Поради някакви (не много ясни ми причини) бях пропуснал да направя ъпгрейд на postgresql демона при дистрибутивният ъпгрейд на един от Debian сървърите ми. Postgresql демона има хубавото свойство да не започва да използва новата си версия (за разлика от Mysql) докато не убедим, че новата е на пълно съвместима със стартаизключително полезно при големи бази данни. Самият процес по обновяване се ограничава до следните 2 стъпки:

  • pg_dropcluster
  • pg_upgradecluster

Преди да издропите клъстера pg демона трябва да е спрян!

pg_dropcluster 9.4 main

Тази команда преминава бързо, след което преминаваме към съществената частсамият ъпгрейд

pg_upgradecluster 9.1 main
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster 9.4/main ...
config /etc/postgresql/9.4/main
data   /var/lib/postgresql/9.4/main
locale en_US.UTF-8
Flags of /var/lib/postgresql/9.4/main set as -------------e-C
port   5433
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database xpqt...
Analyzing database xpqt...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Copying old server.crt...
Copying old server.key...
Stopping target cluster...
Stopping old cluster...
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

pg_dropcluster 9.1 main

Ако всичко е минло гладко трябва да получите съобщение като горното което ви подканва да разкарате старите данни от pg.

pg_dropcluster 9.1 main

В края на тая тарпана вече можете да стартирате процеса си отново. При мен базите са малки и за съжаление не мога да дам оценка за колко време преминава същественият ъпгрейд.

От миналата седмица закупихме Fantastico Deluxe инсталатора, който по мое скромно мнение е един от най приличните за CPanel сървъри. Инсталирахме го тествахме и всичко мина гладко. Днес един клиент ми съобщи за проблем с енкодинга на wordpress инсталация. Прегледах нещата и веднага лъсна проблема базите бяха с енкодинг по подразбиране Latin1 вместо UTF8 като се предполагаше. Още по забавното е, че в phpmyadmin-а пише че се използва UTF8 по подразбиране, драма. Реших да прегледам файловете на Fantastico-то да видя дали няма някъде където мога да окажа настройките за базите данни по подразбиране на пръв поглед не видях нищо. След това нещо ме текна да видя какво има в my.conf-а и какво да видя нямаше съответните настройки във конфигурация и всичко си пали на каквото му е зададено по подразбиране. Mysql сървъра е хардкоднат да ползва UTF8 ако не е конфигуриран с други настройки и Fantastico-то явно е с Latin1 ( което е доста глупаво решение). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

character-set-server=utf8
collation-server=utf8_general_ci

Нямам никаква идея поради каква причина съм пропуснал тези настройки при положение че си играх да правя няколкофининастройки на mysql-а.

Ulepszony przez Zemanta

Image representing MySQL as depicted in CrunchBase

Jakiś czas temu pisałem o MySQL Wyszukiwanie pełnotekstowe 🙂 dzisiaj miałem bardzo ciekawe doświadczenie z jedną prośbą. Ogólnie rzecz biorąc, kwerenda wyszukuje wyniki, których brakuje w innej tabeli. Jeden podstawowy Wybierz i jeden sub wybierz w części WHERE kwerendy. Zasadniczo szkielet jest

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

Zasadniczo proste zapytanie. Napisałem go dla 30 Sec. Upuszczam go i maszynę. Po długim i cierpliwie czekam z mojej strony lub dokładnie ~ 43 sek. . Mój pluć wynik lol . Pfff Szaleństwo. Wchodzę na maszynę oglądając procesor jest zwykle ładowany prawie w stanie bezczynności. Szok i przerażenie. Uruchamiam kwerendę ponownie ten sam wynik. Wiercone WTF. Biegnę wyjaśnić wniosek i wszystko świeci – Drugie pole secondTextField jest tylko Wyszukiwanie pełnotekstowe Bez indeksu, I tam taca jest skromna od około 35 k zamówienia. Kogo czytać – Wyszukiwanie pełnotekstowe nie jest indeksem. Czy teraz jest jasne, że problem szybki numerek

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

I rzeczy przyszedł do miejsc Query wziął 0.0005 😀 SEC

Należy uważać, jak umieścić indeksy na nich zależy marginalnej prędkości aplikacji.

P. s ogólnie się mylę co do powyższej sytuacji nie tylko dlatego, że brakuje indeksu, ponieważ nie korzysta z metody wyszukiwania pełnego tekstu 😀

Ulepszony przez Zemanta

Вчера след обновяване на версията на mysql, server-ът ми започна да ми крещи, че има табличка, която не е била затворена чисто и има нужда от поправка и прочие. Блах, коя ще е тая таблица, все пак са ми около 30-тина на тоя сървър. Единият вариант е да видите в log-овете какво пише по въпроса и да пуснете поправка на съответната таблица или другият вариантдалеч по-добрияте да пуснете поправка, проверка и оптимизиране на всички таблици. За тази цел ще използвам mysqlcheck инструмента. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъвароматична поправка, проверка и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.