MySQL-Replikation. Matthias Jung ORDIX AG Wiesbaden. MySQL, Replikation, Lastverteilung, Verfügbarkeitskonzepte, Backup & Recovery

Transkript

1 MySQL-Replikation Matthias Jung ORDIX AG Wiesbaden Schlüsselworte: MySQL, Replikation, Lastverteilung, Verfügbarkeitskonzepte, Backup & Recovery Einleitung In den letzten Wochen und Monaten hat das freie Datenbankprodukt MySQL zunehmend an Bedeutung gewonnen. Immer mehr Kunden entscheiden sich dafür, MySQL als Alternative zu den im professionellen Bereich etablierten Datenbankprodukten einzusetzen. Ein unter vielen Gesichtspunkten spannendes Thema ist die Replikation. Sie kann für viele Zwecke sinnvoll eingesetzt werden und soll im Folgenden näher vorgestellt werden. Einführung MySQL ist das wohl bekannteste und am häufigsten genutzte Open-Soure-Datenbankprodukt derzeit. Neben der Open-Source-Variante sind jedoch auch kommerzielle Editionen von Oracle verfügbar. In den letzten Monaten ist ein deutlich gesteigertes Interesse im Beratungsumfeld spürbar. Abb. 1: Einführung MSQL Ein Blick auf die Entwicklungsgeschichte belegt die kontinuierliche Weiterentwicklung von MySQL. Mit nahezu jedem Release wurden neue Features in das Produkt aufgenommen. Das Erscheinungsbild von MySQL ist heutzutage extrem professionell. Neben den erfreulichen Weiterentwicklungen am Datenbankserver sind mittlerweile auch viele interessante Zusatzprodukte verfügbar, die das Gesamtbild abrunden: MySQL Enterprise Backup MySQL Enterprise Monitor MySQL Workbench

2 Abb. 2: Geschichte von MySQL MySQL unterscheidet sich in einem Punkt eklatant von den meisten anderen Datenbankprodukten: durch die Vielzahl der vorhandenen Storage Engines (Speichersubsysteme). Diese, auch Tabellen- Typen genannten, Plugins kümmern sich um die physikalische Verwaltung der eigentlichen Daten und sind mit bestimmen Funktionen verknüpft. So gibt es Engines, die beispielsweise Daten nur im Speicher halten. Andere Engines unterstützen keine Transaktionen und / oder referentielle Integrität. Die Wahl einer Engine kann demnach auch Einfluss auf das gewählte Backup-Verfahren haben. So eignen sich zum Beispiel manche Werkzeuge nicht für die Sicherung der einen oder anderen Storage Engine. Abb.3: Storage Engines Überblick MySQL-Replikation Wissenschaftlich handelt es sich bei einer Replikation oder Reduplikation um die Vervielfältigung von Informationen (hier natürlich Erbinformationsträgern). Auch im Rahmen von Datenbanken geht es um die Vervielfältigung von Informationen. Konkret geht es um die Übertragung des Datenbestandes eines führenden Systems (im MySQL- Jargon: Master) auf ein oder mehrere nachgelagerte Systeme (Slaves). In aller Regel verläuft die Datenübertragung jedoch nicht synchron (vergl. Cluster-Systeme). Der Replikationsprozess findet

3 nachgelagert statt. Dies bedeutet, dass das führende System und damit die dort arbeitenden Clients / User nicht auf die Übertragung ihrer Transaktionen / Daten auf die Slave-Systeme warten. Abb.4: MySQL-Replikation Der Aufbau einer Replikation kann die unterschiedlichsten Formen annehmen. Klassisch ist die unidirektionale Replikation von einem Master- auf ein Slave-System. Gängig sind aber auch mehrstufige baumartige Strukturen oder Ringe. Seltener eingesetzt werden bidirektionale Replikationen (gerade bei identischen Datenstrukturen / Datenbanken), da die Gewährleistung der logischen Datenkonsistenz eher schwierig ist. Das Koppeln eines Slave-Systems an mehrere Master (einer Art zentrales Slave) ist mit MySQL- Mitteln derzeit nicht möglich. Abb.5: Aufbau einer Replikation Die Funktionsweise der Replikation bei MySQL ist recht einfach. Anders als z.b. bei einer Oracle Datenbank können hier nicht einfach die generierten Transaktionsprotokolle an das Slave-System gesendet werden. Da MySQL wie bereits in der Einführung erwähnt auch Storage Engines ohne Transaktionsverhalten besitzt, ist dies kein gangbarer Weg.

4 Aus diesem Grund wurde eine Art generisches Transaktionsprotokoll (das Binary Log) eingeführt. In diesem binären Logfile werden alle Statements protokolliert, die Änderungen an den Daten und / oder den dahinterstehenden Strukturen vornehmen (DML, DDL, DCL). Der Slave überträgt diese Daten sofern möglich permanent in einer Art Schattenkopie dieses Logfile (das Relay Log). Aus diesem kopierten Logfile extrahiert der Slave die aufgezeichneten SQL- Statements und spielt diese gegen den eigenen Datenbestand ein. Abb.6: Funktionweise einer Replikation Abb.7: Funktionweise einer Replikation, grafische Darstellung Die beiden vom Slave gesteuerten Prozesse (I/O-Thread: Kopieren der Log-Informationen auf das Slave-System; SQL-Thread: Einspielen der Statements aus dem Relay Log) können separat gesteuert werden. Darüber hinaus stehen Konfigurationsparameter für das Housekeeping der erstellten Log- Dateien zur Verfügung. Zusätzlich bietet MySQL ein kleines Werkzeug an, mit dessen Hilfe eine Art Logmining aus den Binary- und / oder Relay Logs vorgenommen werden kann. Dieses Tool kann z.b. eingesetzt werden, um im Rahmen eines Backup-Konzeptes ein Recovery eines Voll-Backups vorzunehmen (siehe Vortrag DOAG 2010).

5 Abb.8: Die Prozesse Generell sind für die Einrichtung einer Replikation nur wenige Kommandos und Konfigurationseinstellungen notwendig. Gerade auf dem Slave-System gibt es jedoch einige Parameter, mit deren Hilfe sich der Repliaktionsstrom des Master ein wenig reduzieren lässt. So können z.b. gezielt Filterkriterien für bestimmte Datenbanken und / oder Tabellen eingerichtet werden. Leider ist dies derzeit nicht für logische Filter (z.b. auf SQL-Ausdrücken basierende Filter, wie Repliziere nur die Datensätze der Tabelle mitarbeiter wo die Abteilungsnr <> 10 ist ) möglich. Abb.9: Einstellungen auf dem Slave Einsatzgebiete Wie bereits in der Einleitung erwähnt, kann der Mechanismus der Replikation für die unterschiedlichsten Zwecke eingesetzt werden. Lastverteilung (Scale-out-Lösungen) Im Rahmen eines Backup-Konzeptes (sehr häufiger Einsatz) Im Rahmen von Verfügbarkeitskonzepten Reporting-Systeme Datenübertragung über weite Systeme Versorgung von Datawarehouse-Systemen / Datenarchivierung Oftmals werden Replikationen eingesetzt, um Performance-Probleme zu lösen. Dies funktioniert allerdings nur, wenn diese durch eine hohe Leselast erzeugt werden. In einem solchen Fall können mehrere Slaves bereitgestellt werden, um die Anforderungen der Clients zu bedienen. Die Separierung der Anfragen (DML und Queries) muss in einem solchen Konstrukt durch eine vorgeschaltete Instanz (MySQL Proxy, Applikationsserver usw.) erfolgen.

6 Darüber hinaus muss sehr sorgfältig überwacht werden, dass Änderungen (DMLs) zeitnah auch auf den Slave-Systemen etabliert werden (Performance der Replikation). Abb.10: Scale-Out-Lösungen: Lastverteilung über mehrere Slaves Auch im Rahmen von Ausfall- und Backup-Konzepten kann eine Replikation sinnvoll eingesetzt werden. So kann ein Slave-System z.b. genutzt werden, um in aller Ruhe Backups / Dumps des Server zu ziehen. Um einen konsistenten / eingefrorenen Zustand zu erhalten, muss lediglich der SQL-Thread des Slave gestoppt werden. Parallel können solche Infrastrukturen auch genutzt werden, um sich gegen den Ausfall des Master zu schützen. Die Clients greifen generell über eine, auf dem Master aktive, virtuelle IP-Adresse zu. Fällt der Master aus, so wird diese virtuelle IP-Adresse auf dem Slave-System geschaltet. Nach diesem Schwenk können die Clients mit einem (hoffentlich) identischen Datenbestand weiterarbeiten. Abb.11: Daten-/Ausfallsicherheit Eine Abwandlung der Scale-out-Lösung ist die Einrichtung eines Reporting Server. Auch in diesem Fall werden die Daten von einem Master auf einen oder mehrere Slaves repliziert. Im Bedarfsfall kann auch hier der Datenbestand durch das Stoppen des SQL-Threads eingefroren werden, um konsistente Reports über einen längeren Zeitraum zu erhalten.

7 Abb.12: Reporting Natürlich kann eine Replikation auch einfach nur eingesetzt werden, um Daten über eine längere Strecke von A nach B zu schaffen (z.b. zwei weit entfernte Rechenzentren). Abb.13: Datenübertragung über weite Strecken Manchmal können mit der Replikation auch sehr spezielle Anforderungen gelöst werden. Beispielsweise suchte ein Kunde eine Möglichkeit, um direkt aus einem produktiven System ein Archivsystem zu betanken. Auf dem produktiven System sollten lediglich die Daten des letzten Jahres verwahrt werden (Performance), während auf dem Archivsystem alle Daten zur Verfügung stehen sollten. Gelöst wurde diese Versorgung über eine Kombination von Partitionierung und Replikation. Die zyklisch auf dem produktiven System neu angelegten Partitionen und neuen Daten wurden 1:1 auf das Slave-System übertragen. Das Löschen von überzähligen Partitionen wurde durch die Verwendung der Session-Variable (SQL_LOG_BIN) jedoch gefiltert. Abb.14:Versorgung von Datawarehouse-Systemen / Datenarchivierung

8 Neuerungen Mit der aktuellen Version 5.5 wurden einige Erweiterungen am Replikationsmechanismus vorgenommen. Während bislang die Replikation immer asynchron zu den Aktivitäten auf dem Master erfolgte, kann nun wahlweise auch eine semisynchrone Replikation eingesetzt werden. Semisynchron bedeutet, dass die Session des Master im Rahmen eines vereinbarten Zeitfensters auf die Übertragung der Transaktion auf mindestens einen Slave wartet. Dabei ist entscheidend, dass die Daten der Transaktion im Relay Log eines Slave persistiert wurden. Dies bedeutet nicht, dass die Daten der Transaktion bereits in einem Slave-System angekommen sind (Apply muss noch nicht erfolgt sein). Die Nutzung dieses neuen Features ist recht einfach. Die semisynchrone Replikation wird als Plugin bereitgestellt und muss als solche auf allen beteiligten Systemen eingebunden und aktiviert werden. Zusätzlich kann auf dem Master das Timeout-Intervall festgelegt werden. Wird das vereinbarte Intervall von keinem Slave eingehalten, so schaltet der Master automatisch auf die asynchrone Repliaktion zurück. So soll der Stillstand einer Applikation vermieden werden. Ein solcher Fallback wird durch entsprechende Einträge im Fehlerprotokoll des Master deutlich protokolliert. Die Verwendung einer semisynchronen Replikation ist damit also sehr sorgsam zu überwachen. Abb.15: Installation semisynchrone Replikation Ebenfalls neu (ab der Version 5.6) ist die Einführung eines Replication Delay, wie man es ggf. von Oracle bereits kennt. Die Einrichtung des Delay erfolgt über die bekannte change master -Syntax und kann jederzeit online neu erfolgen (Start & Stop des Slave ist lediglich erforderlich). Bis dato konnte für solche Zwecke das Skript-Framework Maatkit eingesetzt werden. Hierbei handelt es sich um ein Perl-Skript, welches die Einträge (Zeitstempel) im Relay Log auswertet und auf Grundlage dieser Informationen den SQL-Thread entsprechend steuerte.

9 Abb.16: Replication Delay Fazit Die MySQL-Repliaktion ist ein einfach und sinnvoll einzusetzendes Feature, welches sich bereits über viele Jahre etabliert hat. Es ermöglicht die Lösung von unterschiedlichen Problemstellungen. Die Erweiterungen der letzten Releases (semisynchrone Repliaktion und Delay) sind eine willkommene und sinnvolle Ergänzung zu den bestehenden Features. Allerdings gibt es immer noch offene Probleme, wie z.b. das logische Filtern von Inhalten und eine Multi-Master-Replikation. Für diese Fälle gibt es aber bereits Lösungen am Markt: Tungsten Replicator Oracle Golden Gate Kontaktadresse: Matthias Jung ORDIX AG Westernmauer D Paderborn Telefon: +49 (0) 5251 / Fax: +49 (0) 1801 / info@ordix.de Internet: