Sichern Sie MySQL Amazon RDS

RDS erlaubt nicht einmal dem Hauptbenutzer den SUPER Privileg, und dies ist erforderlich, um FLUSH TABLES WITH READ LOCK auszuführen . (Dies ist eine unglückliche Einschränkung von RDS).

Die fehlerhafte Anweisung wird von --master-data generiert Option, die natürlich notwendig ist, wenn Sie die genauen Binlog-Koordinaten erfahren möchten, wo die Sicherung beginnt. FLUSH TABLES WITH READ LOCK erwirbt eine globale Lesesperre für alle Tabellen, wodurch mysqldump START TRANSACTION WITH CONSISTENT SNAPSHOT kann (wie bei --single-transaction ) und dann SHOW MASTER STATUS um die Binärlogkoordinaten zu erhalten, woraufhin es die globale Lesesperre aufhebt, weil es eine Transaktion hat, die die sichtbaren Daten in einem Zustand hält, der mit dieser Logposition konsistent ist.

RDS unterbricht diesen Mechanismus, indem es den SUPER ablehnt Privileg und bietet keine offensichtliche Problemumgehung.

Es gibt einige hackige Optionen, um dies richtig zu umgehen, von denen keine besonders attraktiv sein kann:

• Führen Sie die Sicherung während eines Zeitraums mit geringem Datenverkehr durch. Wenn sich die Binlog-Koordinaten zwischen dem Start der Sicherung und nachdem die Sicherung mit dem Schreiben von Daten in die Ausgabedatei oder den Zielserver begonnen hat, nicht geändert haben (vorausgesetzt, Sie haben --single-transaction ), dann funktioniert dies, weil Sie wissen, dass sich die Koordinaten nicht geändert haben, während der Prozess ausgeführt wurde.

• Beobachten Sie die Binlog-Position auf dem Master, bevor Sie mit der Sicherung beginnen, und verwenden Sie diese Koordinaten mit CHANGE MASTER TO . Wenn das binlog_format Ihres Masters auf ROW gesetzt ist dann sollte dies funktionieren, obwohl Sie wahrscheinlich einige anfängliche Fehler überspringen müssen, aber später keine Fehler mehr haben sollten. Dies funktioniert, weil die zeilenbasierte Replikation sehr deterministisch ist und aufhört, wenn versucht wird, etwas einzufügen, das bereits vorhanden ist, oder etwas zu löschen, das bereits verschwunden ist. Sobald Sie die Fehler passiert haben, befinden Sie sich an den wahren Binlog-Koordinaten, an denen der konsistente Schnappschuss tatsächlich begonnen hat.

• wie im vorherigen Punkt, aber versuchen Sie nach dem Wiederherstellen der Sicherung, die richtige Position zu bestimmen, indem Sie mysqlbinlog --base64-output=decode-rows --verbose verwenden um das Binlog des Masters an den erhaltenen Koordinaten zu lesen, Ihren neuen Slave zu überprüfen, um zu sehen, welche der Ereignisse bereits ausgeführt worden sein müssen, bevor der Schnappschuss tatsächlich gestartet wurde, und mit den so ermittelten Koordinaten zu CHANGE MASTER TO .

• Verwenden Sie einen externen Prozess, um eine Lesesperre für jede einzelne Tabelle auf dem Server zu erhalten, wodurch alle Schreibvorgänge gestoppt werden. Beachten Sie, dass die Binlog-Position von SHOW MASTER STATUS die Inkrementierung gestoppt hat, starten Sie die Sicherung und geben Sie diese Sperren frei.

Wenn Sie einen dieser Ansätze außer vielleicht dem letzten verwenden, ist es besonders wichtig, dass Sie Tabellenvergleiche durchführen, um sicherzustellen, dass Ihr Slave mit dem Master identisch ist, sobald er läuft. Wenn Sie auf nachfolgende Replikationsfehler stoßen... dann war es das nicht.

Wahrscheinlich die sicherste Option – aber vielleicht auch die nervigste da es so aussieht, als ob es nicht notwendig sein sollte -- beginnen Sie mit der Erstellung einer RDS-Read Replica Ihres RDS-Masters. Sobald es hochgefahren und mit dem Master synchronisiert ist, können Sie die Replikation auf dem RDS-Read Replica stoppen, indem Sie eine von RDS bereitgestellte gespeicherte Prozedur ausführen, CALL mysql.rds_stop_replication das in RDS 5.6.13 und 5.5.33 eingeführt wurde was den SUPER nicht erfordert Privileg.

Wenn der RDS-Replik-Slave gestoppt ist, nehmen Sie Ihren mysqldump aus dem RDS-Lesereplikat, das nun ab einem bestimmten Satz von Masterkoordinaten einen unveränderten Datensatz enthält. Stellen Sie diese Sicherung auf Ihrem externen Slave wieder her und verwenden Sie dann die Masterkoordinaten der RDS-Read Replica von SHOW SLAVE STATUS Exec_Master_Log_Pos und Relay_Master_Log_File als Ihr CHANGE MASTER TO Koordinaten.

Der in Exec_Master_Log_Pos angezeigte Wert auf einem Slave ist der Start der nächsten Transaktion bzw zu verarbeitendes Ereignis , und genau da muss Ihr neuer Slave anfangen, auf dem Master zu lesen.

Anschließend können Sie das RDS-Lesereplikat außer Betrieb nehmen, sobald Ihr externer Slave betriebsbereit ist.