Nicht-Replikations-Schreibvorgänge in MySQL-Slave verhindern?

Wir haben einige MySQL-Datenbankserver mit zeilenbasierter Replikation eingerichtet, um die Leistung zu verbessern. Die Software schreibt in den Master und liest entweder vom Master oder vom Slave. Alles funktioniert großartig, zum größten Teil.

Ich verstehe, dass MySQL Schreibzugriffe auf den Slave zulässt, obwohl er weiß, dass es sich um einen MySQL-Slave handelt. Im Idealfall würde ich dies gerne schließen. Selbst wenn jemand einen fehlerhaften Code schreibt, der eine Leseverbindung erhält und eine ausführt UPDATE, wird ein Fehler ausgegeben, anstatt Daten auf den Slave zu schreiben .

Gibt es eine Möglichkeit, dies in MySQL zu tun? Natürlich möchten wir dies auch mit unserer Software unmöglich machen, aber wie eine Firewall auf unseren Servern möchte ich so defensiv wie möglich sein.

Vielen Dank!

Aktivieren Sie die read-onlyOption in my.cnf. Es kann auch --read-onlymit mysqld als Flag in der Befehlszeile angegeben werden.

Als Alternative zur Einstellung read_only=1(z. B. wenn die Slave-Instanz andere Scratchpad- / Berichts- / Entwicklungsdatenbanken enthält) entferne ich manchmal alle anderen Berechtigungen als SELECT von allen Benutzern in die zu replizierende Datenbank.

Das heißt, nachdem ich den Befehl GRANT auf dem Master ausgeführt habe, führe ich den Befehl REVOKE auf dem Slave aus.

Ab MySQL 5.7.8 gibt es jetzt eine super_read_onlyOption, die sogar SUPER-Benutzer daran hindert, Client-Updates durchzuführen. Der Replikationsprozess wird nicht unterbrochen. Wie bei anderen Einstellungen kann Folgendes eingestellt werden:

• im Kommandozeilenformat ( --super_read_only=ON),
• als Variable in my.cnf ( super_read_only=1) oder
• von der Client-Eingabeaufforderung ( SET GLOBAL super_read_only = 1;).

Beachten Sie, dass:

• super_read_onlyImplizit aktivieren aktiviertread_only
• Das read_onlyimplizite Deaktivieren wird deaktiviertsuper_read_only

Einige Einschränkungen:

• Weder read_onlynoch super_read_onlywerden Operationen für temporäre Tabellen verhindert.
• Sie verhindern keine Metadatenoperationen wie ANALYZE TABLE und OPTIMIZE TABLE.
• Es wurden Fehler für bestimmte Abfragen mit super_read_onlyaktivierter Funktion gemeldet.

Referenz: https://www.percona.com/blog/2016/09/27/using-the-super_read_only-system-variable/

Wie der erste Beitrag etwas andeutet, tun Sie dies mit Berechtigungen. Die schreibgeschützte Option funktioniert nicht für Superuser als FYI und ist auch nicht wirklich eine praktikable Lösung für einen Slave, bei dem Sie Schreibzugriffe verhindern möchten. Sie müssen Schreibvorgänge mit Benutzer- / Datenbank- / Tabellenberechtigungen verhindern. Zum einen muss der Replikationsbenutzer weiterhin in der Lage sein, auf den Slave zu schreiben, um ihn mit dem Master synchron zu halten. Eine bessere Möglichkeit, Schreibvorgänge zu steuern, besteht darin, Optionen zu widerrufen, die Schreibvorgänge (z. B. Einfügen, Erstellen usw.) für den betreffenden Benutzer zulassen, bei denen nur Lesevorgänge auf dem Slave ausgeführt werden sollen.

Gewähren Sie den Benutzern auf dem Slave nur replikationsbezogene Rechte. Sie haben immer noch das Problem der Root-Benutzerrechte, können jedoch den Remote-Root-Zugriff auf den DB-Server entfernen.