Néhány miatt (nem túl világos okok számomra) Elfelejtettem frissíteni a postgresql démont a disztribúció frissítésekor az egyik Debian szervernél. A Postgresql démonnak az a jó tulajdonsága, hogy nem kezd el használni az új verziót (ellentétben a Mysql-lel) amíg nem vagyunk meggyőződve, hogy az új teljesen kompatibilis a bevezetéssel – rendkívül hasznos nagy adatbázisokban. Maga a frissítési folyamat a következőkre korlátozódik 2 lépések:

  • pg_dropcluster
  • pg_upgradecluster

A fürt lehagyása előtt le kell állítani a pg démont!

pg_dropcluster 9.4 main

Ez a parancs gyorsan áthalad, akkor továbbmegyünk a lényeges részhez – maga a frissítés

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

Ha minden zökkenőmentesen zajlik, akkor olyan üzenetet kell kapnia, mint a fenti, amely felhívja Önt, hogy szabaduljon meg a régi adatlaptól.

pg_dropcluster 9.1 main

A tarpan végén most újra indíthatja a folyamatot. Számomra az alapok kicsik és sajnos nem tudom megbecsülni, hogy mennyi ideig tart a jelentős frissítés..

Megvásároltuk a Fantastico Deluxe telepítőjét a múlt héten, ami szerény véleményem szerint a legmegfelelőbb a CPanel szerverek számára. Telepítettük, teszteltük és minden zökkenőmentesen ment. Ma egy ügyfél beszámolt a WordPress telepítésének kódolásáról. Átnéztem a dolgokat, és azonnal felvillantam a probléma, amelyet az adatbázisok alapértelmezés szerint a Latin1 kódoltak az UTF8 helyett, ahogy azt feltételezték. Még szórakoztatóbb, hogy a phpmyadminben azt írják, hogy az UTF8 alapértelmezés szerint használatos, dráma. Úgy döntöttem, hogy megnézem a Fantastico fájlokat, hogy megnézzem, van-e valahol olyan hely, ahol megadhatom az alapértelmezett adatbázis-beállításokat első pillantásra, nem láttam semmit. Aztán valami felrobbant, hogy megnézze, mi van a my.conf fájlban, és mit kell látni, a konfigurációban nem voltak megfelelő beállítások, és minden az alapértelmezés szerint világít.. A Mysql-kiszolgáló az UTF8 használatához keményen használható, ha nincs beállítva más beállításokkal, és a Fantastico nyilvánvalóan a Latin1 ( ami nagyon ostoba döntés). A megoldás, mint mindig, triviális 2 rend c [mysqld] részben az UTF8 alapértelmezett kódolásává válik, és minden elalszik 🙂

karakter-set-server = utf8
egybevetés-szerver = utf8_general_ci

Fogalmam sincs, miért hagytam ki ezeket a beállításokat, mivel néhányat játszottam “bírság” mysql beállítások.

Javította Zemanta

Image representing MySQL as depicted in CrunchBase

Egy ideje írtam MySQL teljes szöveges keresés 🙂 Ma nagyon érdekes tapasztalatom volt egy kéréssel. Általában a lekérdezés olyan eredményeket keres, amelyek hiányoznak egy másik táblából. Egy alapválasztás és egy részválasztás a lekérdezés WHERE részében. Általában a csontváz

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

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

Alapvetően egy egyszerű lekérdezés. Én írtam 30 mp. Futom, és a gép hurok. Hosszú és türelmes várakozás az én részemről vagy pontosabban ~ 43 mp . Kihúztam az eredményt lol . Pffff őrült ház. Bemegyek a gépbe, figyelve, hogy a CPU szinte üresjáratban van betöltve. Sokk és horror. A lekérdezést ismét ugyanazzal az eredménnyel futtam. Bassza meg a WTF-t. Elmagyarázom a lekérdezést, és minden süt – a második mező, a secondTextField csak teljes szöveg keresés index nélkül, és ott a lemez szerény, kb. 35 ezer vonal. Ki olvasni – A teljes szöveges keresés nem index. A probléma gyorsan megoldódik

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

És a dolgok a helyére estek, amit Query elvette 0.0005 sec 😀

Vigyázzon, hogyan készíti tőlük az indexeket, a lekérdezés sebessége csekély mértékben függ tőled.

p.s Általában véve a fenti helyzetet hibáztatom nemcsak azért, mert nincs indexe, hanem azért is, mert nem használja a teljes szöveg keresési módját 😀

Javította 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 ви.