Überlegungen zu Datenintegrität und Leistung bei der semisynchronen MySQL-Replikation

Die semisynchrone MySQL-Replikation bietet eine verbesserte Datenintegrität, denn wenn ein Commit erfolgreich zurückgegeben wird, ist bekannt, dass die Daten an mindestens zwei Orten vorhanden sind – dem Master und seinem Slave. In diesem Blogbeitrag überprüfen wir einige der MySQL-Hosting-Konfigurationen, die die Datenintegrität und Leistungsaspekte der semisynchronen Replikation beeinflussen. Wir werden die InnoDB-Speicher-Engine und die GTID-basierte Replikation in einem 3-Knoten-Replik-Set (Master und 2 Slaves) verwenden, wodurch Redundanz in den Slaves sichergestellt wird. Das bedeutet, dass wir bei Problemen mit einem Slave auf den anderen zurückgreifen können.

Auf Master- und Slave-Knoten anwendbare Konfigurationen

• innodb_flust_log_at_trx_commit =1
• sync_binlog =1

Diese Konfigurationen garantieren hohe Dauerhaftigkeit und Konsistenzeinstellungen für Daten. Das heißt, dass jede festgeschriebene Transaktion garantiert in Binärprotokollen vorhanden ist und die Protokolle auch auf die Festplatte geschrieben werden. Somit bleibt die Datenkonsistenz von MySQL bei Stromausfall oder Betriebssystemabsturz immer erhalten.

Konfigurationen auf dem Master-Knoten.

• rpl_semi_sync_master_wait_for_slave_count:

Diese Option wird verwendet, um die Anzahl der Slaves zu konfigurieren, die eine Bestätigung senden müssen, bevor ein semisynchroner Master die Transaktion festschreiben kann. Im 3-Knoten-Replikatsatz empfehlen wir, dies auf 1 zu setzen, damit wir immer sicher sein können, dass die Daten in mindestens einem Slave verfügbar sind, und gleichzeitig Leistungseinbußen beim Warten auf die Bestätigung von beiden Slaves vermeiden.

• rpl_semi_sync_master_timeout:

Diese Option wird verwendet, um die Zeitspanne zu konfigurieren, die ein semisynchroner Master auf die Slave-Bestätigung wartet, bevor er zurück in den asynchronen Modus wechselt. Wir empfehlen, dies auf eine große Zahl einzustellen, damit kein Fallback auf den asynchronen Modus erfolgt, der dann unser Ziel der Datenintegrität zunichte macht. Da wir mit 2 Slaves arbeiten und rpl_semi_sync_master_wait_for_slave_count auf 1 gesetzt ist, können wir davon ausgehen, dass mindestens einer der Slaves innerhalb einer angemessenen Zeitspanne bestätigt, wodurch die Auswirkungen dieser Einstellung auf die Leistung minimiert werden.

Konfigurationen auf den Slave-Knoten

In den Slaves ist es immer wichtig, zwei Positionen sehr genau zu verfolgen:die aktuell ausgeführte Position des SQL-Threads im Relay-Log und die aktuelle Position des IO-Threads, die angibt, wie weit Die Mater-Binärdatei wird gelesen und auf den Slave kopiert. Die Folgen einer Nichteinhaltung dieser Positionen liegen auf der Hand. Wenn ein Slave abstürzt und neu gestartet wird, kann der SQL-Thread mit der Verarbeitung von Transaktionen an einem falschen Offset beginnen oder der IO-Thread kann beginnen, Daten von einer falschen Position in den Master-Binärprotokollen abzurufen. Beide Fälle führen zu Datenkorruption.

Es ist wichtig, die Crash-Sicherheit von Slaves durch die folgenden Konfigurationen zu gewährleisten:

• relay_log_info_repository =TABELLE
• relay_log_recovery =EIN

Das Setzen von relay_log_info_repository auf TABLE stellt sicher, dass die Position des SQL-Threads zusammen mit jedem Transaktions-Commit auf dem Slave aktualisiert wird. Es ist jedoch schwierig, die genaue Position des IO-Threads beizubehalten und bündig mit der Festplatte zu sein. Dies liegt daran, dass das Lesen des Master-Binärlogs und das Schreiben in das Slave-Relay-Log nicht auf Transaktionen basiert. Die Auswirkung auf die Leistung ist sehr hoch, wenn die IO-Thread-Position nach jedem Schreiben in Slave-Relay-Protokolle aktualisiert und auf die Festplatte geleert werden muss. Eine elegantere Lösung wäre, relay_log_recovery =ON zu setzen. In diesem Fall wird bei einem MySQL-Neustart angenommen, dass aktuelle Relay-Logs beschädigt sind und basierend auf der SQL-Thread-Position frisch vom Master gezogen werden.

Zu guter Letzt ist es wichtig zu beachten, dass die semisynchrone Replikation sicherstellt, dass die Daten gerade einen der Slaves „erreicht“ haben, bevor der Master die Transaktion festschreibt, und dies nicht bedeutet die Transaktionen werden auf dem Slave festgeschrieben. Daher ist es gut sicherzustellen, dass der SQL-Thread mit guter Leistung arbeitet. Im Idealfall bewegt sich der SQL-Thread Hand in Hand mit dem IO-Thread, sodass wir den Vorteil haben, dass der Slave die Transaktionen nicht nur empfängt, sondern auch festschreibt. Es wird empfohlen, eine Multi-Threaded-Slave-Konfiguration zu verwenden, damit wir eine erhöhte Slave-SQL-Thread-Leistung erzielen können. Die wichtigen Konfigurationen für Multithread-Slaves sind:

• slave_parallel_workers : Stellen Sie dies auf> 1 ein, um mehrere Slave-SQL-Thread-Worker zu aktivieren. Basierend auf der Anzahl der Threads, die auf den Master schreiben, können wir eine optimale Anzahl dafür festlegen, damit der Slave nicht verzögert.
• slave-parallel-type =LOGICAL_CLOCK
• slave-preserve-commit-order =1

Die obigen Konfigurationen versprechen Parallelität im Slave, während sie gleichzeitig die Reihenfolge der Transaktionen beibehalten, wie sie auf dem Master zu sehen sind.

Zusammenfassend lässt sich sagen, dass wir durch die Verwendung der obigen Konfigurationen auf unserem MySQL-Replik-Set in der Lage sind, eine hohe Datenintegrität zusammen mit einer optimalen Leistung aufrechtzuerhalten.

Wenn Sie Fragen haben, hinterlassen Sie uns wie immer einen Kommentar, kontaktieren Sie uns unter @scalegridio auf Twitter oder senden Sie uns eine E-Mail an den Support @scalegrid.io.