Ich habe eine Anzahl von MySQL-Servern mit der Version 5.1.63 und während ich einige Anfragen gegen den Slave zu Beginn dieser Woche abrief, bemerkte ich einige Daten auf dem Slave, die mit einer Update-Anweisung auf dem Master entfernt werden sollten.
Meine anfänglichen Gedanken waren:
Also habe ich untersucht, indem ich eine mysql show status "table" Abfrage ausgeführt habe. Dies wurde mit einer Testdatenbank auf jedem der Server durchgeführt, um zu sehen, wie die Datenlänge war. In vielen Fällen zeigte es mir die Datenlänge zwischen den Servern, aber bei einem Blick auf die Daten, die ich sehen konnte das gleiche, also konnte ich diese Methode nicht verwenden, um zu sehen, ob es irgendwelche Unterschiede gab, da sie fehleranfällig zu sein scheint.
Als nächstes habe ich eine einfache (über alle dbs) Zeilenanzahl für jede Tabelle ausgeführt, um zu bestätigen, dass die Zeilenanzahl dieselbe war - es war.
Ich begann dann in den Bin-Protokollen nach Replikation zu suchen. Ich konnte die Update-Anweisungen sehen, die in den Protokollen deutlich sichtbar sein sollten, aber das Update lief nie.
Was ich wissen muss ist:
Jede Hilfe ist willkommen.
Wenn Sie Statement-basierte Replikation verwenden, ist es leicht möglich, dass aufgrund von schlecht konstruierten INSERT-Anweisungen unterschiedliche Ergebnisse auf Master und Slave auftreten.
INSERT SELECT ohne ORDER BY, oder wo ORDER BY nichtdeterministische Ergebnisse hinterlassen kann, führt dazu, dass die Slaves vom Master abweichen.
Von der MySQL-Site Ссылка
Die Reihenfolge, in der Zeilen von einer SELECT-Anweisung mit Nein zurückgegeben werden ORDER BY-Klausel ist nicht festgelegt. Dies bedeutet, dass bei der Verwendung Replikation gibt es keine Garantie, dass ein solcher SELECT Zeilen zurückgibt die gleiche Reihenfolge auf dem Master und dem Slave; Dies kann dazu führen Inkonsistenzen zwischen ihnen. Um dies zu verhindern, müssen Sie sollte immer INSERT ... SELECT-Anweisungen schreiben, die sein sollen repliziert als INSERT ... SELECT ... ORDER BY Spalte. Die Wahl der Spalte spielt keine Rolle solange die gleiche Reihenfolge für die Rückgabe der Zeilen wird sowohl auf dem Master als auch auf dem Slave erzwungen. Siehe auch Abschnitt 16.4.1.15, "Replikation und LIMIT".
Wenn dies passiert ist, sind Ihre Replikate auseinander gegangen und der einzige sichere Weg, sie wieder in Gang zu bringen, besteht darin, sie aus einer kürzlichen Sicherung der Master-Datenbank wiederherzustellen. Der schlimmste Teil davon ist, dass der Fehler möglicherweise niemals zu einem Fehler der Replikation führt, aber die Ergebnisse sind inkonsistent. Normalerweise schlägt die Replikation fehl, wenn eine UPDATE- oder DELETE-Anweisung eine andere Anzahl von Zeilen betrifft als die des Masters. Dies ist verwirrend, da es nicht das UPDATE war, das den Fehler verursachte und die einzige Möglichkeit, das Problem zu beheben, besteht darin, jede INSERT-Abfrage zu überprüfen die Codebasis!
Die Statusdetails stammen aus information_schema, das Daten aus Datenbankstatistiken für die Mysql-Instanz zusammenfasst und nie bei jeder Ausführung gleich geblieben ist. Es kann nur als grobe Schätzung der Datengröße in Bytes angesehen werden, aber nie als genauer Wert für die Index- und Datenlänge. Es kann für Schätzungen verwendet werden, nicht jedoch für Gegenprüfungen. Für die Replikation können Sie überprüfen, ob der Slave io und sql gegen den Master läuft oder nicht. Und Relay-Info sehen Sie möglicherweise die entsprechenden Protokolldetails von Master und Slave.
Von, natürlich (1) Art des Tuns ist das Zählen (*) von Tabellen EOD stellt sicher, dass die Daten in Tabellen auf Master und Slave konsistent sind oder nicht. Aber um genau zu sein, (2) nehmen Sie zufällige Wertfelder und Gegenprüfung mit Master und Slave. Auch wenn du damit nicht zufrieden bist, (3) kannst du sie ins Outfile nehmen und Diff oder Checksum nehmen. Ich bevorzuge (1) und (2). Wenn (1) nicht möglich ist (2) überzeugt mich immer noch. ;)
Tags und Links mysql sql-update replication