Bereits seit dem 15. Dezember gibt es die aktuelle GA Release von MySQL in der Version 5.5. Obwohl ein großer Nutzerkreis der Datenbank, nach Installation und Anlage von Benutzern, häufig keine größere Aufmerksamkeit zukommen lässt, lohnt es sich durchaus einen genaueren Blick auf die neuen Features zu werfen. In den nächsten Woche werde ich die aus meiner Sicht wichtigsten Themen zusammenfassen und Euch zum Wochenende damit beglücken.
Starten möchte ich die Serie mit einer kleinen Einführung in die Semisynchronous Replication. Dieses von vielen lang erwartete Feature löst den bisher nicht vorhandenen Transaktionskontext über verteilte Replikationsumgebungen nun endlich auf. Aber was heisst das nun genau?
In einer normalen (synchronen) Replikationsumgebung schreibt die Master-DB alle Änderungen in lokale Binlogs und schert sich nicht über die weitere Bearbeitung durch einen oder mehrer Slaves. Diese Entkopplung zwischen Spooling der Änderungsdaten und spätere Einarbeitung in den Slaves bietet zwar einen Performancevorteil, kann bei Ausfall des Masters im weiteren Verlauf jedoch den Verlust von Daten zur Folge haben.
Wenn in einer Datenbankumgebung transaktionsorientiert gearbeitet wird, also mit autocommit=0 oder Initierung durch den Befehl start transaction, hat dies zur Folge, dass erst nach dem nächsten Commit die Daten für alle anderen Benutzer sichtbar geschrieben werden. Voraussetzung hierfür ist der Einsatz von InnoDB, welche seit Version 5.5 auch Standard-Engine, und die  ACID-Kriterien erfüllt. Sobald der Benutzer den Commit abgesetzt hat, werden die Daten geschrieben und für das lokale System ist die Integrität hergestellt. Was aber wenn ein angeschlossener DB-Slave die Daten noch nicht eingearbeitet hat und es nun zu einem Ausfall des Masters kommt? Genau hier setzt die Semisynchronous Replication an. Bei Aktivierung, welcher für Master und Slave erforderlich ist, bekommt der Benutzer erst dann einen Status “committed” wenn die Transaktion auf mindestens einem Slave eingearbeitet ist. So kann auch in verteilten Umgebungen die Integrität auf mindestens einem weiteren Knoten sichergestellt werden. Bei Ausfall aller Slaves springt die Datenbank nach einem gewissen Timeout in die normale (synchrone) Replikation zurück und stellt so trotzdem die Verfügbarkeit sicher. Sobald wieder ein Slave verfügbar ist, wird natürlich wieder die Semisynchronous Replication verwendet. Über einige neue Servervariablen kann der Admin auch die entsprechenden Transaktionen im System sichtbar machen. So gibt die Variable Rpl_semi_sync_master_no_tx beispielsweise Auskunft über noch offene Transaktionen, welche noch nicht auf einem Slave committed wurden.
Für alle, denen eine replikationsübergreifende Transaktionssicherheit wichtig ist, ist dieses Feature ein Muss.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.