Die parallele Verarbeitung von inkrementellen Backups in XtraBackup reduziert die Vorbereitungszeit und verändert das I/O-Verhalten unter Last.
Das Problem tritt nicht sofort auf — bis der inkrementelle Backup aus Tausenden von .delta-Dateien besteht. In dem klassischen Modell verarbeitete XtraBackup diese sequenziell. Das bedeutete hohe Overheadkosten pro Datei und ein lineares Wachstum der Zeit in der Vorbereitungsphase. Bei großen Installationen mit vielen Tabellen (.ibd) wurde die Vorbereitung zum Engpass und verlangsamte die Wiederherstellung (Wiederherstellungszeit).
Die Lösung besteht darin, Parallelität in die Phase der Anwendung von Änderungen einzuführen. In den Versionen XtraBackup 8.0.35-33 und 8.4.0-3 wurde das Flag –parallel für den Befehl xtrabackup –prepare –apply-log-only eingeführt. Jetzt scannt das System zunächst das Backup-Verzeichnis und erstellt eine Warteschlange von .delta-Dateien. Dann verarbeiten mehrere Threads diese Warteschlange parallel. Dies ist ein Kompromiss: Die Beschleunigung wird durch eine erhöhte Konkurrenz um die Festplatte (Disk I/O) und Overheadkosten für das Thread-Management erreicht.
Die Implementierung hat das Ausführungsmodell selbst verändert. Früher wurde die Datei sofort nach der Entdeckung verarbeitet. Jetzt wird eine explizite Aufgabenwarteschlange eingeführt. Jeder Thread liest die .delta-Datei und wendet die Änderungen auf die entsprechende InnoDB-Datei (.ibd) an. Dies skaliert besser bei einer großen Anzahl kleiner Dateien. Bei einer geringeren Anzahl oder größeren Dateien ist der Effekt begrenzt. Nach etwa 16 Threads kann die Leistung auf ein Plateau ansteigen oder sogar aufgrund von Overhead leicht abnehmen.
Die Ergebnisse zeigen, dass der Gewinn von der Struktur des Backups abhängt. In einem Szenario mit 20.608 Dateien von 2,5 MB führte die Erhöhung von –parallel von 1 auf 64 zu einem Anstieg der Disk Write IOPS von 18,2K auf 85K. Die Vorbereitungszeit wurde von 3,76 Minuten auf etwa eine Minute verkürzt. Das entspricht einer Beschleunigung von etwa 3,5x bei einem Anstieg des I/O um das 4,67-fache. In einem anderen Fall wurde die Zeit von 237 Minuten auf 6 Minuten verkürzt, was bis zu 40x Beschleunigung ergibt. Es gibt keinen universellen Wert, aber ein praktischer Ausgangspunkt sind 8 Threads.
Es ist wichtig, die Kausalität zu verstehen: Die Beschleunigung wird nicht durch „Magie“ erreicht, sondern durch eine bessere Auslastung der Festplatte und die Parallelisierung kleinerer Operationen. Wenn das System bereits an die Grenzen der IOPS oder CPU stößt, wird ein Anstieg von –parallel nicht helfen. Unter solchen Bedingungen kann sogar ein Rückgang möglich sein. Dies ist ein typischer Trade-off zwischen der Latenz einzelner Operationen und dem gesamten Durchsatz des Systems.
Aus Sicht des Betriebs verschiebt diese Änderung den Fokus der Anpassung. Früher war die Struktur des Backups der Schlüsselfaktor. Jetzt ist es das Gleichgewicht zwischen der Anzahl der Threads und den Möglichkeiten des Speichers. Die Beobachtbarkeit (observability) durch IOPS-Metriken wird entscheidend für die Auswahl des optimalen Wertes.
In der Branche wird dieser Ansatz seit langem für Aufgaben mit einer hohen Anzahl kleiner Dateien verwendet. XtraBackup holt faktisch dieses Muster nach. Es handelt sich um eine evolutionäre Verbesserung, die ein echtes Engpassproblem löst, ohne das Backup-Format zu ändern.