Das MySQL Clone-Plugin: schnelles Provisioning neuer Replicas

1. Das Provisionierungsproblem bei großen Magento-Datenbanken

Ein neuer Replica benötigt zu Beginn einen konsistenten, vollständigen Datenbestand des Primärservers, bevor er über die reguläre Replikation mit laufenden Änderungen synchron gehalten werden kann. Klassisch geschah das über mysqldump mit anschließendem logischem Import, ein Verfahren, das bei jeder einzelnen Zeile einen vollständigen INSERT-Befehl samt Indexpflege durchläuft und bei einer 200-Gigabyte-Datenbank ohne weiteres viele Stunden dauern kann.

Externe Werkzeuge wie Perconas xtrabackup lösten dieses Problem bereits deutlich schneller über einen physischen Kopiervorgang der zugrunde liegenden Datendateien, benötigten dafür aber eine separate Installation, eigene Berechtigungen auf Betriebssystemebene und einen zusätzlichen Prepare-Schritt nach dem eigentlichen Kopieren. Genau diese Lücke schließt das seit MySQL 8.0.17 verfügbare, vollständig in den Server integrierte Clone-Plugin.

2. Was CLONE INSTANCE technisch macht: physisch statt logisch

Der entscheidende technische Unterschied zu mysqldump liegt darin, dass das Clone-Plugin keine SQL-Anweisungen generiert und keine Zeile für Zeile neu einfügt, sondern direkt die zugrunde liegenden InnoDB-Datendateien auf Seitenebene kopiert, exakt so, wie sie physisch auf der Festplatte des Spenderservers vorliegen. Indizes müssen dadurch nicht neu aufgebaut werden, weil sie in genau der Form übertragen werden, in der sie beim Spender bereits existieren.

Damit unterscheidet sich der Ansatz fundamental von einem logischen Dump, der Struktur und Daten getrennt betrachtet und beim Import jede Tabelle, jeden Index und jede Fremdschlüsselbeziehung faktisch neu erschafft. Der physische Ansatz ist deutlich näher an einem klassischen Dateisystem-Snapshot, bringt aber gegenüber einem reinen Snapshot den Vorteil mit, dass er direkt über eine reguläre Netzwerkverbindung zwischen zwei laufenden MySQL-Servern funktioniert, ohne Zugriff auf die Betriebssystemebene des Spenderservers zu benötigen.

3. Voraussetzungen und Installation des Clone-Plugins

Das Clone-Plugin muss sowohl auf dem Spenderserver, dem sogenannten Donor, als auch auf dem Empfängerserver, dem Recipient, installiert sein. Beide Instanzen benötigen zusätzlich einen Datenbankbenutzer mit dem Recht BACKUP_ADMIN, das speziell für Clone-Operationen eingeführt wurde, sowie auf dem Donor eine über clone_valid_donor_list explizit freigegebene Netzwerkadresse des Recipient-Servers.

Diese explizite Whitelist ist ein bewusstes Sicherheitsmerkmal: ohne einen entsprechenden Eintrag verweigert der Donor jede eingehende Clone-Anfrage, selbst bei korrekten Zugangsdaten. Für produktive Umgebungen empfiehlt sich außerdem eine verschlüsselte Verbindung zwischen beiden Servern, da während des Klonvorgangs potenziell sensible Kundendaten unverschlüsselt über das Netzwerk übertragen würden, sofern SSL nicht explizit erzwungen ist.

-- Clone-Plugin auf Donor und Recipient installieren
INSTALL PLUGIN clone SONAME 'mysql_clone.so';

-- Recipient-Adresse auf dem Donor explizit freigeben
SET GLOBAL clone_valid_donor_list = 'db-replica-neu.internal:3306';

-- Benutzer mit den für Clone-Operationen noetigen Rechten anlegen
CREATE USER 'clone_user'@'%' IDENTIFIED BY 'ein-sicheres-passwort';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%';

4. Der Klonvorgang Schritt für Schritt

Der eigentliche Klonvorgang wird auf dem Recipient mit dem Befehl CLONE INSTANCE FROM gestartet und durchläuft mehrere interne Phasen: zunächst eine Dateikopie-Phase, in der die Rohdaten der InnoDB-Tablespaces übertragen werden, gefolgt von einer Seitenkopie-Phase, die während der Übertragung parallel entstandene Änderungen auf dem Donor nachträgt, und schließlich eine Redo-Kopie-Phase, die den letzten konsistenten Zustand über den Redo-Log sicherstellt.

Nach erfolgreichem Abschluss startet sich der Recipient-Server automatisch neu und kommt anschließend mit exakt dem Datenbestand hoch, der zum Abschlusszeitpunkt des Klonvorgangs auf dem Donor vorlag. Aus Sicht des Administrators ist der gesamte Vorgang ein einziger SQL-Befehl, der Server kümmert sich intern um alle Details der Konsistenzsicherung.

-- Auf dem leeren Recipient-Server ausführen
CLONE INSTANCE FROM 'clone_user'@'db-primary.internal':3306
  IDENTIFIED BY 'ein-sicheres-passwort';

-- Fortschritt des laufenden Klonvorgangs beobachten
SELECT STAGE, STATE, BEGIN_TIME, END_TIME
FROM performance_schema.clone_progress;

5. Automatische Replikations-Konfiguration nach dem Klon

Ein besonders praktischer Vorteil des Clone-Plugins gegenüber einem reinen Dateikopiervorgang: der Server merkt sich während des Klonens automatisch die exakte GTID-Position, an der der Datenbestand auf dem Donor konsistent war, in der internen Tabelle mysql.clone_status. Diese Position lässt sich direkt für den Aufbau der Replikationsverbindung verwenden, ganz ohne manuelles Ermitteln eines Binlog-Dateinamens und einer Byte-Position.

Ist GTID-basierte Replikation aktiviert, reicht danach ein einziger CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION=1-Befehl, um den frisch geklonten Recipient nahtlos an die laufende Replikationskette anzuschließen. Der Server ermittelt die passende Startposition selbstständig, was gegenüber der klassischen, fehleranfälligen manuellen Positionsbestimmung bei einem mysqldump-basierten Aufbau einen erheblichen praktischen Vorteil darstellt.

6. Geschwindigkeitsvergleich zum mysqldump-basierten Replica-Aufbau

Der Geschwindigkeitsunterschied zwischen einem physischen Klon und einem logischen mysqldump-Import wächst mit der Datenbankgröße überproportional. Während ein mysqldump-Import bei jeder Zeile einen vollständigen INSERT samt Indexaktualisierung durchläuft und bei großen Tabellen zusätzlich unter dem Overhead von Transaktionslogs leidet, überträgt das Clone-Plugin die bereits fertig indizierten Datenseiten direkt, ohne jede Zeile einzeln zu verarbeiten.

Bei einer realistischen, mehrere hundert Gigabyte großen Magento-Produktionsdatenbank bedeutet das in der Praxis häufig den Unterschied zwischen einem mysqldump-Import, der über Nacht läuft, und einem Klonvorgang, der je nach verfügbarer Netzwerkbandbreite in ein bis zwei Stunden abgeschlossen ist. Die tatsächliche Dauer hängt dabei primär von der Netzwerkbandbreite zwischen Donor und Recipient ab, nicht von der Zeilenzahl der größten Tabellen.

7. Geschwindigkeitsvergleich zu xtrabackup

Gegenüber xtrabackup ist der reine Übertragungsmechanismus ähnlich, beide kopieren physische InnoDB-Seiten statt logischer SQL-Anweisungen. Der praktische Unterschied liegt vor allem in der Integration: das Clone-Plugin benötigt keine separate Installation eines externen Pakets, keine eigene Konfigurationsdatei und keinen zusätzlichen, manuell auszuführenden Prepare-Schritt, der bei xtrabackup nötig ist, um die kopierten Dateien in einen konsistenten, startfähigen Zustand zu bringen.

Dieser Prepare-Schritt entfällt beim Clone-Plugin, weil die Redo-Kopie-Phase bereits während des eigentlichen Klonvorgangs für einen konsistenten Endzustand sorgt. Für Teams, die xtrabackup bereits produktiv im Einsatz haben und mit dessen inkrementellen Backup-Möglichkeiten arbeiten, bleibt es weiterhin relevant, für die reine Aufgabe des schnellen Replica-Provisionings ist das Clone-Plugin jedoch die einfachere, da vollständig serverintegrierte Alternative.

8. Einschränkungen: nur InnoDB und gleiche Version

Das Clone-Plugin kopiert ausschließlich InnoDB-Tabellen, andere Storage Engines wie MyISAM werden beim Klonvorgang nicht mit übertragen. Für Magento-Shops mit einer sauberen, deklarativen Schema-Struktur, die praktisch ausschließlich auf InnoDB setzt, ist das in der Regel unkritisch, bei älteren, aus Magento-1-Zeiten migrierten Installationen mit vereinzelten MyISAM-Resttabellen lohnt sich jedoch eine vorherige Prüfung, welche Tabellen betroffen wären.

Eine weitere zentrale Einschränkung betrifft die Versionskompatibilität: Donor und Recipient müssen entweder exakt dieselbe MySQL-Version oder zumindest kompatible Versionen innerhalb derselben Major-Release-Linie verwenden, da sich das interne Format des Redo-Logs und des Undo-Logs zwischen Versionen unterscheiden kann. Ein Klonen von einer MySQL-8.0-Instanz auf eine ältere 5.7-Instanz wird vom Plugin von vornherein verweigert.

9. Praktische Stolperfallen beim produktiven Einsatz

Ein häufiger Stolperstein ist unkontrollierte Netzwerkbandbreitennutzung: ein Klonvorgang kann während der Dateikopie-Phase die verfügbare Netzwerkbandbreite zwischen Donor und Recipient nahezu vollständig auslasten, was bei einem produktiven Donor-Server zu spürbaren Latenzproblemen für die normale Anwendungslast führen kann. Über die Systemvariable clone_max_data_bandwidth lässt sich der Klonvorgang gezielt drosseln, um diesen Effekt zu vermeiden.

Zusätzlich sollte der Recipient-Server vor dem Klonen tatsächlich leer sein, ein Klonen in ein bereits initialisiertes, produktiv genutztes Datenverzeichnis wird vom Server verweigert. Bei einer fehlgeschlagenen oder abgebrochenen Klon-Operation, etwa durch einen Netzwerkausfall, lässt sich über die Tabellen performance_schema.clone_status und clone_progress genau nachvollziehen, in welcher Phase der Abbruch erfolgte, bevor ein erneuter Versuch gestartet wird.

10. Zusammenfassung

11. FAQ: MySQL Clone-Plugin für Replica-Provisioning