Köszönhető, hogy néhány (nem nagyon világos számomra) Volt elhanyagolt, hogy a postgresql démon, az egyik az én-m Debian szerverek elosztó rendszerre való frissítés. PostgreSQL démon birtokol a szép tulajdonsága nem kezd használ a új változat (Ellentétben a Mysql) amíg nem győzzük, az új teli összeegyeztethető-val a dob- – rendkívül hasznos a nagy adatbázisok. A puszta folyamat megújítási korlátozódik a következő 2 lépések:

  • pg_dropcluster
  • pg_upgradecluster

Mielőtt a démon izdropite fürt kell megállt pg!

pg_dropcluster 9.4 main

Ezzel a paranccsal gyorsan halad, majd haladunk kijelöléshez – az egyszerű 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 sima minlo Önnek kellene kap egy üzenetet, mint a fenti, amely megkérdezi, hogy ki a régi adatok pg.

pg_dropcluster 9.1 main

A végén ez lehet kezdeni a Tarpan folyamat újra. Nekem az alapok kicsik, és sajnos nem tudok adni egy becslést a mennyi idő telik az alapvető frissítés.

Mivel a múlt héten vásárolt Fantastico Deluxe telepítő, amely az én szerény véleményem az egyik legtisztességesebb az CPanel szerverek. Telepítettük és teszteltük minden simán ment. Ma egy ügyfél mesélt egy probléma a kódolás wordpress telepítés. Keresztül a dolgokat, és azonnal sütött probléma bázisok voltak Latin1 kódoló alapértelmezett UTF8 helyett feltételezve. Még több móka, hogy phpmyadmin-írta és az alapértelmezett UTF8, dráma. Úgy döntöttem, hogy vizsgálja felül a fájlokat a Fantastico-, hogy hátha van valahol, hol találom magam beállítások adatbázis alapértelmezés szerint először nem látott semmit. Aztán valami TEKNA, hogy lássam, mi van my.conf-és mit kell látni nem volt megfelelő beállításokat a konfigurációs és minden villanyt, amit az alapértelmezett beállítás,. MySQL szerver hardkodnat használni UTF8 ha helytelenül van beállítva az egyéb beállításokat, és Fantastico-it nyilvánvalóan Latin1 ( ami elég hülye döntés). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

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

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

Növeli Zemanta

Image representing MySQL as depicted in CrunchBase

Néhány évvel ezelőtt írtam MySQL teljes szöveges keresés 🙂 Ma már egy nagyon érdekes tapasztalat-val egy lekérdezés. Általában a lekérdezés eredményeit, hogy hiányzik egy másik táblában keres. Válasszon egy al osnovne és részben válassza ki hol az alkalmazás. Általában, a csontváz és

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

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

Általában, egy egyszerű kérés. Írtam, hogy a 30 S engedje őt, és megragadt a gép. Miután egy hosszú és türelmesen vár a részemről, vagy csak ~ 43 mp . Köpni a pontszám lol . Pfff bolondokháza. Adja meg a gép látszó CPU szabályosan megterhelt szinte üresjárati állapotban. Sokk és félelem. A lekérdezés futtatásával újra mindig ugyanazt az eredményt. WTF fasz. Futtassuk a lekérdezést, és mindent megmagyaráz én – a második pedig csak secondTextField teljes szöveges keresés Nincs index, és van egy szerény tálca körülbelül 35 k-vonal. Mit olvas – teljesszöveges keresési index nincs. Már most világos, a probléma valódi gyors

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

És a dolgok lekérdezésének helyek 0.0005 MP 😀

Legyen óvatos, hogyan tesz az indexek közülük függ a marginális ráta az alkalmazás.

p. s egész tévedtem a fenti helyzet nem csak azért, mert hiányzik az index, mert nem használja a teljes szöveges keresési módszer 😀

Növeli Zemanta

Tegnap frissítése után a MySQL verzió, szerver látott velem kiabálni kezdett velem, hogy van egy táblázat, amely nem volt lezárva tisztán és javításra szorul, stb. blabla, mi lesz ebben a táblázatban, Még ott van a 30-valami ezen a szerveren. Az egyik lehetőség az, hogy a log-ok, mit mond a kérdés, és futás javítás az asztal vagy a másik lehetőség – messze jobb – Ez fut javítás, ellenőrzése és optimalizálása az összes táblát. Ez fogja használni mysqlcheck eszköz. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:

mysqlcheck -Aor -u root -p

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

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