Replikation hält einen zweiten Server mit denselben Daten, der dieselben Änderungen kurz nach dem ersten anwendet. Sie taugt für drei Dinge und wird regelmäßig für ein viertes eingesetzt, das sie nicht leistet.

Wofür sie taugt

  • Lesekapazität - Berichte und Suche gehen an die Replik, Schreibvorgänge an den Primärserver.
  • Sicherungen ohne Last - dumpen Sie von der Replik, und die laufende Website merkt nichts.
  • Failover - eine warme Kopie, bereit zur Beförderung, die aus einem Neuaufbau ein Umschalten macht.

Was sie nicht ist

Eine Replik ist keine Sicherung. DROP TABLE orders repliziert in unter einer Sekunde, und dann fehlt die Tabelle in beiden Kopien. Sicherungen schützen vor Fehlern, Repliken vor einer sterbenden Maschine. Sie brauchen beides - siehe Sicherungen als Sicherheitsmaßnahme.

Der Rückstand, mit dem niemand rechnet

Replikation ist standardmäßig asynchron: der Primärserver wartet nicht. Auf einen Schreibvorgang unmittelbar ein Lesen von der Replik folgen zu lassen kann den alten Wert liefern - ein Kunde speichert sein Profil und es erscheint unverändert.

mysql -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind|Replica_(IO|SQL)_Running'

Die Regel, die das vermeidet: von der Replik nur dort lesen, wo leicht veraltete Daten hinnehmbar sind. Was der Benutzer gerade geschrieben hat, wird vom Primärserver gelesen.

Aufbau, im Überblick

  1. Binärlogging auf dem Primärserver einschalten — log_bin, eine eindeutige server_id und gtid_mode = ON.
  2. Einen Replikationsbenutzer anlegen — nur mit REPLICATION SLAVE.
  3. Die Replik aus einem konsistenten Dump befüllen — mysqldump --single-transaction --source-data=2
  4. Sie auf den Primärserver richten und starten — dann den Status beobachten, bis sie aufgeholt hat.

Danach im Auge behalten

Eine stehengebliebene Replik ist still. Sie beantwortet weiter Lesevorgänge mit Daten, die inzwischen Tage alt sind - schlimmer, als wenn sie ausgefallen wäre. Alarmieren Sie sowohl auf die Laufflags als auch auf den Rückstand.