Importieren von Daten aus einer beliebigen Quelle zu einer DB-Instance von Amazon RDS für MariaDB - Amazon Relational Database Service

Importieren von Daten aus einer beliebigen Quelle zu einer DB-Instance von Amazon RDS für MariaDB

Mit Amazon RDS können Sie vorhandene MariaDB-Daten von einer beliebigen Quelle zu einer DB-Instance von RDS für MariaDB migrieren. Sie können Daten von lokalen Datenbanken, anderen Cloud-Anbietern oder vorhandenen DB-Instances von RDS für MariaDB auf Ihre Ziel-DB-Instance von RDS für MariaDB übertragen. Mit dieser Funktion können Sie Datenbanken konsolidieren, Lösungen für eine Notfallwiederherstellung implementieren oder von selbstverwalteten Datenbanken umsteigen. Zu den gängigen Szenarien gehören der Wechsel von selbst gehosteten MariaDB-Servern zu vollständig verwalteten Amazon-RDS-DB-Instances, die Konsolidierung mehrerer MariaDB-Datenbanken in eine einzige DB-Instance oder die Erstellung von Testumgebungen mit Produktionsdaten. Die folgenden Abschnitte enthalten schrittweise Anleitungen zum Importieren von MariaDB-Daten mithilfe von Methoden wie mariadb-dump, Backup-Dateien oder Replikationen.

Schritt 1: Erstellen von Flatfiles, die die zu ladenden Daten enthalten

Verwenden Sie ein gängiges Format, z. B. kommagetrennte Werte (CSV), um die zu ladenden Daten zu speichern. Jede Tabelle muss über eine eigene Datei verfügen. Sie können keine Daten für mehrere Tabellen in derselben Datei kombinieren. Geben Sie jeder Datei denselben Namen wie der zugehörigen Tabelle. Die Dateierweiterung können Sie benennen, wie Sie möchten. Wenn der Tabellenname beispielsweise sales lautet, kann der Dateiname sales.csv oder sales.txt lauten.

Ordnen Sie die Daten nach Primärschlüssel der ladenden Tabelle, sofern möglich. Dadurch werden die Ladezeiten drastisch verbessert und die Anforderungen an den Festplattenspeicher minimiert.

Die optimale Geschwindigkeit und Effizienz dieser Prozedur ist auf kleine Dateigrößen ausgelegt. Wenn die Größe einer einzelnen unkomprimierten Datei mehr als 1 GiB beträgt, teilen Sie diese in mehrere Dateien auf, die danach separat geladen werden können.

Verwenden Sie auf Unix-ähnlichen Systemen (einschließlich Linux) den split-Befehl. Der folgende Befehl teilt beispielsweise die Datei sales.csv in mehrere Dateien auf, die kleiner als 1 GiB sind. Die Teilung findet nur an Zeilenumbrüchen statt (-C 1024m). Die Namen der neuen Dateien enthalten numerische Suffixe in aufsteigender Reihenfolge. Mit dem folgenden Befehl werden beispielsweise Dateien mit Namen wie sales.part_00 und sales.part_01 erzeugt.

split -C 1024m -d sales.csv sales.part_

Ähnliche Hilfsprogramme sind auch für andere Betriebssysteme verfügbar.

Sie können die Flatfiles überall speichern. Wenn Sie die Daten in Schritt 5 laden, müssen Sie die mysql-Shell jedoch von demselben Speicherort aufrufen, an dem sich die Dateien befinden, oder beim Ausführen von LOAD DATA LOCAL INFILE den absoluten Pfad für die Dateien verwenden.

Schritt 2: Verhindern des Zugriffs von Anwendungen auf die Ziel-DB-Instance

Unterbinden Sie vor dem Starten eines großen Ladevorgangs den Zugriff jeglicher Anwendungsaktivitäten auf die Ziel-DB-Instance, in die die Daten geladen werden sollen. Wir empfehlen dies insbesondere, wenn andere Sitzungen die zu ladenden Tabellen oder die in diesen Tabellen referenzierten Tabellen verändern. Dadurch wird die Gefahr von Verstößen gegen Einschränkungen während des Ladens reduziert und zugleich die Ausführungsgeschwindigkeit des Ladevorgangs erhöht. Zudem wird es möglich, die DB-Instance im Zustand unmittelbar vor dem Ladevorgang wiederherzustellen, ohne die Änderungen durch Prozesse zu verlieren, die nicht am Ladevorgang beteiligt sind.

Unter Umständen ist dies jedoch nicht möglich oder nicht praktikabel. Wenn Sie vor dem Ladevorgang den Zugriff von Anwendungen auf die DB-Instance nicht stoppen können, führen Sie die erforderlichen Schritte aus, um die Verfügbarkeit und Integrität der Daten sicherzustellen. Die jeweiligen erforderlichen Schritte können sich stark unterscheiden, je nachdem welche besonderen Verwendungsfälle der Standortanforderungen vorliegen.

Schritt 3: Erstellen Sie einen DB-Snapshot

Wenn Sie Daten in eine neue DB-Instance laden wollen, die keine Daten enthält, können Sie diesen Schritt überspringen. Andernfalls empfehlen wir, dass Sie vor und nach dem Datenladevorgang DB-Snapshots für die Ziel-DB-Instance von Amazon RDS erstellen. Amazon-RDS-DB-Snapshots sind vollständige Backups der DB-Instance, die Sie für eine Wiederherstellung der DB-Instance auf einen bekannten Zustand verwenden können. Wenn Sie ein DB-Snapshot-I/O initiieren, werden alle Operationen in Ihrer DB-Instance augenblicklich unterbrochen, während Ihre Datenbank gesichert wird.

Wenn Sie einen DB-Snapshot unmittelbar vor dem Laden erstellen, können Sie die Datenbank bei Bedarf in ihrem Zustand vor dem Laden wiederherstellen. Ein DB-Snapshot, der sofort nach einem Ladevorgang erstellt wird, bewahrt Sie davor, die Daten bei einem Fehler erneut laden zu müssen. Sie können DB-Snapshots auch nach dem Laden verwenden, um Daten in die neuen Datenbank-Instances zu importieren.

Im folgenden Beispiel wird der AWS CLI-Befehl create-db-snapshot verwendet, um einen DB-Snapshot der Instance AcmeRDS zu erstellen und dem DB-Snapshot die Kennung "preload" zuzuweisen.

Für Linux, macOS oder Unix:

aws rds create-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload

Für Windows:

aws rds create-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload

Sie können auch die Wiederherstellung aus der DB-Snapshot-Funktionalität verwenden, um Test-DB-Instances für Testversuche zu erstellen, oder, um die Änderungen während eines Ladevorgangs rückgängig zu machen.

Bedenken Sie, dass die Wiederherstellung einer Datenbank aus einem DB-Snapshot eine neue DB-Instance erstellt, die wie alle DB-Instances über eine eindeutige Kennung und einen Endpunkt verfügt. Um die DB-Instance wiederherzustellen, ohne den Endpunkt zu ändern, löschen Sie zuerst die DB-Instance, damit Sie den Endpunkt wiederverwenden können.

Um beispielsweise eine DB-Instance für einen Testlauf oder andere Testzwecke zu erstellen, weisen Sie der DB-Instance eine eigene Kennung zu. Im Beispiel ist AcmeRDS-2" die Kennung. Das Beispiel stellt über den Endpunkt, der AcmeRDS-2 zugeordnet ist, eine Verbindung mit der DB-Instance her. Weitere Informationen finden Sie unter restore-db-instance-from-db-snapshot.

Für Linux, macOS oder Unix:

aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS-2 \ --db-snapshot-identifier preload

Für Windows:

aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS-2 ^ --db-snapshot-identifier preload

Um einen bestehenden Endpunkt erneut zu verwenden, löschen Sie zuerst die DB-Instance und weisen Sie dann der wiederhergestellten Datenbank dieselbe Kennung zu. Weitere Informationen finden Sie unter delete-db-instance.

Im folgenden Beispiel wird auch ein letzter DB-Snapshot der DB-Instance erstellt, bevor sie gelöscht wird. Dies ist zwar optional, wird aber empfohlen.

Für Linux, macOS oder Unix:

aws rds delete-db-instance \ --db-instance-identifier AcmeRDS \ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload

Für Windows:

aws rds delete-db-instance ^ --db-instance-identifier AcmeRDS ^ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload

Schritt 4 (optional): Deaktivieren von automatischen Backups für Amazon RDS

Warnung

Deaktivieren Sie die automatischen Backups nicht, wenn Sie zeitpunktbezogene Wiederherstellungen durchführen müssen.

Das Deaktivieren von automatischen Backups ist eine Leistungsoptimierung und ist für Datenladevorgänge nicht erforderlich. Durch das Deaktivieren von automatischen Backups werden alle vorhandenen Backups gelöscht. Wenn Sie die automatischen Backups deaktiviert haben, ist daher eine zeitpunktbezogene Wiederherstellung nicht möglich. Beachten Sie, dass manuelle DB-Snapshots nicht von der Deaktivierung automatischer Backups betroffen sind. Alle bestehenden manuellen DB-Snapshots bleiben für eine Wiederherstellung verfügbar.

Das Deaktivieren von automatischen Backups reduziert die Ladezeit um 25 % und verringert zugleich den während des Ladevorgangs erforderlichen Speicherplatz. Wenn Sie Daten in eine neue DB-Instance laden wollen, die keine Daten enthält, ist das Deaktivieren von Backups eine einfache Möglichkeit, die Übertragungsgeschwindigkeit zu erhöhen und zusätzlichen Speicherverbrauch zu vermeiden. In einigen Fällen können Sie jedoch in eine DB-Instance laden, die bereits Daten enthält. Wenn ja, müssen Sie die Vorteile des Deaktivierens von Backups und den Verlust der Fähigkeit, zeitpunktbezogene Wiederherstellung durchführen zu können, gegeneinander abwägen.

In DB-Instances ist die Funktion für automatische Backups standardmäßig aktiviert (mit einem Aufbewahrungszeitraum von 1 Tag). Setzen Sie den Wert des Aufbewahrungszeitraums für Backups auf 0, um automatische Backups zu deaktivieren. Nach dem Ladevorgang können Sie Backups erneut aktivieren, indem Sie den Aufbewahrungszeitraum für Backups auf einen Nicht-Null-Wert setzen. Um Backups zu aktivieren oder zu deaktivieren, fährt Amazon RDS die DB-Instance herunter und startet sie dann neu, um die Protokollierung in MariaDB zu aktivieren oder zu deaktivieren.

Führen Sie den AWS CLI-Befehl modify-db-instance aus, um den Aufbewahrungszeitraum für Backups auf Null zu setzen und die Änderungen sofort zu übernehmen. Das Setzen des Aufbewahrungszeitraums für Backups auf Null erfordert den Neustart einer DB-Instance. Warten Sie daher bitte, bis der Neustart abgeschlossen wurde, bevor Sie fortfahren. Weitere Informationen finden Sie unter modify-db-instance.

Für Linux, macOS oder Unix:

aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --apply-immediately \ --backup-retention-period 0

Für Windows:

aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --apply-immediately ^ --backup-retention-period 0

Sie können den Status der DB-Instance mit dem AWS CLI-Befehl describe-db-instances überprüfen. Das folgende Beispiel zeigt den DB-Instance-Status der DB-Instance AcmeRDS.

aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}"

Wenn der Status der DB-Instance available ist, können Sie mit dem nächsten Schritt fortfahren.

Schritt 5: Laden der Daten

Verwenden Sie die MariaDB-Anweisung LOAD DATA LOCAL INFILE, um Zeilen aus den Flatfiles in die Datenbanktabellen einzulesen.

Anmerkung

Sie müssen die mariadb-Shell von demselben Speicherort aufrufen, an dem sich die Flatfiles befinden, oder beim Ausführen von LOAD DATA LOCAL INFILE den absoluten Pfad für die Dateien verwenden.

Das folgende Beispiel zeigt, wie Daten aus der Datei sales.txt in die Tabelle Sales in der Datenbank geladen werden:

MariaDB [(none)]> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\'; Query OK, 1 row affected (0.01 sec) Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

Weitere Informationen zur Anweisung LOAD DATA finden Sie unter LOAD DATA INFILE in der MariaDB-Dokumentation.

Schritt 6: Reaktivieren von automatischen Backups für Amazon RDS

Wenn Sie die automatischen Backups für Amazon RDS in Schritt 4 deaktiviert haben, aktivieren Sie sie nach Abschluss des Ladevorgangs erneut, indem Sie den Aufbewahrungszeitraum für Backups auf seinen ursprünglichen Wert vor dem Ladevorgang setzen. Wie bereits in Schritt 4 erwähnt, startet Amazon RDS die DB-Instance neu. Es kommt also zu einem kurzen Ausfall.

Im folgenden Beispiel wird der AWS CLI-Befehl modify-db-instance verwendet, um automatische Backups für die DB-Instance AcmeRDS zu aktivieren und den Aufbewahrungszeitraum auf einen Tag festzulegen:

Für Linux, macOS oder Unix:

aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --backup-retention-period 1 \ --apply-immediately

Für Windows:

aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --backup-retention-period 1 ^ --apply-immediately