Din cauza unora (nu sunt motive foarte clare pentru mine) Am uitat să actualizez demonul postgresql în actualizarea distribuției pe unul dintre serverele mele Debian. Demonul Postgresql are caracteristica frumoasă de a nu începe să folosească noua sa versiune (spre deosebire de Mysql) până când suntem convinși, că noul este pe deplin compatibil cu lansarea – extrem de util în bazele de date mari. Procesul de actualizare în sine este limitat la următoarele 2 pași:

  • pg_dropcluster
  • pg_upgradecluster

Demonul pg trebuie oprit înainte de a putea renunța la cluster!

pg_dropcluster 9.4 main

Această comandă trece repede, apoi trecem la partea esențială – actualizarea în sine

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

Dacă totul a decurs fără probleme, ar trebui să primiți un mesaj precum cel de mai sus, care vă invită să scăpați de datele vechi din pag.

pg_dropcluster 9.1 main

La sfârșitul acestei perioade, puteți începe procesul din nou. Pentru mine, bazele sunt mici și, din păcate, nu pot estima cât durează actualizarea semnificativă..

Am cumpărat instalatorul Fantastico Deluxe săptămâna trecută, care în umila mea părere este unul dintre cele mai decente pentru serverele CPanel. L-am instalat, l-am testat și totul a decurs fără probleme. Astăzi, un client a raportat o problemă cu codificarea unei instalări de wordpress. Am revizuit lucrurile și am aruncat imediat lumină asupra problemei, bazele de date erau codificate în mod implicit Latin1 în loc de UTF8 așa cum se presupunea. Este și mai distractiv, că în phpmyadmin se scrie că UTF8 este folosit implicit, dramă. Am decis să mă uit la fișierele Fantastico pentru a vedea dacă există undeva unde pot oferi setările implicite ale bazei de date la prima vedere, nu am văzut nimic. Apoi, ceva m-a grăbit să văd ce este în my.conf și ce să văd nu au fost setări corespunzătoare în configurație și totul se aprinde la ceea ce este setat implicit. Serverul Mysql este hardcode pentru a utiliza UTF8 dacă nu este configurat cu alte setări și Fantastico este în mod evident cu Latin1 ( care este o decizie destul de stupidă). Soluția ca întotdeauna este adăugată banală 2 comanda c [mysqld] parte pentru a face UTF8 codarea implicită și totul adorme 🙂

caractere-set-server = utf8
colaționare-server = utf8_general_ci

Nu am idee de ce am ratat aceste setări, având în vedere că mă jucam să fac câteva “amenda” setări mysql.

Îmbunătățit de Zemanta

Image representing MySQL as depicted in CrunchBase

Cu ceva timp în urmă am scris despre MySQL Full Text Căutare 🙂 Azi am avut o experiență foarte interesantă cu o singură solicitare. În general, interogarea caută rezultate care lipsesc dintr-un alt tabel. O selectare de bază și una secundară în partea WHERE a interogării. În general, scheletul este

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

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

Practic, o simplă interogare. Am scris-o pentru 30 sec Îl rulez și mașina se bucle. După o lungă și răbdătoare așteptare din partea mea sau mai precis ~ 43 sec . Am scos rezultatul lol . Pffff madhouse. Intru în mașină urmărind că procesorul este încărcat în mod normal aproape în stare inactivă. Șoc și groază. Rulez interogarea din nou același rezultat. La dracu WTF. Alerg să explic interogarea și totul strălucește – al doilea câmp secundTextField este numai căutare text complet fără indice, iar acolo placa este modestă de aproximativ 35k linii. Cine să citească – căutarea textului complet nu este un index. Problema este rapid clară

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

Și lucrurile au căzut la locul lui Query a luat 0.0005 sec

Aveți grijă cum puneți indexurile de la ei, viteza interogării depinde în mod marginal de dvs..

p.s În general, sunt de vină pentru situația de mai sus, nu doar pentru că îi lipsește un index, ci pentru că nu folosește metoda de căutare a textului complet 😀

Îmbunătățit de 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 ви.