mysql-Replikation - Tabellensperre?

Question

Ich arbeite derzeit für ein Unternehmen, das eine Website mit mysql/php betreibt (alle Tabellen verwenden auch den Tabellentyp MYISAM).

Wir möchten die Replikation implementieren, aber ich habe in den Mysql-Dokumenten und an anderer Stelle im Internet gelesen, dass dies die Tabellen sperren wird, wenn die Schreibvorgänge in das Binärprotokoll ausgeführt werden (aus dem die Slave-DBs schließlich lesen werden).

Verursachen diese Sperren ein Problem auf einer Live-Site, die ziemlich schreibintensiv ist? Gibt es außerdem eine Möglichkeit, die Replikation zu aktivieren, ohne die Tabellen sperren zu müssen?

Answer 1

Wenn Sie Ihre Tabellentypen in innodb ändern, wird Zeilensperre verwendet. Außerdem wird Ihre Replikation stabiler sein, da Aktualisierungen transaktional erfolgen. Die MyISAM-Replikation ist auf lange Sicht ein Problem.

Vergewissern Sie sich, dass Ihre Server versionsgleich sind, und fahren Sie IMMER erst den Master herunter, bevor Sie die Slaves herunterfahren. Sie können den Master sofort wieder hochfahren, nachdem Sie die Slaves heruntergefahren haben, aber Sie müssen ihn auch herunterfahren.

Stellen Sie außerdem sicher, dass Sie geeignete Autoextend-Optionen für InnoDB verwenden. Und wenn Sie schon dabei sind, sollten Sie wahrscheinlich von float und double auf "decimal" (d.h. mysql 5.1.) umsteigen. Das erspart Ihnen einige Replikationsprobleme.

Das ist wahrscheinlich ein bisschen mehr, als Sie verlangt haben. Viel Spaß!

P.s.: Ja, die myisam-Sperren können Probleme verursachen. Außerdem ist innodb langsamer als myisam, es sei denn, myisam ist für eine große Auswahl blockiert.

Answer 2

Nach meiner Erfahrung als DBA einer schreibintensiven Site führt das Schreiben eines binären Protokolls zu keinen erkennbaren Problemen mit Sperren oder Leistung auf dem Master . Wenn Sie einen Benchmark durchführen wollen, schalten Sie einfach die Binärprotokollierung ein. Ich glaube nicht, dass Tabellen gesperrt sind, um Abfragen in das binäre Protokoll zu schreiben.

Tischverriegelung auf dem Sklave ist jedoch eine ganz andere Sache. Die Replikation erfolgt seriell: Jede Abfrage wird zu Ende geführt, bevor der Slave die nächste ausführt. Lange Aktualisierungen führen also dazu, dass die Replikation vorübergehend ins Hintertreffen gerät. Wenn Ihre Anwendung die Replikation für die Skalierung nutzen will, muss sie wissen, wie sie dies berücksichtigen kann.

Answer 3

Die Lösung mit dem Tabellentyp myisam ist nicht "besser". Sie können jedoch damit auskommen.

Das Beste, was Sie tun können, ist sicherzustellen, dass Ihr Slave und Ihr Master auf der gleichen Hardware laufen (FPU-Unterschiede können zu Replikationsfehlern führen), sowie sicherzustellen, dass Sie die gleichen Versionsnummern auf Ihren MySQL-Servern verwenden.

Der folgende Link beantwortet Ihre Fragen. Insbesondere haben Sperren in MyISAM-Tabellen eine geringere Chance, Schreibvorgänge zu blockieren, wenn keine Löschvorgänge vorhanden sind. Eine Tabelle, in der keine Löschvorgänge stattfinden, wird also in einem replizierten Setup schneller ausgeführt.

http://dev.mysql.com/doc/refman/5.1/en/internal-locking.html

Sie können die Auswirkungen von "Löchern" abmildern, indem Sie einen DBA regelmäßig während geplanter Ausfallzeiten exportieren/importieren lassen (insbesondere nach Massenlöschungen). Stellen Sie außerdem sicher, dass Ihre Slave-Datenbanken nicht ausfallen, während der Master noch läuft. Das wird Ihnen viele, viele Probleme ersparen.