Geteiltes Backup

Bei einer Split-Backup-Strategie migrieren Sie einen großen Datenbankserver, indem Sie das Backup in mehrere Teile aufteilen. Sie können unterschiedliche Ansätze verwenden, um jeden Teil des Backups zu migrieren. Dies kann die beste Option für die folgenden Anwendungsfälle sein:

• Großer Datenbankserver, aber kleine Einzeldatenbanken — Dies ist ein guter Ansatz, wenn die Größe des gesamten Datenbankservers mehrere TB beträgt, die Größe jeder einzelnen, unabhängigen Benutzerdatenbank jedoch weniger als 1 TB beträgt. Um den Gesamtmigrationszeitraum zu verkürzen, können Sie einzelne Datenbanken separat und parallel migrieren.

  Lassen Sie uns ein Beispiel für einen lokalen Datenbankserver mit 2 TB verwenden. Dieser Server besteht aus vier Datenbanken mit jeweils 0,5 TB. Sie können Backups jeder einzelnen Datenbank separat erstellen. Beim Wiederherstellen der Sicherung können Sie entweder alle Datenbanken auf einer Instanz parallel wiederherstellen, oder wenn die Datenbanken unabhängig sind, können Sie jede Sicherung auf einer separaten Instanz wiederherstellen. Es hat sich bewährt, unabhängige Datenbanken auf separaten Instanzen wiederherzustellen, anstatt sie auf derselben Instanz wiederherzustellen. Weitere Informationen finden Sie unter Bewährte Methoden in diesem Handbuch.

• Großer Datenbankserver, aber kleine einzelne Datenbanktabellen — Dies ist ein guter Ansatz, wenn die Größe des gesamten Datenbankservers mehrere TB beträgt, die Größe jeder unabhängigen Datenbanktabelle jedoch weniger als 1 TB beträgt. Um den Gesamtmigrationszeitraum zu verkürzen, können Sie unabhängige Tabellen einzeln migrieren.

  Lassen Sie uns ein Beispiel für eine Einzelbenutzerdatenbank verwenden, die 1 TB groß ist und die einzige Datenbank auf einem lokalen Datenbankserver ist. Die Datenbank enthält 10 Tabellen, von denen jede 100 GB groß ist. Sie können Backups jeder einzelnen Tabelle separat erstellen. Beim Wiederherstellen des Backups können Sie alle Tabellen auf einer Instanz parallel wiederherstellen.

• Eine Datenbank enthält sowohl transaktionale als auch nicht-transaktionale Workload-Tabellen. Ähnlich wie im vorherigen Anwendungsfall können Sie einen Split-Backup-Ansatz verwenden, wenn Sie sowohl transaktionale als auch nicht-transaktionale Workload-Tabellen in derselben Datenbank haben.

  Lassen Sie uns ein Beispiel für eine 2-TB-Datenbank verwenden, die aus 0,5 TB an Tabellen für kritische Workloads besteht, die für die Online-Transaktionsverarbeitung (OLTP) verwendet werden, und einer einzelnen 1,5-TB-Tabelle, die für die Archivierung alter Daten verwendet wird. Sie können die Sicherung aller Datenbankobjekte mit Ausnahme der Archivtabelle als konsistente Sicherung mit einer einzigen Transaktion durchführen. Dann erstellen Sie eine weitere, separate Sicherung nur der Archivtabelle. Für die Sicherung der Archivtabelle können Sie auch erwägen, mehrere parallel Sicherungen zu erstellen, indem Sie Bedingungen verwenden, um die Anzahl der Zeilen in der Sicherungsdatei aufzuteilen. Im Folgenden wird ein Beispiel gezeigt:

  mysqldump -p your_db1 --tables your_table1 --where=“column1 between 1 and 1000000 " > your_table1_part1.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 between 1000001 and 2000000 " > your_table1_part2.sql
  mysqldump -p your_db1 --tables your_table1 --where="column1 > 2000000 " > your_table1_part3.sql

  Beim Wiederherstellen der Sicherungsdateien können Sie die transaktionale Workload-Backup und die Sicherung der Archivtabelle parallel wiederherstellen.

• Einschränkungen der Rechenressourcen — Wenn Sie auf dem lokalen Server nur begrenzte Rechenressourcen wie CPU, Arbeitsspeicher oder Festplatten-I/O haben, kann dies die Stabilität und Leistung bei der Erstellung des Backups beeinträchtigen. Anstatt ein vollständiges Backup zu erstellen, können Sie es in Teile aufteilen.

  Beispielsweise kann ein lokaler Produktionsserver stark mit Workloads belastet sein und über begrenzte CPU-Ressourcen verfügen. Wenn Sie ein Backup einer Datenbank mit mehreren Terabyte auf diesem Server in einem einzigen Durchlauf erstellen, kann dies zusätzliche CPU-Ressourcen verbrauchen und sich negativ auf den Produktionsserver auswirken. Anstatt die gesamte Datenbanksicherung zu erstellen, teilen Sie die Sicherung in mehrere Teile auf, z. B. jeweils 2—3 Tabellen.