Wegen einigen (keine sehr klaren Gründe für mich) Ich habe vergessen, den postgresql-Daemon beim Distributions-Upgrade auf einem meiner Debian-Server zu aktualisieren. Der Postgresql-Daemon hat die nette Funktion, seine neue Version nicht zu verwenden (im Gegensatz zu MySQL) bis wir überzeugt sind, dass der neue voll kompatibel mit dem Start ist – Sehr nützlich in großen Datenbanken. Der Aktualisierungsprozess selbst ist auf Folgendes beschränkt 2 Schritte:

  • pg_dropcluster
  • pg_upgradecluster

Der pg-Daemon muss gestoppt werden, bevor Sie den Cluster löschen können!

pg_dropcluster 9.4 main

Dieser Befehl wird schnell ausgeführt, dann gehen wir zum wesentlichen Teil über – das Upgrade selbst

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

Wenn alles reibungslos verlief, sollten Sie eine Nachricht wie die oben genannte erhalten, die Sie einlädt, die alten Daten von pg zu entfernen.

pg_dropcluster 9.1 main

Am Ende dieses Tarpans können Sie den Vorgang nun erneut starten. Für mich sind die Basen klein und ich kann leider nicht abschätzen, wie lange das signifikante Upgrade dauert..

Wir haben letzte Woche den Fantastico Deluxe Installer gekauft, Dies ist meiner bescheidenen Meinung nach einer der anständigsten für CPanel-Server. Wir haben es installiert, getestet und alles verlief reibungslos. Heute hat ein Client ein Problem mit der Codierung einer WordPress-Installation gemeldet. Ich überprüfte die Dinge und stellte sofort das Problem fest, dass die Datenbanken standardmäßig Latin1 anstelle von UTF8 codierten, wie es angenommen wurde. Es macht noch mehr Spaß, dass in phpmyadmin geschrieben steht, dass UTF8 standardmäßig verwendet wird, Theater. Ich habe mich entschlossen, in den Fantastico-Dateien nachzuschauen, ob es irgendwo einen Ort gibt, an dem ich die Standarddatenbankeinstellungen bereitstellen kann. Auf den ersten Blick habe ich nichts gesehen. Dann stürzte mich etwas, um zu sehen, was sich in my.conf befindet und was zu sehen ist. Es gab keine entsprechenden Einstellungen in der Konfiguration und alles leuchtet auf, was standardmäßig eingestellt ist. Der MySQL-Server ist ein Hardcode für die Verwendung von UTF8, wenn er nicht mit anderen Einstellungen konfiguriert ist und der Fantastico offensichtlich mit Latin1 ( Das ist eine ziemlich dumme Entscheidung). Die Lösung ist wie immer trivial hinzugefügt 2 Bestellung c [mysqld] Teil, um UTF8 zur Standardkodierung zu machen und alles schläft ein 🙂

Zeichensatzserver = utf8
collation-server = utf8_general_ci

Ich habe keine Ahnung, warum ich diese Einstellungen verpasst habe, da ich ein paar gespielt habe “fein” MySQL-Einstellungen.

Verbessert von Zemanta

Image representing MySQL as depicted in CrunchBase

Vor einiger Zeit habe ich über MySQL Volltextsuche 🙂 heute hatte ich eine sehr interessante Erfahrung mit einer Anfrage. Im Allgemeinen sucht die Abfrage nach Ergebnissen, die in einer anderen Tabelle fehlen.. Eine einfache Select- und eine Unterauswahl im WHERE-Teil der Abfrage. Grundsätzlich ist das Skelett

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

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

Grundsätzlich ist eine einfache Abfrage. Ich schrieb es für 30 Sec. Ich lasse es fallen und die Maschine. Nach langem und geduldiges Warten auf mich oder in genau 43 Sek. . Meine spat partitur lol . PFFF Wahnsinn. Ich betrete die Maschine beobachten, dass der Prozessor normalerweise fast im Leerlauf-Zustand geladen wird. Schock und Schrecken. Ich führe die Abfrage erneut mit demselben Ergebnis aus.. Gebohrtes WTF. Ich führe die Erklärung der Anfrage und alles leuchtet – Das zweite zweiteTextField-Feld ist nur Volltextsuche Ohne Index, Und dort ist das Tablett bescheiden von ca. 35 k die Bestellung. Wer zu lesen – Volltextsuche ist kein Index. Ist jetzt klar das Problem ein Quickie

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

Und die Dinge kamen an die Orte, die Query 0.0005 SEC-😀

Seien Sie vorsichtig, wie Sie Ihre Indizes auf sie setzen hängt marginale Geschwindigkeit der Anwendung.

P. s insgesamt bin ich falsch über die oben genannte Situation nicht nur, weil der Index fehlt, weil es nicht die Volltext-Suchmethode verwendet 😀

Verbessert von 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 ви.