knebb wrote:isotopp wrote:knebb wrote:Setze ich das auf dem Slave, repariert (schreibt) er Tabellen, fuer die er ja eigentlich nur lesend zustaendig ist :?:
Wieso glaubst Du, daß ein Slave nur lesen würde? Oder anders gefragt: Was glaubst Du, wie die Daten auf den Slave kommen?
Man kann die Worte auch im Mund umdrehen, richtig. :o
Natuerlich "schreibt" er in seine Datenbank. Aber doch nicht selbststaendig.
Doch, genau das. Ein Master macht in einer Replikation nahezu gar nix. Er zeichnet seine Befehle im Binlog auf und er läßt Slaves bei sich einloggen. Mehr tut er nicht.
Der Slave dagegen ist ziemlich busy. Er startet zwei Threads: Der IO_THREAD connected sich an den Master und loggt sich ein. Er lädt mit dem Kommando "SHOW BINLOG EVENTS" das Binlog vom Master auf den Slave runter und packt es dort ins Relay Log um.
Der SQL_THREAD wiederum läuft auf dem Slave, liest das Relay-Log und die darin enthaltenen Kommandos (Du kannst sie Dir mit dem Kommando "mysqlbinlog" auf ein Relay-Logfile angewendet ansehen) und führt sie aus - ganz genau so als hättest Du sie auf einer Konsole eingegeben. Das bedeutet, daß der Slave ganz normale insert/update/delete/replace/optimize/analyze und so weiter Kommandos ausführt wie der Master auch.
Und eine Reparatur einer Datenbank ist mehr als nur das zu tun, was ihm der Master befiehlt. Die Replikation soll ja einen einheitlichen Stand zwischen Master und Slave herstellen.
Nein, das tut eine Replikation nicht. Es ist vielmehr Deine Aufgabe, diesen einheitlichen Zustand VOR dem Start der Replikation herzustellen. Etwa indem Du ein Vollbackup des Masters auf dem Slave einspielst und dem Slave dann die Binlog-Position mitteilst, die der Master hatte als das Vollbackup gemacht wurde.
Die Replikation nimmt diesen einheitlichen Zustand dann und wendet die Befehle aus dem Binlog darauf an. Das führt dazu, daß die Datenbestände auf dem Slave denselben Transformationen unterzogen werden wie auf dem Master, falls alles klappt. Mit einigen Befehlen ("INSERT INTO t (d) values (@@hostname)" etwa, oder "INSERT INTO t (d) values (sysdate())") klappt das nicht, weil diese Befehle auf dem Master und dem Slave unterschiedliche Ergebnisse liefern, wenn man sie ausführt. Dann divergieren Master und Slave über die Zeit (und man braucht ein Tool wie mysql-table-sync von Baron Schwartz, um das zu erkennen und zu korrigieren).
Dieser Zustand besteht sicherlich nicht mehr, wenn der Slave Tabellen selbststaendig veraendert/ repariert.
Der Slave ist für seine Tabellen selbst zuständig und muß sie auch selber reparieren. Sonst tut das nämlich keiner, und wenn sie kaputt sind, schlagen Schreibbefehle aus dem Binlog auf diese Tabellen fehl oder machen sie Tabellen noch mehr kaputt.
