Migrieren von Datenbanken zu Amazon Aurora
Werbung
Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Copyright © 2016 Amazon Web Services Inc. oder Tochterfirmen. Alle Rechte vorbehalten. Hinweise Dieses Dokument wird nur zu Informationszwecken zur Verfügung gestellt. Es stellt das aktuelle Produktangebot und die Praktiken von AWS zum Erstellungsdatum dieses Dokuments dar. Änderungen vorbehalten. Kunden sind für ihre eigene unabhängige Einschätzung der Informationen in diesem Dokument und jedwede Nutzung der AWS-Services verantwortlich. Jeder Service wird „wie besehen“ ohne Gewähr und ohne Garantie jeglicher Art, weder ausdrücklich noch impliziert, bereitgestellt. Dieses Dokument gibt keine Garantien, Gewährleistungen, vertragliche Verpflichtungen, Bedingungen oder Zusicherungen von AWS, seinen Partnern, Zulieferern oder Lizenzgebern. Die Verantwortung und Haftung von AWS gegenüber seinen Kunden werden durch AWS-Vereinbarungen geregelt. Dieses Dokument ist weder ganz noch teilweise Teil der Vereinbarungen von AWS mit seinen Kunden und ändert diese Vereinbarungen auch nicht. Seite 2 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Inhalt Übersicht 4 Einführung in Amazon Aurora 4 Überlegungen zur Datenbankmigration 6 Migrationsphasen 6 Überlegungen zur Anwendung 6 Überlegungen zu Sharding und Read Replica 8 Überlegungen zur Zuverlässigkeit 8 Überlegungen zu Kosten und Lizenzierung 9 Weitere Überlegungen zur Migration 9 Planen der Datenbankmigration Homogene Migration 10 Heterogene Migration 13 Migrieren von großen Datenbanken zu Amazon Aurora 14 Partitions- und Shard-Konsolidierung mit Amazon Aurora 15 Migrationsoptionen – Übersicht 16 RDS-Snapshot-Migration 17 Migrieren des Datenbankschemas 22 Homogene Schemamigration 23 Heterogene Schemamigration 24 Schemamigration mit AWS Schema Conversion Tool 25 Migrieren von Daten 34 AWS DMS – Einführung und Allgemeines 34 Migrationsmethoden 35 Migrationsverfahren 36 Tests und Umstellung Migrationstests Seite 3 von 46 10 42 42 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Umstellung Juni 2016 43 Fazit 44 Mitwirkende 45 Weitere Informationen 45 Anmerkungen 45 Übersicht Amazon Aurora ist eine mit MySQL kompatible, relationale Datenbank-Engine für Unternehmen. Da Amazon Aurora eine cloudbasierte Datenbank ist, fallen zahlreiche Einschränkungen herkömmlicher relationaler Datenbank-Engines weg. Dieses Whitepaper vermittelt die bewährten Methoden für die Migration Ihrer bestehenden Datenbanken zu Amazon Aurora. Im Whitepaper werden Migrationsaspekte dargelegt, zudem wird in einem schrittweisen Verfahren erläutert, wie Open Source- und kommerzielle Datenbanken mit minimaler Anwendungsunterbrechung zu Amazon Aurora migriert werden. Einführung in Amazon Aurora Jahrzehntelang waren herkömmliche relationale Datenbanken die erste Wahl für Datenspeicher und Persistenz. Solche Datenbanksysteme basieren auf monolithischen Architekturen und sind nicht für die Nutzung der Cloud-Infrastruktur geeignet. Besonders in Bezug auf Kosten, Flexibilität und Verfügbarkeit sind die monolithischen Architekturen problematisch. Um diese Probleme zu lösen, hat AWS die relationalen Datenbanken auf die Cloud-Infrastruktur abgestimmt und Amazon Aurora eingeführt. Amazon Aurora ist eine mit MySQL kompatible, relationale Datenbank-Engine und kombiniert die Geschwindigkeit, Verfügbarkeit und Sicherheit von kommerziellen High-End-Datenbanken mit der Einfachheit und Kosteneffizienz von Open Source-Datenbanken. Aurora bietet eine fünffach bessere Performance als MySQL und kann sich mit der Leistung von kommerziellen High-EndDatenbanken messen. Im Vergleich zu kommerziellen Engines kostet Amazon Aurora jedoch nur ein Zehntel. Seite 4 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Amazon Aurora ist über die Amazon Relational Database Service-Plattform (Amazon RDS) verfügbar. Wie die anderen Amazon RDS-Datenbanken ist auch Aurora ein vollständig verwalteter Datenbankservice. Der Großteil der Datenbankverwaltung (Hardwarebereitstellung, Software-Patches, Einrichtung, Konfiguration, Überwachung und Sicherung) ist bei der Amazon RDS-Plattform vollständig automatisiert. Amazon Aurora ist auf unternehmenskritische Arbeitslasten ausgelegt und standardmäßig hoch verfügbar. Ein Aurora-Datenbank-Cluster umfasst mehrere Availability Zones in einer Region und bietet daher sofortige Stabilität und Fehlertoleranz für Ihre Daten in verschiedenen physischen Rechenzentren. Eine Availability Zone besteht aus einem oder mehreren HochverfügbarkeitsRechenzentren von Amazon. Availability Zones sind voneinander getrennt und über Verbindungen mit geringer Latenz verbunden. Jedes Segment eines Datenbankvolumes wird in diesen Availability Zones sechsfach repliziert. Die Volumes der Aurora-Cluster werden automatisch mit der steigenden Datenmenge in Ihrer Datenbank vergrößert, und zwar gänzlich ohne Leistungs- oder Verfügbarkeitseinbußen. Daher müssen Sie keine Erweiterung für den Datenspeicher mehr im Voraus schätzen oder bereitstellen. Ein AuroraCluster-Volume kann maximal 64 Terabyte (TB) umfassen. Nur der tatsächlich im Aurora-Cluster-Volume genutzte Speicherplatz wird in Rechnung gestellt. Die automatische Sicherungsfunktion von Aurora unterstützt die zeitpunktbezogene Wiederherstellung Ihrer Daten, sodass Sie die Datenbank auf jede Sekunde Ihrer Beibehaltungsdauer bis zu den letzten 5 Minuten wiederherstellen können. Die automatischen Sicherungen werden in Amazon Simple Storage Service (Amazon S3) gespeichert. Dieser Service bietet eine Stabilität von 99,999999999 %. Amazon Aurora-Sicherungen werden automatisch, inkrementell und fortlaufend erstellt. Die Datenbankleistung wird dadurch nicht beeinträchtigt. Für Anwendungen, die ein schreibgeschütztes Replikat (Read Replica) benötigen, können Sie pro Aurora-Datenbank bis zu 15 Aurora-Replikate mit sehr geringer Verzögerung erstellen. Diese Replikate nutzen denselben zugrunde liegenden Speicher wie die Quellinstanz, sodass Kosten gesenkt und Schreibvorgänge auf den Replikatknoten vermieden werden. Seite 5 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Amazon Aurora ist ausgesprochen sicher und bietet Ihnen die Möglichkeit, Ihre Datenbanken zu verschlüsseln. Die Schlüssel dafür erstellen und steuern Sie mit AWS Key Management Service (AWS KMS). Für eine Datenbankinstanz mit Amazon Aurora-Verschlüsselung werden die Daten im zugrunde liegenden Speicher ebenso wie die automatischen Sicherungen, Snapshots und Replikate im gleichen Cluster verschlüsselt. Amazon Aurora verwendet SSL (AES-256), um die Daten während der Übertragung zu schützen. Eine vollständige Liste der Aurora-Funktionen finden Sie auf der Produktseite von Amazon Aurora.1 Aufgrund der umfangreichen Funktionen und der Kosteneffektivität wird Amazon Aurora in zunehmenden Maße als zukünftige Datenbank für unternehmenskritische Anwendungen gesehen. Überlegungen zur Datenbankmigration In der Architektur der meisten Anwendungen ist die Datenbank eine entscheidende Komponente. Im Anwendungslebenszyklus gilt die Datenbankmigration zu einer neuen Plattform als wichtiges Ereignis, das sich auf die Funktion, Leistung und Stabilität der Anwendung auswirken kann. Bevor Sie Ihr erstes Migrationsprojekt mit Amazon Aurora beginnen, sollten Sie einige Überlegungen berücksichtigen. Migrationsphasen Da Datenbankmigrationen komplex sein können, empfehlen wir eine phasenbasierte und schrittweise Methode. Abbildung 1: Migrationsphasen Überlegungen zur Anwendung Auswerten der Aurora-Funktionen Obwohl die meisten Anwendungen mit verschiedenen relationalen DatenbankEngines genutzt werden können, sollten Sie sicherstellen, dass Ihre Anwendung für Amazon Aurora geeignet ist. Amazon Aurora bietet „Wire Compatibility“ mit MySQL 5.6. Daher lassen sich die meisten Programmierungen, Anwendungen, Treiber und Tools, die heutzutage für MySQL-Datenbanken eingesetzt werden, mit geringfügigen oder gar keinen Änderungen ebenfalls für Aurora nutzen. Seite 6 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Bestimmte Funktionen von MySQL (wie z. B. die Speicher-Engine MyISAM) sind für Amazon Aurora jedoch nicht verfügbar. Da es sich bei Aurora um einen verwalteten Service handelt, ist zudem der SSH-Zugriff auf Datenbankknoten eingeschrä nkt. Dies kann die Installation von Tools oder Plug-ins von Drittanbietern auf dem Datenbankhost beeinträchtigen. Überlegungen zur Leistung Bei der Datenbankmigration zu einer neuen Plattform ist die Datenbankleistung ein wichtiger Faktor. Daher beginnen viele erfolgreiche Datenbankmigrationen mit der Leistungsauswertung der neuen Datenbankplattform. Mit running Sysbench and TPC-C benchmarks erhalten Sie zwar einen guten Eindruck der allgemeinen Datenbankleistung, jedoch emulieren diese Benchmarks nicht die Datenzugriffsmuster Ihrer Anwendungen. Für weiterführende Ergebnisse sollten Sie die Datenbankleistung mit zeitkritischen Arbeitslasten testen, indem Sie die Abfragen (oder ein Subset der Abfragen) direkt auf der neuen Plattform ausführen. Berücksichtigen Sie die folgenden Strategien: Wenn Sie eine MySQL-Datenbank nutzen, erfolgt die Migration zu Amazon Aurora mit einer Ausfallzeit. Führen Sie Leistungstests für die Datenbank mit einer Test- oder Staging-Version der Anwendung oder durch Simulation der Produktionsarbeitslast aus. Wenn Sie eine nicht mit MySQL kompatible Engine nutzen, können Sie die Tabellen mit der höchsten Arbeitslast selektiv in Amazon Aurora kopieren und die Abfragen für diese Tabellen testen. Damit erhalten Sie einen guten Startpunkt. Einen vollständigen Überblick über die tatsächliche Leistung der Anwendung auf der neuen Plattform bieten jedoch erst die nach der vollständigen Datenmigration ausgeführten Tests. Amazon Aurora bietet eine deutliche bessere Leistung als MySQL und ist mit kommerziellen Engines vergleichbar. Dies wird durch eine enge Integration der Datenbank-Engine in eine speziell für Datenbanklasten entwickelte, SSD-basierte und virtuelle Speicherebene erzielt. Auf diese Weise werden Schreibvorgä nge in das Speichersystem reduziert, Sperrkonflikte minimiert und (durch die Threads der Datenbankverarbeitung entstehende) Verzögerungen verhindert. Unsere Tests mit SysBench auf r3.8xlarge-Instances zeigen, dass Amazon Aurora über 585.000 Lesevorgänge sowie 107.000 Schreibvorgänge pro Sekunde leistet. Das ist fünfmal mehr als mit SQL auf derselben Benchmark und der gleichen Hardware. Seite 7 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Besonders im Bereich von stark parallelisierten Arbeitslasten ist Amazon Aurora erheblich besser als herkömmliche MySQL-Datenbanken. Für den maximalen Arbeitslastdurchsatz mit Amazon Aurora empfehlen wir, die Anwendungen auf eine hohe Anzahl paralleler Abfragen auszulegen. Überlegungen zu Sharding und Read Replica Wenn Sie derzeit eine Shard-Datenbank auf mehreren Knoten nutzen, können Sie diese Shards im Rahmen der Migration in einer einzigen Aurora-Datenbank zusammenfassen. Eine einzelne Amazon Aurora-Instance kann auf bis zu 64 TB skaliert werden, unterstützt Tausende Tabellen und eine erheblich höhere Anzahl von Lese- und Schreibvorgängen als eine standardmäßige MySQL-Datenbank. Bei Anwendungen mit vielen Lese- und Schreibvorgängen können Sie die Read Replicas von Aurora nutzen, um die Arbeitslast der Lesevorgänge aus dem Master-Datenbankknoten auszulagern. Dadurch können parallele Schreibvorgänge für die primäre Datenbank – und somit die gesamte Lese- und Schreibleistung – optimiert werden. Der Einsatz von Read Replicas kann zudem die Kosten einer Multi-AZ-Konfiguration senken, da Sie kleinere Instances für die primäre Instance nutzen und gleichzeitig Failover-Funktionen für den Datenbank-Cluster hinzufügen können. Die Read Replicas von Aurora bieten eine Replikationsverzögerung von nahezu null und Sie können bis zu 15 Read Replicas erstellen. Überlegungen zur Zuverlässigkeit Eine wichtige Überlegung in Bezug auf Datenbanken betrifft die Hochverfügbarkeit sowie die Notfallwiederherstellung. Ermitteln Sie die anwendungsbezogenen Anforderungen für RTO (Recovery Time Objective) und RPO (Recovery Point Objective). Mit Amazon Aurora können Sie beide Faktoren deutlich verbessern. Amazon Aurora verringert die für einen Neustart der Datenbank benötigte Zeit auf unter 60 Sekunden (dies gilt für die meisten Datenbankausfall-Szenarios). Zudem wird mit Aurora der Puffercache aus dem Datenbankprozess herausgenommen und direkt zum Neustart verfügbar gemacht. In den seltenen Szenarios von Hardware- und Availability Zone-Ausfällen wird die Wiederherstellung automatisch von der Datenbankplattform übernommen. Seite 8 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Aurora bietet in einer AWS-Region eine Wiederherstellung mit einem RPO-Wert von null – im Vergleich zu lokalen Datenbanksystemen ist das eine deutliche Verbesserung. Mit Aurora werden sechs Kopien Ihrer Daten in drei Availability Zones hinterlegt. In einer stabilen AZ wird automatisch versucht, die Datenbank ohne Datenverlust wiederherzustellen. In dem unwahrscheinlichen Fall, dass die Daten nicht im Amazon Aurora-Speicher verfügbar sind, können Sie diese über einen DB-Snapshot wiederherstellen oder eine zeitpunktbezogene Wiederherstellung in eine neue Instance ausführen. Überlegungen zu Kosten und Lizenzierung Das Betreiben und Ausführen von Datenbanken ist mit Kosten verbunden. Vor der Planung einer Datenbankmigration ist daher eine Analyse der Gesamtbetriebskosten (TCO, Total Cost of Ownership) für die neue Datenbankplattform unerlässlich. Im Idealfall werden die Gesamtbetriebskosten durch die Migration zu einer neuen Datenbankplattform gesenkt und gleichzeitig die Anwendungen mit gleichbleibenden oder besseren Funktionen bereitgestellt. Wenn Sie eine Open Source-Datenbank-Engine (MySQL, Postgres) nutzen, entstehen die Kosten im Wesentlichen in den Bereichen Hardware sowie Serverund Datenbankmanagement. Falls Sie jedoch eine kommerzielle DatenbankEngine (Oracle, SQL Server, DB2 usw.) einsetzen, besteht ein Großteil der Kosten aus der Datenbanklizenzierung. Da Aurora zu einem Zehntel der Kosten von kommerziellen Engines verfügbar ist, werden die Gesamtbetriebskosten zahlreicher Anwendungen durch den Wechsel zu Aurora erheblich gesenkt. Aufgrund der hohen Leistung und der für mehrere Zwecke einsetzbaren Read Replicas von Aurora können Sie auch dann erhebliche Kosteneinsparungen erzielen, wenn Sie von einer Open Source-Engine wie MySQL oder Postgres zu Aurora wechseln. Weitere Informationen finden Sie auf der Seite Amazon RDS for Aurora – Preise.2 Weitere Überlegungen zur Migration Wenn Sie die Anwendungseignung, die Leistung, die Gesamtbetriebskosten und die Zuverlässigkeit berücksichtigt haben, sollten Sie den Aufwand für die Migration zu einer neuen Plattform bedenken. Seite 9 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Einschätzen der Codeänderungen Es ist wichtig, die für die Migration der Datenbank zu Amazon Aurora erforderlichen Code- und Schemaänderungen einzuschätzen. Bei einer Migration von mit MySQL kompatiblen Datenbanken sind nur geringfügige Codeänderungen nötig. Wird jedoch von einer nicht mit MySQL kompatiblen Engine migriert, können Schema- und Codeänderungen erforderlich sein. Dieser Aufwand kann mit AWS Schema Conversion Tool eingeschätzt werden (wird später in diesem Whitepaper vorgestellt). Anwendungsverfügbarkeit während der Migration Bei der Migration zu Amazon Aurora können Sie zwischen einer geplanten Ausfallzeit oder einer Fast-Null-Ausfallzeit wählen. Die gewählte Methode hängt von der Datenbankgröße und den Verfügbarkeitsanforderungen der Anwendungen ab. In jedem Fall sollte vor dem Beginn der Datenbankmigration die Auswirkung eines solchen Migrationsprozesses auf die Anwendung und das Unternehmen einbezogen werden. In den nächsten Abschnitten werden beide Methoden ausführlich erläutert. Planen der Datenbankmigration Im vorherigen Abschnitt wurden einige der wichtigsten Überlegungen genannt, die bei einer Datenbankmigration zu Amazon Aurora zu berücksichtigen sind. Wenn Sie sich für Aurora entschieden haben, wählen Sie im nächsten Schritt eine vorläufige Migrationsmethode aus und erstellen einen Plan für die Datenbankmigration. Homogene Migration Sofern Sie eine mit MySQL 5.6 kompatible Quelldatenbank (MySQL, MariaDB, Percona usw.) nutzen, ist die Migration zu Aurora recht einfach. Homogene Migration mit Ausfallzeit Wenn für die Anwendung eine geplante Ausfallzeit außerhalb der Spitzenauslastungszeiten in Frage kommt, ist die Migration mit Ausfallzeit die einfachste und daher empfohlene Methode. Die meisten Datenbankmigrationen fallen in diese Kategorie, da für die meisten Anwendungen bereits ein gut geplantes Wartungsfenster vorhanden ist. Bei einer Datenbankmigration mit Ausfallzeit haben Sie folgende Möglichkeiten: Seite 10 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 RDS-Snapshot-Migration. Wird Ihre Quelldatenbank mit Amazon RDS MySQL 5.6 ausgeführt, können Sie einfach einen Snapshot dieser Datenbank zu Amazon Aurora migrieren. Bei Migrationen mit Ausfallzeit ist es während der Snapshot-Erstellung und der Migration erforderlich, entweder die Anwendung anzuhalten oder die Schreibvorgänge in die Datenbank zu stoppen. Die für die Migration benötigte Zeitspanne hängt in erster Linie von der Datenbankgröße ab und kann bereits vor der Produktionsmigration mithilfe einer ausgeführten Testmigration ermittelt werden. Die Option der Snapshot-Migration wird im Abschnitt RDS-Snapshot-Migration erläutert. Mithilfe der Snapshot-Migration und der binlog-Replikation ist auch eine Migration mit Fast-Null-Ausfallzeit möglich. Diese Option wird im nächsten Abschnitt vorgestellt. Migration mit systemeigenen MySQL-Tools. Für die Daten- und Schemamigration zu Aurora können Sie die systemeigenen MySQL-Tools nutzen. Diese Option bietet sich an, wenn Sie mehr Kontrolle über die Datenbankmigration wünschen, mit den systemeigenen MySQL-Tools vertraut sind und andere Migrationsmethoden nicht so gut für Ihren Anwendungsfall geeignet sind. Die bewährten Methoden für diese Option finden Sie im Whitepaper Amazon RDS for Aurora Export/Import Performance Best Practices.3 Migration mit AWS Database Migration Service (AWS DMS). Die einmalige Migration mit AWS DMS ist ein weiteres Tool für die Verschiebung der Quelldatenbank zu Amazon Aurora. Bevor Sie die Daten mit AWS DMS verschieben können, müssen Sie das Datenbankschema mit den systemeigenen MySQL-Tools von der Quelle in das Ziel kopieren. Den schrittweisen Prozess finden Sie im Abschnitt Migrieren von Daten. Der Einsatz von AWS DMS ist eine gute Wahl, wenn Sie mit den systemeigenen MySQL-Tools nicht vertraut sind. Homogene Migration mit Fast-Null-Ausfallzeit In einigen Szenarios ist eine Datenbankmigration zu Aurora mit minimaler Ausfallzeit erforderlich. Nachfolgend finden Sie zwei Beispiele: Seite 11 von 46 Wenn Ihre Datenbank relativ umfangreich ist und die Ausfallzeit für die Migration lä nger dauert als das vorgesehene Wartungsfenster der Anwendung. Wenn Sie die Quell- und die Zieldatenbank zu Testzwecken gleichzeitig ausführen möchten. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 In solchen Fällen können Sie die an der MySQL-Datenbank vorgenommenen Änderungen in Aurora mithilfe der Replikationsfunktion in Echtzeit replizieren. Dafür stehen Ihnen die folgenden Optionen zur Verfügung: Seite 12 von 46 Migration mit Fast-Null-Ausfallzeit – MySQL binlog-Replikation. Amazon Aurora unterstützt die herkömmliche MySQL binlog-Replikation. Sofern Sie eine MySQL-Datenbank verwenden, sind Sie möglicherweise bereits mit der klassischen Konfiguration der binlog-Replikation vertraut. Wenn das der Fall ist und Sie mehr Kontrolle über den Migrationsprozess wünschen, ist das einmalige Laden der Daten unter Verwendung von systemeigenen Tools und der binlog-Replikation für Sie ein vertrauter Migrationspfad zu Aurora. Migration mit Fast-Null-Ausfallzeit – AWS Database Migration Service (AWS DMS). Neben der einmaligen Migration unterstützt AWS DMS auch die Datenreplikation in Echtzeit mithilfe von CDC (Change Data Capture) zwischen Quelle und Ziel. Mit AWS DMS wird die Komplexität im Zusammenhang mit der initialen Datenkopie, mit der Einrichtung von Replikations-Instances und mit der Überwachung der Replikation berücksichtigt. Nach Abschluss der initialen Datenbankmigration werden Quell- und Zieldatenbank so lange synchronisiert, wie Sie es wünschen. Falls Sie mit der binlog-Replikation nicht vertraut sind, ist AWS DMS die nächstbeste Option für homogene Migrationen zu Amazon Aurora mit Fast-Null-Ausfallzeit. Weitere Informationen finden Sie im Abschnitt AWS DMS – Einführung und Allgemeines. Migration mit Fast-Null-Ausfallzeit – RDS-Snapshot-Migration und MySQL binlog-Replikation. Wenn Ihre Quelldatenbank mit Amazon RDS MySQL 5.6 ausgeführt wird, können Sie einen Snapshot dieser Datenbank zu Amazon Aurora migrieren. Im Anschluss an diese Snapshot-Migration starten Sie die binlog-Replikation zwischen Quelle und Ziel. Weitere Informationen über diese Migrationsoption finden Sie unter Replication with Amazon Aurora im Amazon RDS-Benutzerhandbuch.4 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Heterogene Migration Wenn Sie eine nicht mit MySQL kompatible Datenbank (Oracle, SQL Server, PostgresSQL usw.) schnell und einfach zu Amazon Aurora migrieren möchten, stehen Ihnen mehrere Optionen zur Verfügung: Schemamigration Die Schemamigration von einer nicht mit MySQL kompatiblen Datenbank zu Amazon Aurora führen Sie mit AWS Schema Conversion Tool aus. Bei diesem Tool handelt es sich um eine Desktop-Anwendung, mit der Sie das Datenbankschema einer Oracle-, Microsoft SQL Server- oder PostgreSQLDatenbank in eine DB-Instance von Amazon RDS MySQL oder einen DB-Cluster von Amazon Aurora konvertieren können. Falls sich das Schema Ihrer Quelldatenbank nicht automatisch und vollständig konvertieren lä sst, bietet AWS Schema Conversion Tool eine Anleitung, mit der Sie das Schema in der Amazon RDS-Zieldatenbank erstellen können. Details dazu finden Sie im Abschnitt Migrieren des Datenbankschemas. Datenmigration AWS Database Migration Service (AWS DMS) unterstützt nicht nur homogene Migrationen mit Fast-Null-Ausfallzeit, sondern auch die fortlaufende Replikation von heterogenen Datenbanken. AWS DMS gilt als bevorzugte Option für die Verschiebung der Quell- in die Zieldatenbank, und zwar sowohl für Migrationen mit Ausfallzeit als auch für Migrationen mit Fast-Null-Ausfallzeit. Nach dem Beginn der Migration werden alle Komplexitä ten des Migrationsprozesses (wie Datentyptransformation, Komprimierung und parallele Übertragung (für eine schnellere Datenübertragung) von AWS DMS übernommen. Gleichzeitig wird sichergestellt, dass die während der Migration an der Quelldatenbank vorgenommenen Änderungen automatisch in der Zieldatenbank repliziert werden. Neben AWS DMS können Sie auch andere Tools von Drittanbietern (z. B. Attunity Replicate, Tungsten Replicator, Oracle Golden Gate) für die Datenmigration zu Amazon Aurora nutzen. Unabhängig vom gewählten Tool sollten Sie die Leistungs- und Lizenzierungskosten berücksichtigen, wenn Sie Ihr Toolset für die Migration zusammenstellen. Seite 13 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Migrieren von großen Datenbanken zu Amazon Aurora In jeder Datenbankmigration stellt die Migration großer Datenmengen einzigartige Herausforderungen dar. Bei vielen erfolgreichen Migrationsprojekten von Datenbanken wird eine Kombination aus folgenden Strategien eingesetzt: Seite 14 von 46 Migration mit fortlaufender Replikation. Bei großen Datenbanken ist in der Regel eine längere Ausfallzeit erforderlich, um die Daten von der Quelle zum Ziel zu verschieben. Zur Verringerung dieser Ausfallzeit können Sie zunächst die Baseline-Daten von der Quelle in das Ziel laden und dann die Replikation aktivieren (über die systemeigenen MySQL-Tools, AWS DMS oder Tools von Drittanbietern), um Änderungen zu synchronisieren. Zuerst Kopieerstellung von statischen Tabellen. Wenn Ihre Datenbank auf umfangreichen statischen Tabellen mit Referenzdaten basiert, sollten Sie zuerst diese großen Tabellen zur Zieldatenbank migrieren. Anschließend können Sie den aktiven Datenbestand migrieren. Mit AWS DMS können Sie Tabellen selektiv kopieren oder diese manuell exportieren und importieren. Mehrphasenmigration. Die Migration einer umfangreichen Datenbank mit Tausenden Tabellen kann in mehrere Phasen untergliedert werden. Beispielsweise können Sie so lange an jedem Wochenende mehrere Tabellen mit Abfragen ohne Kreuzverknüpfungen (Cross Joins) verschieben, bis die Quelldatenbank vollständig zur Zieldatenbank migriert ist. Beachten Sie, dass dafür Anwendungsänderungen erforderlich sind, damit die Verbindung zu zwei Datenbanken gleichzeitig hergestellt werden kann, während sich der Datenbestand auf zwei verschiedenen Knoten befindet. Diese Option ist jedoch kein gängiges Migrationsmuster. Datenbankbereinigung. Viele große Datenbanken enthalten Daten und Tabellen, die nicht verwendet werden. In vielen Fällen behalten die Entwickler und Datenbankadministratoren Sicherungskopien der Tabellen in derselben Datenbank. Möglicherweise haben sie auch einfach nur vergessen, obsolete Tabellen zu löschen. In jedem Fall bietet eine Datenbankmigration eine gute Gelegenheit, um die bestehende Datenbank vor der Migration zu bereinigen. Sie können die nicht verwendeten Tabellen entweder löschen oder in einer anderen Datenbank archivieren. Ebenso können Sie Altdaten aus großen Tabellen löschen oder diese Daten in Flat-Dateien archivieren. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Partitions- und Shard-Konsolidierung mit Amazon Aurora Wenn Sie für eine bessere Leistung mehrere Shards oder funktionale Partitionen der Datenbank ausführen, können Sie diese Partitionen oder Shards in einer einzigen Aurora-Datenbank konsolidieren. Eine einzelne Amazon Aurora-Instance kann auf bis zu 64 TB skaliert werden, unterstützt Tausende Tabellen und eine erheblich höhere Anzahl von Lese- und Schreibvorgängen als eine standardmäßige MySQL-Datenbank. Durch die Konsolidierung dieser Partitionen in einer einzigen Aurora-Instance können Sie nicht nur die Gesamtbetriebskosten reduzieren und das Datenbankmanagement vereinfachen, sondern auch die Leistung von partitionsübergreifenden Abfragen verbessern. Funktionale Partitionen. Bei der funktionalen Partitionierung werden unterschiedliche Knoten für unterschiedliche Aufgaben zugeordnet. Beispielsweise kann bei einer E-Commerce-Anwendung ein Datenbankknoten für die Produktkatalogdaten und ein anderer Datenbankknoten für die Erfassung und Verarbeitung von Bestellungen verwendet werden. Folglich haben diese Partitionen in der Regel getrennte und nicht überlappende Schemata. Konsolidierungsstrategie. Migrieren Sie jede funktionale Partition als eigenes Schema zu Ihrer Aurora-Ziel-Instance. Sofern Sie eine mit MySQL kompatible Quelldatenbank verwenden, können Sie das Schema mit den systemeigenen MySQL-Tools und die Daten mit AWS DMS migrieren (entweder mit einmaligem Ladevorgang oder fortlaufender Replikation). Nutzen Sie hingegen eine nicht mit MySQL kompatible Quelldatenbank, können Sie die Schemata mit AWS Schema Conversion Tool zu Aurora migrieren und AWS DMS für einen einmaligen Ladevorgang oder die fortlaufende Replikation verwenden. Seite 15 von 46 Daten-Shards. Wenn Sie das gleiche Schema mit unterschiedlichen Datenbestä nden auf mehreren Knoten verwenden, nutzen Sie Datenbank-Sharding. Beispielsweise könnte bei einem Blog-Service mit hohem Datenverkehr das Sharding der Benutzeraktivität und Daten mit demselben Tabellenschema über mehrere Datenbank-Shards erfolgen. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Konsolidierungsstrategie. Da alle Shards das gleiche Datenbankschema verwenden, muss das Zielschema nur einmal erstellt werden. Wenn Ihre Datenbank mit MySQL kompatibel ist, können Sie das Datenbankschema mit den systemeigenen Tools zu Aurora migrieren. Nutzen Sie hingegen eine nicht mit MySQL kompatible Datenbank, können Sie das Datenbankschema mit AWS Schema Conversion Tool zu Aurora migrieren. Nach der Migration des Datenbankschemas sollten Sie die Schreibvorgänge in die Datenbank-Shards stoppen und einen einzelnen Shard mit den systemeigenen Tools oder mit dem einmaligen Ladevorgang von AWS DMS zu Aurora migrieren. Können die Schreibvorgänge der Anwendung nicht für einen längeren Zeitraum ausgesetzt werden, können Sie nach umsichtiger Planung und sorgfältigen Tests dennoch AWS DMS mit der Replikation einsetzen. Migrationsoptionen – Übersicht Typ der Quelldatenbank Migration mit Ausfallzeit Migration mit Fast-Null-Ausfallzeit Amazon RDS MySQL Option 1: RDS-Snapshot-Migration Option 1: Migration mit systemeigenen Tools + binlog-Replikation Option 2: Manuelle Migration mit systemeigenen Tools* Option 3: Schemamigration mit systemeigenen Tools und AWS DMS zum Laden der Daten MySQL Amazon EC2 oder lokal Oracle/SQL Server Seite 16 von 46 Option 2: RDS-Snapshot-Migration + binlog-Replikation Option 3: Schemamigration mit systemeigenen Tools + AWS DMS zur Datenverschiebung Option 1: Migration mit systemeigenen Tools Option 1: Migration mit systemeigenen Tools + binlog-Replikation Option 2: Schemamigration mit systemeigenen Tools + AWS DMS zum Laden der Daten Option 2: Schemamigration mit systemeigenen Tools + AWS DMS zur Datenverschiebung Option 1: AWS Schema Conversion Tool + AWS DMS (empfohlen) Option 1: AWS Schema Conversion Tool + AWS DMS (empfohlen) Option 2: Schemakonvertierung manuell oder über Drittanbieter-Tool + Laden der Daten in das Ziel manuell oder über Drittanbieter-Tool Option 2: Schemakonvertierung manuell oder über Drittanbieter-Tool + Laden der Daten in das Ziel manuell oder über Drittanbieter-Tool + Replikation über Drittanbieter-Tool Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Typ der Quelldatenbank Migration mit Ausfallzeit Migration mit Fast-Null-Ausfallzeit Andere nicht mit MySQL kompatible Datenbanken Option: Schemakonvertierung manuell oder über Drittanbieter-Tool + Laden der Daten in das Ziel manuell oder über Drittanbieter-Tool Option: Schemakonvertierung manuell oder über Drittanbieter-Tool + Laden der Daten in das Ziel manuell oder über Drittanbieter-Tool + Replikation über Drittanbieter-Tool (GoldenGate usw.) *Systemeigene MySQL-Tools: mysqldump, SELECT INTO OUTFILE, Drittanbieter-Tools wie mydumper/myloader RDS-Snapshot-Migration Damit Sie die RDS-Snapshot-Migration für den Wechsel zu Aurora verwenden können, muss Ihre MySQL-Datenbank mit Amazon RDS MySQL 5.6 ausgeführt werden. Zudem müssen Sie einen RDS-Snapshot der Datenbank erstellen. Diese Migrationsmethode ist nicht für lokale Datenbanken oder für mit Amazon Elastic Compute Cloud (Amazon EC2) ausgeführte Datenbanken geeignet. Falls Sie Ihre Amazon RDS MySQL-Datenbank mit einer Version vor 5.6 ausführen, ist ein Upgrade auf 5.6 als Voraussetzung erforderlich. Der größte Vorteil dieser Migrationsmethode liegt darin, dass sie am einfachsten ist und die wenigsten Schritte erfordert. Insbesondere werden gemeinsam mit den gesamten Datenbankdaten auch alle Schemaobjekte, sekundären Indizes und gespeicherten Prozeduren migriert. Bei einer Snapshot-Migration ohne binlog-Replikation muss die Quelldatenbank entweder offline oder im schreibgeschützten Modus sein (damit während der Migration keine Änderungen an der Quelldatenbank vorgenommen werden können). Zur Einschätzung der Ausfallzeit können Sie einfach den vorhandenen Snapshot Ihrer Datenbank für eine Testmigration nutzen. Sofern die Migrationszeit die Ausfallzeitvorgaben nicht überschreitet, ist dies womöglich die beste Methode für Sie. In einigen Fä llen jedoch kann eine Migration mit AWS DMS oder mit systemeigenen Migrationstools schneller sein als die Snapshot-Migration. Im Falle, dass eine längere Ausfallzeit nicht möglich ist, können Sie eine Migration mit einer Fast-Null-Ausfallzeit ausführen. Dazu migrieren Sie zuerst einen Snapshot der RDS-Datenbank zu Amazon Aurora – die Quelldatenbank kann weiterhin aktualisiert werden. Anschließend führen Sie mithilfe der MySQL binlog-Replikation die Aktualisierung von MySQL zu Aurora aus. Seite 17 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Sie können entweder einen manuellen oder einen automatisierten DB-Snapshot migrieren. Dazu führen Sie die folgenden allgemeinen Schritte aus: 1. Ermitteln Sie den Speicherplatz, der für eine Migration der Amazon RDS MySQL 5.6-Instance zu einem Aurora DB-Cluster benötigt wird. Weitere Informationen finden Sie im nächsten Abschnitt. 2. Verwenden Sie die Amazon RDS-Konsole, um den Snapshot in der Region zu erstellen, in der sich die Amazon RDS MySQL 5.6-Instance befindet. 3. Erstellen Sie mithilfe der Konsolenfunktion Migrate Database einen DB-Cluster für Amazon Aurora, der mit dem DB-Snapshot aus der ursprünglichen DB-Instance von MySQL 5.6 gefüllt wird. Hinweis: Einige MyISAM-Tabellen werden möglicherweise nicht fehlerfrei konvertiert und erfordern manuelle Änderungen. Beispielsweise lässt die InnoDB-Engine kein Feld für die automatische Inkrementierung als Teil eines zusammengesetzten Schlüssels zu. Auch räumliche Indizes werden derzeit nicht unterstützt. Einschätzen des erforderlichen Speicherplatzes für die Snapshot-Migration Wenn Sie den Snapshot einer MySQL DB-Instance zum Aurora DB-Cluster migrieren möchten, verwendet Aurora ein Amazon Elastic Block Store (Amazon EBS)-Volume, um die Snapshot-Daten vor der Migration zu formatieren. In einigen Fällen wird zusätzlicher Speicherplatz benötigt, um die Daten für die Migration zu formatieren. Bei der Migration können potenzielle Speicherplatzprobleme durch MyISAM-Tabellen und die Option ROW_FORMAT=COMPRESSED entstehen. Wenn Sie keine der beiden genannten Funktionen in Ihrer Quelldatenbank verwenden, können Sie diesen Abschnitt überspringen, da bei Ihnen keine Speicherplatzprobleme auftreten sollten. Während der Migration werden MyISAM-Tabellen in InnoDB konvertiert, alle komprimierten Tabellen werden dabei in unkomprimierte Tabellen umgewandelt. Folglich muss für die zusätzlichen Kopien solcher Tabellen ausreichend Speicherplatz bereitgestellt werden. Seite 18 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Die Größe des Migrationsvolumes basiert auf der zugeordneten Größe der MySQL-Quelldatenbank, von der der Snapshot erstellt wurde. Wenn Sie also MyISAM-Tabellen oder komprimierte Tabellen verwenden, die nur einen geringen Prozentsatz der gesamten Datenbankgröße ausmachen, und wenn genügend Speicherplatz in der ursprünglichen Tabelle verfügbar ist, sollte die Migration erfolgreich ausgeführt werden können, ohne dass Speicherplatzprobleme auftreten. Sollte jedoch die ursprüngliche Datenbank nicht genügend Speicherplatz zum Speichern einer Kopie der konvertierten MyISAM-Tabellen und einer weiteren (unkomprimierten) Kopie der komprimierten Tabellen aufweisen, wird das Migrationsvolume nicht ausreichen. In einem solchen Fall müssen Sie die zugeordnete Größe der Amazon RDS MySQL-Quelldatenbank so erhöhen, dass die zusätzlichen Kopien dieser Tabellen gespeichert werden können. Anschließend erstellen Sie einen neuen Snapshot der Datenbank und migrieren diesen. Beachten Sie bei der Datenmigration in den DB-Cluster folgende Richtlinien und Einschränkungen: Obwohl Amazon Aurora bis zu 64 TB Speicher unterstützt, ist die Snapshot-Migration zum Aurora DB-Cluster auf die Größe des Amazon EBS-Volumes des Snapshots und somit auf maximal 6 TB beschränkt. In der Quelldatendank vorhandene Tabellen, die keine MyISAM-Tabellen sind, können eine Größe von 6 TB aufweisen. Allerdings sollten Sie aufgrund des zusätzlich benötigten Speicherplatzes bei der Konvertierung darauf achten, dass keine der MyISAM-Tabellen und der komprimierten Tabellen, die Sie von der MySQL DB-Instance migrieren, eine Größe von 3 TB übersteigt. Möglicherweise sollten Sie das Datenbankschema anpassen (MyISAM-Tabellen in InnoDB konvertieren und ROW_FORMAT=COMPRESSED entfernen), bevor Sie es zu Amazon Aurora migrieren. Das kann in den folgenden Fällen hilfreich sein: Seite 19 von 46 Sie möchten die Migration beschleunigen. Sie wissen nicht genau, wie viel Speicherplatz bereitgestellt werden muss. Sie haben versucht, die Daten zu migrieren. Die Migration schlug jedoch fehl, weil nicht ausreichend Speicherplatz verfügbar war. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Achten Sie darauf, diese Änderungen nicht an Ihrer Amazon RDS MySQLProduktionsdatenbank vorzunehmen. Dafür ist eine Datenbank-Instance vom Produktions-Snapshot besser geeignet. Weitere Informationen dazu finden Sie unter Reducing the Amount of Space Required to Migrate Data into Amazon Aurora im Amazon RDS-Benutzerhandbuch.5 Migrieren eines DB-Snapshots mit der Konsole Sie können einen DB-Snapshot einer Amazon RDS MySQL DB-Instance migrieren und so einen Aurora DB-Cluster erstellen. Der neue DB-Cluster wird mit den Daten von der ursprünglichen Amazon RDS MySQL DB-Instance gefüllt. Der DB-Snapshot muss von einer RDS DB-Instance mit MySQL 5.6 erstellt werden und darf nicht verschlüsselt sein. Weitere Informationen über die Erstellung eines DB-Snapshots finden Sie unter Creating a DB Snapshot im Amazon RDS-Benutzerhandbuch.6 Falls sich der DB-Snapshot nicht in der Region befindet, in der Sie den Aurora DB-Cluster speichern möchten, können Sie den DB-Snapshot mithilfe der Amazon RDS-Konsole in diese Region kopieren. Weitere Informationen über das Kopieren eines DB-Snapshots finden Sie unter Copying a DB Snapshot im Amazon RDS-Benutzerhandbuch.7 Gehen Sie wie folgt vor, um einen MySQL 5.6 DB-Snapshot mit der Konsole zu migrieren: 1. Melden Sie sich bei AWS Management Console an und öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/. 2. Wählen Sie Snapshots aus. 3. Wählen Sie auf der Seite Snapshots den Amazon RDS MySQL 5.6-Snapshot aus, der zum Aurora DB-Cluster migriert werden soll. 4. Wählen Sie Migrate Database aus. 5. Geben Sie auf der Seite Migrate Database die Werte für Ihre Umgebung und die Verarbeitungsvorgaben wie in der folgenden Abbildung ein. Beschreibungen für diese Optionen finden Sie unter Migrating a DB Snapshot by Using the Console im Amazon RDS-Benutzerhandbuch.8 Seite 20 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Abbildung 2: Snapshot-Migration Seite 21 von 46 Juni 2016 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 6. Klicken Sie auf Migrate, um den DB-Snapshot zu migrieren. Klicken Sie in der Liste der Instances auf den entsprechenden Pfeil, um die Details zum DB-Cluster aufzurufen und den Migrationsfortschritt zu überwachen. Im Detailbereich wird der Cluster-Endpunkt für die Verknüpfung mit der primä ren Instance des DB-Clusters angegeben. Weitere Informationen über die Verknüpfung mit einem Amazon Aurora DB-Cluster finden Sie unter Connecting to an Amazon Aurora DB Cluster im Amazon RDS-Benutzerhandbuch.9 Migrieren des Datenbankschemas Bei der RDS DB-Snapshot-Migration werden das vollstä ndige Schema und die Daten in die neue Aurora-Instance migriert. Falls die RDS-Snapshot-Migration nicht möglich ist (z. B. wegen des Quelldatenbank-Speicherplatzes oder weil die Anwendung beständig ausgeführt werden muss), migrieren Sie zuerst das Datenbankschema von der Quell- zur Zieldatenbank. Anschließend können Sie dann die Daten verschieben. Ein Datenbankschema ist ein Gerüst, das die logische Ansicht der gesamten Datenbank darstellt. In der Regel umfasst es Folgendes: Objekte des Datenbankspeichers: Tabellen, Spalten, Bedingungen, Indizes, Folgen, benutzerdefinierte Typen, Datentypen Objekte des Datenbankcodes: Funktionen, Prozeduren, Pakete, Auslöser, Ansichten, materialisierte Ansichten, Ereignisse, SQL-Skalierfunktionen, SQL-Inlinefunktionen, SQL-Tabellenfunktionen, Attribute, Variablen, Konstanten, Tabellentypen, öffentliche Typen, private Typen, Cursors, Ausnahmen, Parameter und andere Objekte In den meisten Fällen bleibt das Datenbankschema relativ statisch, daher wird für die Migration des Datenbankschemas keine Ausfallzeit benötigt. Das Schema der Quelldatenbank kann extrahiert werden, während diese aktiv ausgeführt wird. Dabei entsteht keine Leistungsbeeinträchtigung. Falls die Anwendung oder die Entwickler häufig Änderungen am Datenbankschema vornehmen, sollten Sie sicherstellen, dass während der Migration keine Änderungen erfolgen oder dass diese ggf. bei der Schemamigration berücksichtigt werden. In den nächsten Abschnitten werden die Methoden zur Migration des Datenbankschemas erläutert, die Sie abhängig vom Typ der Quelldatenbank verwenden können. Als Voraussetzung für die Schemamigration muss eine Aurora-Zieldatenbank erstellt und verfügbar sein. Seite 22 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Homogene Schemamigration Wenn Ihre Quelldatenbank mit MySQL 5.6 kompatibel ist und mit Amazon RDS, Amazon EC2 oder außerhalb von AWS ausgeführt wird, können Sie das Schema mit den systemeigenen MySQL-Tools exportieren und importieren. Exportieren des Datenbankschemas. Sie können das Clientdienstprogramm mysqldump zum Exportieren des Datenbankschemas verwenden. Zum Ausführen dieses Dienstprogramms müssen Sie die Quelldatenbank aufrufen und die Ausgabe des Befehls mysqldump in eine Flat-Datei umleiten. Die Option –no-data stellt sicher, dass nur das Datenbankschema (und keine Tabellendaten) exportiert wird (werden). Eine vollständige Referenz zum Befehl mysqldump finden Sie unter mysqldumpA Database Backup Program.10 mysqldump –u source_db_username –p --no-data --routines -triggers –databases source_db_name > DBSchema.sql Importieren des Datenbankschemas in Aurora. Zum Importieren des Schemas in die Aurora-Instance rufen Sie die Aurora-Datenbank über einen MySQL-Befehlszeilenclient (oder einen entsprechenden WindowsClient) auf und leiten die Inhalte der Exportdatei in MySQL um. mysql –h aurora-cluster-endpoint -u username -p < DBSchema.sql Beachten Sie Folgendes: Falls die Quelldatenbank gespeicherte Prozeduren, Auslöser und Ansichten enthält, müssen Sie die Syntax DEFINER aus der Dumpdatei löschen. Dafür können Sie den unten angegebenen, einfachen Perl-Befehl nutzen. Damit werden alle Auslöser, Ansichten und gespeicherten Prozeduren für den aktuell verbundenen Benutzer als DEFINER erstellt. Beachten Sie die in diesem Zusammenhang eventuell auftretenden Sicherheitsprobleme. $perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < DBSchema.sql > DBSchemaWithoutDEFINER.sql Seite 23 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Amazon Aurora unterstützt ausschließlich InnoDB-Tabellen. Falls in Ihrer Quelldatenbank MyISAM-Tabellen vorhanden sind, ä ndert Aurora die Engine automatisch in InnoDB, sobald der Befehl CREATE TABLE ausgeführt wird. Amazon Aurora unterstützt keine komprimierten Tabellen (das heißt, mit ROW_FORMAT=COMPRESSED erstellte Tabellen). Falls in Ihrer Quelldatenbank komprimierte Tabellen vorhanden sind, ändert Aurora ROW_FORMAT automatisch in COMPACT, sobald der Befehl CREATE TABLE ausgeführt wird. Wenn Sie das Schema von der mit MySQL 5.6 kompatiblen Quelldatenbank zu Amazon Aurora migriert haben, kopieren Sie im nächsten Schritt die Daten von der Quell- zur Zieldatenbank. Weitere Informationen finden Sie im Abschnitt AWS DMS – Einführung und Allgemeines in diesem Whitepaper. Heterogene Schemamigration Wenn Ihre Datenbank nicht mit MySQL kompatibel ist, müssen Sie das Schema in ein Format konvertieren, das mit Amazon Aurora kompatibel ist. Die Schemakonvertierung von einer Datenbank-Engine in eine andere DatenbankEngine ist eine komplexe Aufgabe, ggf. müssen bestimmte Abschnitte im Datenbank- und im Anwendungscode umgeschrieben werden. Im Wesentlichen haben Sie zwei Optionen für die Konvertierung und Migration Ihres Schemas zu Amazon Aurora: Seite 24 von 46 AWS Schema Conversion Tool. Mit AWS Schema Conversion Tool sind heterogene Datenbankmigrationen einfach, da sowohl das Schema der Quelldatenbank als auch der Großteil des benutzerdefinierten Codes – darunter Ansichten, gespeicherte Prozeduren und Funktionen – automatisch in ein mit der Zieldatenbank kompatibles Format konvertiert werden.11 Code, der nicht automatisch konvertiert werden kann, wird eindeutig gekennzeichnet, damit Sie diesen manuell konvertieren können. Sie können mit diesem Tool Ihre mit Oracle oder Microsoft SQL Server ausgeführten Quelldatenbanken in eine Amazon Aurora-, MySQL- oder PostgreSQL-Zieldatenbank (in Amazon RDS oder Amazon EC2) konvertieren. AWS Schema Conversion Tool ist zudem die bevorzugte Methode, um Ihr Oracle-, SQL Server- oder PostgreSQL-Schema in ein Aurora-kompatibles Format zu konvertieren. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Manuelle Schemamigration und Drittanbieter-Tools. Wenn Sie eine andere Quelldatenbank (also keine Oracle-, SQL Server- oder PostgreSQLDatenbank) verwenden, können Sie das Schema der Quelldatenbank entweder manuell migrieren oder es mithilfe von Drittanbieter-Tools in ein mit MySQL 5.6 kompatibles Format konvertieren. Die manuelle Schemamigration kann je nach der Größe und der Komplexität Ihres Quellschemas recht umfangreich werden. In den meisten Fällen ist die manuelle Schemakonvertierung wegen der Vorteile, die Amazon Aurora z. B. in Bezug auf Kosteneinsparungen und höhere Leistung bietet, den Aufwand wert. Schemamigration mit AWS Schema Conversion Tool AWS Schema Conversion Tool bietet eine projektbasierte Benutzeroberflä che für die automatische Konvertierung des Schemas Ihrer Quelldatenbank in ein Format, das mit Amazon Aurora kompatibel ist. Es wird empfohlen, AWS Schema Conversion Tool zur Ermittlung des Aufwands für die Datenbankmigration sowie für eine Pilotmigration (vor der Produktionsmigration) einzusetzen. Die folgende Beschreibung enthält die allgemeinen Schritte für die Verwendung von AWS Schema Conversion Tool. Eine ausführliche Anleitung finden Sie unter Getting Started im AWS Schema Conversion Tool-Benutzerhandbuch.12 1. Installieren Sie zuerst das Tool. AWS Schema Conversion Tool ist für Microsoft Windows, Mac OS X, Ubuntu Linux und Fedora Linux verfügbar. Eine detaillierte Anleitung für den Download und die Installation finden Sie unter installation and update im Benutzerhandbuch.13 Wichtig ist, wo Sie AWS Schema Conversion Tool installieren. Für die Konvertierung und Übernahme des Schemas muss das Tool direkt mit der Quell- und der Zieldatenbank verbunden sein. Achten Sie darauf, dass der Desktop, auf dem Sie AWS Schema Conversion Tool installieren, über Netzwerkkonnektivität mit der Quell- und der Zieldatenbank verfügt. 2. Installieren Sie die JDBC-Treiber. AWS Schema Conversion Tool nutzt JDBC-Treiber für die Verbindung zur Quell- und zur Zieldatenbank. Um das Tool verwenden zu können, müssen Sie diese JDBC-Treiber auf Ihren lokalen Desktop herunterladen. Eine Anleitung für den Treiber-Download finden Sie unter Required Database Drivers im AWS Schema Conversion Tool-Benutzerhandbuch.14 Ziehen Sie zudem das AWS-Forum für AWS Schema Conversion Tool für Anweisungen zur JDBC-Treiberkonfiguration für verschiedene Datenbank-Engines heran.15 Seite 25 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 3. Erstellen Sie eine Zieldatenbank. Erstellen Sie eine Amazon AuroraZieldatenbank. Eine Anleitung zum Erstellen einer Amazon AuroraDatenbank finden Sie unter Creating an Amazon Aurora DB Cluster im Amazon RDS-Benutzerhandbuch.16 4. Öffnen Sie AWS Schema Conversion Tool und starten Sie New Project Wizard. Abbildung 3: Erstellen eines neuen AWS Schema Conversion Tool-Projekts 5. Konfigurieren Sie die Quelldatenbank und testen Sie die Konnektivität zwischen AWS Schema Conversion Tool und Quelldatenbank. Damit dies funktioniert, müssen Sie die Quelldatenbank von Ihrem Desktop aus aufrufen können. Dafür sind entsprechende Netzwerk- und Firewalleinstellungen erforderlich. Seite 26 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Abbildung 4: Assistent „Create New Database Migration Project“ 6. Wählen Sie im nächsten Bildschirm das Schema der Quelldatenbank aus, das in Amazon Aurora konvertiert werden soll. Abbildung 5: Auswählen des Schemas im Migrationsassistenten Seite 27 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 7. Führen Sie den Bericht zur Bewertung der Datenbankmigration aus. Der Bericht liefert wichtige Informationen über die Konvertierung des Schemas von Ihrer Quelldatenbank in die Amazon Aurora-Ziel-Instance. Der Bericht fasst die Aufgaben der Schemakonvertierung zusammen und gibt detailliert die Aktionselemente für die Schemabereiche an, die nicht automatisch in Aurora konvertiert werden können. Im Bericht ist zudem eine Aufwandsschä tzung für die nicht automatisch konvertierten Bereiche enthalten, für die entsprechender Code in die Zieldatenbank geschrieben werden muss. Klicken Sie auf Next, um die Zieldatenbank zu konfigurieren. Sie können diesen Migrationsbericht später erneut aufrufen. Abbildung 6: Migrationsbericht 8. Konfigurieren Sie die Amazon Aurora-Zieldatenbank und testen Sie die Konnektivität zwischen AWS Schema Conversion Tool und Quelldatenbank. Damit dies funktioniert, müssen Sie die Zieldatenbank von Ihrem Desktop aus aufrufen können. Dafür sind entsprechende Netzwerk- und Firewalleinstellungen erforderlich. Klicken Sie auf Finish, um das Projektfenster aufzurufen. 9. Wenn das Projektfenster geöffnet wird, wurde bereits eine Verbindung zur Quell- und zur Zieldatenbank hergestellt. Sie können nun den detaillierten Bewertungsbericht auswerten und das Schema migrieren. Seite 28 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 10. Wählen Sie im linken Bereich, in dem das Schema Ihrer Quelldatenbank angezeigt wird, ein Schemaobjekt aus, für das ein Bewertungsbericht erstellt werden soll. Klicken Sie mit der rechten Maustaste auf das Objekt und wählen Sie Create Report aus. Abbildung 7: Erstellen des Migrationsberichts Auf der Registerkarte Summary wird eine Zusammenfassung des Berichts zur Bewertung der Datenbankmigration angezeigt. Es werden sowohl die automatisch konvertierten Elemente als auch Elemente, die nicht automatisch konvertiert werden konnten, angezeigt. Für die Schemaelemente, die nicht automatisch in die ZieldatenbankEngine konvertiert werden konnten, enthält die Zusammenfassung eine Aufwandsschätzung für die Erstellung eines (mit der Quelldatenbank) gleichwertigen Schemas in der DB-Ziel-Instance. Im Bericht wird der geschätzte Zeitaufwand für die Konvertierung dieser Schemaelemente wie folgt kategorisiert: Seite 29 von 46 Einfach – Die Aktionen können in weniger als einer Stunde abgeschlossen werden. Mittel – Die Aktionen sind komplexer und nehmen zwischen einer und vier Stunden in Anspruch. Erheblich – Die Aktionen sind sehr komplex und werden mehr als vier Stunden in Anspruch nehmen. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Abbildung 8: Migrationsbericht Wichtig: Wenn Sie den Aufwand für die Datenbankmigration auswerten, sollte dieser Bewertungsbericht unbedingt berücksichtigt werden. Studieren Sie den Bewertungsbericht genauestens und ermitteln Sie, welche Codeänderungen im Datenbankschema erforderlich sind und wie sich diese Änderungen ggf. auf die Funktionalität und das Design der Anwendung auswirken. 11. Der nächste Schritt besteht darin, das Schema zu konvertieren. Das konvertierte Schema wird nicht sofort für die Zieldatenbank übernommen. Stattdessen wird es lokal gespeichert, bis Sie das konvertierte Schema explizit für die Zieldatenbank übernehmen. Um das Schema von Ihrer Quelldatenbank zu konvertieren, wählen Sie im linken Bereich des Objekts ein zu konvertierendes Schemaobjekt aus. Klicken Sie mit der rechten Maustaste auf das Objekt und wählen Sie Convert schema aus, wie in der folgenden Abbildung dargestellt. Seite 30 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Abbildung 9: Konvertieren des Schemas Mit dieser Aktion fügen Sie das konvertierte Schema im rechten Bereich des Projektfensters hinzu und die von AWS Schema Conversion Tool automatisch konvertierten Objekte werden angezeigt. 12. Die Aktionselemente im Bewertungsbericht können Sie unterschiedlich bearbeiten: Sie können ein gleichwertiges Schema manuell hinzufügen. Sie können den Teil des Schemas, der automatisch konvertiert werden kann, in die DB-Ziel-Instance schreiben. Wählen Sie dazu im rechten Projektbereich Apply to database aus. Das Schema, das in die DB-Ziel-Instance geschrieben wird, enthält nur die Elemente, die automatisch konvertiert werden konnten. Die nicht automatisch konvertierten Elemente sind im Bericht zur Bewertung der Datenbankmigration aufgeführt. Nachdem Sie das Schema für die DB-Ziel-Instance übernommen haben, können Sie das Schema für die Elemente, die nicht automatisch konvertiert werden konnten, manuell in der DB-Ziel-Instance erstellen. In einigen Fällen ist es möglicherweise nicht möglich, ein gleichwertiges Schema in der DB-Ziel-Instance zu erstellen. Ggf. muss das Design der Anwendung und der Datenbank in Teilen überarbeitet werden, damit Sie die von der DB-Engine bereitgestellte Funktionalität für Ihre DB-Ziel-Instance nutzen können. In anderen Fällen kann das Schema, das nicht automatisch konvertiert werden kann, ignoriert werden. Seite 31 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Vorsicht: Wenn Sie das Schema in der DB-Ziel-Instance manuell erstellen, wählen Sie Apply to database erst dann aus, wenn Sie eine Kopie der manuellen Änderungen gespeichert haben. Durch die Übernahme des Schemas vom Projekt in die DB-Ziel-Instance wird ein Schema mit demselben Namen in der DB-Ziel-Instance überschrieben, sodass sämtliche der von Ihnen manuell vorgenommenen Aktualisierungen verloren gehen. Sie können das Schema der Quelldatenbank bearbeiten und das Schema im Projekt aktualisieren. Bei einigen Elementen ist es am besten, wenn Sie das Datenbankschema der Quelldatenbank an das Schema anpassen, das mit der Anwendungsarchitektur kompatibel ist und ebenfalls automatisch in die DB-Engine der DB-Ziel-Instance konvertiert werden kann. Aktualisieren Sie das Schema der Quelldatenbank und stellen Sie sicher, dass die Aktualisierungen mit der Anwendung kompatibel sind. Wählen Sie dann im linken Projektbereich Refresh from Database aus, um die Aktualisierung mit dem Schema der Quelldatenbank auszuführen. Anschließend können Sie das aktualisierte Schema konvertieren und den Bericht zur Bewertung der Datenbankmigration erneut erstellen. Das Aktionselement für das aktualisierte Schema wird nicht mehr angezeigt. 13. Um das konvertierte Schema für die Aurora-Ziel-Instance zu übernehmen, wählen Sie im rechten Projektbereich das Schemaelement aus. Klicken Sie mit der rechten Maustaste auf das Schemaelement und wählen Sie Apply to database aus, wie in der folgenden Abbildung dargestellt. Seite 32 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Abbildung 10: Übernehmen des Schemas für die Datenbank Hinweis: Wenn das konvertierte Schema zum ersten Mal für die DB-ZielInstance übernommen wird, fügt AWS Schema Conversion Tool ein zusätzliches Schema (AWS_ORACLE_EXT oder AWS_SQLSERVER_EXT) zur DB-Ziel-Instance hinzu. Über dieses Schema werden Systemfunktionen der Quelldatenbank implementiert, die zum Schreiben des konvertierten Schemas in die DB-Ziel-Instance benötigt werden. Dieses Schema sollten Sie nicht ändern, andernfalls könnten im konvertierten Schema, das in die DB-Ziel-Instance geschrieben wird, unerwünschte Ergebnisse auftreten. Nachdem das Schema vollständig in die DB-Ziel-Instance migriert ist und AWS Schema Conversion Tool nicht länger benötigt wird, können Sie das Schema AWS_ORACLE_EXT oder AWS_SQLSERVER_EXT löschen. AWS Schema Conversion Tool ist eine benutzerfreundliche Ergänzung für Ihr Migrations-Toolkit. Weitere bewä hrte Methoden für AWS Schema Conversion Tool finden Sie unter Best Practices im AWS Schema Conversion ToolBenutzerhandbuch.17 Seite 33 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Migrieren von Daten Nachdem das Datenbankschema von der Quelldatenbank in die AuroraZieldatenbank kopiert wurde, besteht der nächste Schritt in der Migration der Daten von der Quell- zur Zieldatenbank. Die Datenmigration kann mit verschiedenen Tools umgesetzt werden, empfohlen wird jedoch der Einsatz von AWS Database Migration Service (AWS DMS). Dieser Service ist sehr benutzerfreundlich und bietet alle benötigten Funktionen für diesen Schritt. AWS DMS – Einführung und Allgemeines Mit AWS Database Migration Service (AWS DMS) können Sie die Produktionsdatenbanken mit nur minimaler Ausfallzeit zu AWS migrieren. Während der Datenbankmigration können die Anwendungen weiterhin ausgeführt werden. Zudem wird durch AWS Database Migration Service gewährleistet, dass die während und nach der Migration in der Quelldatenbank geänderten Daten fortlaufend in der Zieldatenbank repliziert werden. Mithilfe von AWS Management Console können die Migrationsaufgaben in wenigen Minuten eingerichtet werden. AWS Database Migration Service kann Ihre Daten von und zu den gängigsten Datenbankplattformen migrieren, z. B. Oracle, SQL Server, MySQL, PostgreSQL, Amazon Aurora, MariaDB und Amazon Redshift. Der Service unterstützt sowohl homogene Migrationen (z. B. Oracle zu Oracle) als auch heterogene Migrationen mit verschiedenen Datenbankplattformen (z. B. Oracle zu Amazon Aurora oder SQL Server zu MySQL). Sie können einmalige Migrationen vornehmen oder die fortlaufende Replikation zwischen den Datenbanken einrichten, ohne dass die Installation oder Konfiguration von komplexer Software erforderlich ist. AWS DMS ist für lokale sowie für mit Amazon EC2 oder Amazon RDS ausgeführte Datenbanken geeignet. Jedoch kann AWS DMS nicht verwendet werden, wenn beide Datenbanken (Quelle und Ziel) lokal sind – ein Endpunkt muss sich in AWS befinden. AWS DMS unterstützt bestimmte Versionen von Oracle, SQL Server, Amazon Aurora, MySQL und PostgreSQL. Die derzeit unterstützten Versionen finden Sie im AWS Database Migration Service-Benutzerhandbuch.18 Dieses Whitepaper beschäftigt sich ausschließlich mit dem Migrationsziel Amazon Aurora. Seite 34 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Migrationsmethoden AWS DMS bietet drei Methoden für die Datenmigration: Migrieren von bestehenden Daten. Bei dieser Methode werden die Tabellen in der Zieldatenbank erstellt, die im Ziel erforderlichen Metadaten werden automatisch definiert und die Tabellen werden mit den Daten aus der Quelldatenbank gefüllt (dies wird auch als vollständiger Ladevorgang („Full Load“) bezeichnet). Für eine bessere Effizienz werden die Daten parallel aus den Tabellen geladen. Die Tabellen werden nur bei homogenen Migrationen erstellt. Sekundäre Indizes werden von AWS DMS nicht automatisch erstellt. Weitere Informationen finden Sie nachfolgend. Migrieren von bestehenden Daten und Replizieren nachfolgender Änderungen. Bei dieser Methode wird ein vollständiger Ladevorgang (wie oben beschrieben) ausgeführt, zudem werden alle laufenden Änderungen, die während des vollständigen Ladevorgangs an der Quelldatenbank erfolgen, erfasst und in der Replikations-Instance gespeichert. Nach Abschluss des vollständigen Ladevorgangs werden die gespeicherten Änderungen in die Zieldatenbank übernommen, damit diese wieder mit der Quelldatenbank übereinstimmt. Außerdem werden alle nachfolgenden Änderungen an der Quelldatenbank fortlaufend in der Zieldatenbank repliziert, sodass beide Datenbanken synchronisiert sind. Diese Migrationsmethode ist sinnvoll, wenn Sie eine Datenbankmigration mit Fast-Null-Ausfallzeit durchführen möchten. Nur Replizieren von Datenänderungen. Bei dieser Methode werden nur die Änderungen aus dem Wiederherstellungsprotokoll der Quelldatenbank ausgelesen, diese Änderungen werden dann fortlaufend in die Zieldatenbank übernommen. Sollte die Zieldatenbank nicht verfügbar sein, werden diese Änderungen in der Replikations-Instance zwischengespeichert, bis die Zieldatenbank wieder zur Verfügung steht. Wenn AWS DMS eine Migration mit vollständigem Ladevorgang ausführt, verursacht dies eine Auslastung der Tabellen in der Quelldatenbank. Das könnte die Leistung der Anwendungen beeinträchtigen, die zur gleichen Zeit auf die Datenbank zugreifen. Falls dies ein Problem darstellt, Sie aber die Anwendungen für die Dauer der Migration nicht herunterfahren können, können Sie Folgendes in Betracht ziehen: Seite 35 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Führen Sie die Migration zu einem Zeitpunkt aus, an dem die Auslastung der Datenbank seitens der Anwendung am geringsten ist. Erstellen Sie eine Read Replica der Quelldatenbank und führen Sie die AWS DMS-Migration anhand der Read Replica aus. Migrationsverfahren Die allgemeinen Schritte zur Nutzung von AWS DMS lauten wie folgt: 1. Erstellen Sie eine Zieldatenbank. 2. Kopieren Sie das Schema. 3. Erstellen Sie eine AWS DMS-Replikations-Instance. 4. Definieren Sie die Endpunkte für die Quell- und die Zieldatenbank. 5. Erstellen Sie eine Migrationsaufgabe und führen Sie diese aus. Erstellen der Zieldatenbank Erstellen Sie den Zieldatenbank-Cluster für Amazon Aurora mithilfe des Verfahrens, das unter Creating an Amazon Aurora DB Cluster im Amazon RDS-Benutzerhandbuch beschrieben ist.19 Sie sollten die Zieldatenbank so erstellen, dass Region und Instance-Typ auf Ihre Geschäftsanforderungen abgestimmt sind. Um die Migrationsleistung zu verbessern, sollten Sie zudem sicherstellen, dass die Multi-AZ-Bereitstellung für die Zieldatenbank deaktiviert ist. Sie können diese nach Abschluss des Ladevorgangs aktivieren. Kopieren des Schemas Des Weiteren sollten Sie in der Zieldatenbank ein Schema erstellen. AWS DMS unterstützt eine grundlegende Schemamigration einschließlich der Erstellung von Tabellen und primären Schlüsseln. Jedoch werden sekundäre Indizes, Fremdschlüssel, gespeicherte Prozeduren, Benutzerkonten usw. nicht automatisch von AWS DMS in der Zieldatenbank erstellt. Details zur vollständigen Schemamigration finden Sie im Abschnitt Migrieren des Datenbankschemas. Seite 36 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Erstellen einer AWS DMS-Replikations-Instance Damit Sie AWS DMS nutzen können, müssen Sie eine AWS DMS-ReplikationsInstance erstellen, die auf Ihrem VPC ausgeführt wird. Diese Instance liest die Daten aus der Quelldatenbank, führt die entsprechenden Tabellenzuweisungen aus und schreibt die Daten in die Zieldatenbank. Im Allgemeinen wird die Datenbankmigration durch eine größere Replikations-Instance beschleunigt (allerdings kann die Migration auch durch andere Faktoren wie z. B. die Kapazität der Quell- und der Zieldatenbank und die Verbindungslatenz verlangsamt werden). Die Replikations-Instance kann nach der abgeschlossenen Datenbankmigration auch beendet werden. Abbildung 11: AWS Database Migration Service Derzeit unterstützt AWS DMS die Instance-Klassen T2 und C4 als ReplikationsInstances. Die T2-Instance-Klassen sind kostengünstige Standard-Instances, die eine erweiterbare CPU-Basisleistung bieten. Mit diesen können Sie die Datenbankmigration entwickeln, konfigurieren und testen sowie regelmäßige Datenmigrationsaufgaben ausführen, für die sich die CPU-Erweiterungsoption gut eignet. Die C4-Instance-Klassen bieten höchste Prozessorleistung und somit auch eine bessere PPS (Packet Per Second)-Leistung, weniger Netzwerk-Jitter und geringere Netzwerklatenz. Die C4-Instance-Klassen sind gut geeignet, wenn Sie große Datenbanken in möglichst kurzer Zeit migrieren möchten. In der Regel wird für den vollständigen Ladevorgang nicht sehr viel InstanceSpeicher in der AWS DMS-Replikations-Instance benötigt. Wenn Sie allerdings die Replikation parallel zum vollständigen Ladevorgang ausführen, werden die Änderungen an der Quelldatenbank während der Ausführung des vollständigen Ladevorgangs in der AWS DMS-Replikations-Instance gespeichert. Falls Sie also eine sehr große Quelldatenbank migrieren, an der während der Migration viele Aktualisierungen erfolgen, kann auch sehr viel Instance-Speicher erforderlich sein. Die C4-Instance-Familie bietet 100 GB Instance-Speicher, die T2-InstanceFamilie bietet 50 GB. Normalerweise ist dieser Speicher für die meisten Migrationsszenarios mehr als ausreichend. Seite 37 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 In einigen Extremfällen, in denen sehr umfangreiche Datenbanken mit hohen Transaktionsraten und aktivierter Replikation migriert werden, kann die AWS DMS-Replikation möglicherweise nicht alle Änderungen rechtzeitig verarbeiten. In einer solchen Situation kann es erforderlich sein, die Änderungen an der Quelldatenbank für einige Minuten auszusetzen, damit die Replikation alle bis dato erfolgten Änderungen umsetzen kann. Danach können Sie die Anwendung wieder auf die Aurora-Zieldatenbank ausrichten. Abbildung 12: Seite zum Erstellen einer Replikations-Instance in der AWS DMS-Konsole Definieren der Endpunkte für die Quell- und die Zieldatenbank Ein Datenbank-Endpunkt wird von der Replikations-Instance für die Verbindung zu einer Datenbank verwendet. Für die Datenbankmigration muss ein Endpunkt für die Quelldatenbank und ein Endpunkt für die Zieldatenbank erstellt werden. Bei den festgelegten Datenbank-Endpunkten kann es sich um einen lokalen und einen mit Amazon EC2 oder Amazon RDS ausgeführten Endpunkt handeln – jedoch dürfen nicht für die Quelle und das Ziel lokale Endpunkte angegeben werden. Es wird empfohlen, die Verbindung der Datenbank-Endpunkte nach der Erstellung zu testen. Sie können dieselbe Seite, die Sie zum Erstellen der Datenbank-Endpunkte verwendet haben, auch zum Testen verwenden (dies wird später in diesem Whitepaper erlä utert). Seite 38 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Hinweis: Wenn im Quellschema Fremdschlüsseleinschränkungen vorhanden sind, müssen Sie beim Erstellen des Zielendpunkts für Extra connection attributes im Abschnitt Advanced Folgendes eingeben: initstmt=SET FOREIGN_KEY_CHECKS=0 Damit werden die Fremdschlüsselprüfungen während des Ladevorgangs der Zieltabellen deaktiviert. Auf diese Weise wird verhindert, dass der Ladevorgang durch fehlerhafte Fremdschlüsselprüfungen bei nur teilweise geladenen Tabellen unterbrochen wird. Abbildung 13: Seite zum Erstellen des Datenbank-Endpunkts in der AWS DMS-Konsole Seite 39 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Erstellen und Ausführen einer Migrationsaufgabe Nachdem Sie die Endpunkte der Quell- und der Zieldatenbank erstellt und getestet haben, können Sie nun eine Aufgabe für die Datenmigration erstellen. Bei der Erstellung dieser Aufgabe geben Sie die erstellte Replikations-Instance, die Methode der Datenbankmigration (wie zuvor beschrieben), den Endpunkt der Quelldatenbank sowie den Endpunkt der Zieldatenbank für den DatenbankCluster in Amazon Aurora an. Zudem sollten Sie nach der Erstellung des vollständigen Schemas in der Datenbank unter Task Settings die Option Target table preparation mode in Do nothing ändern, anstatt den Standardwert Drop tables on target zu verwenden. Da beim Standardwert die Tabellen verworfen und neu erstellt werden, kann dies zu einem teilweisen Verlust Ihrer Schemadefinition (wie z. B. Fremdschlüsseleinschränkungen) führen. Im Rahmen der Aufgabenerstellung können Sie Tabellenzuweisungen erstellen, die das Quellschema sowie die entsprechenden Tabellen enthalten, die zum Zielendpunkt migriert werden sollen. Bei der standardmäßigen Zuweisungsmethode werden alle Quelltabellen den Zieltabellen gleichen Namens zugewiesen, sofern diese vorhanden sind. Andernfalls werden die Quelltabellen im Ziel erstellt (dies ist abhängig von den Aufgabeneinstellungen). Wenn nur bestimmte Tabellen migriert werden sollen oder mehr Kontrolle über die Feldund Tabellenzuweisung erforderlich ist, können Sie auch benutzerdefinierte Zuweisungen erstellen (mit einer JSON-Datei). Sie können entweder ein Schema oder alle Schemata vom Quellendpunkt migrieren. Seite 40 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Abbildung 14: Seite zum Erstellen der Aufgabe in der AWS DMS-Konsole Mit AWS Management Console können Sie den Fortschritt bei den Aufgaben von AWS Database Migration Service (AWS DMS) überwachen. Sie können ebenfalls die verwendeten Ressourcen und die Netzwerkkonnektivität überwachen. In der AWS DMS-Konsole werden einfache Statistiken zu jeder Aufgabe angezeigt, darunter der Aufgabenstatus, Prozent abgeschlossen, verstrichene Zeit und Tabellenstatistiken, wie in der folgenden Abbildung dargestellt. Des Weiteren können Sie eine Aufgabe auswählen und die Leistungsmetrik für diese anzeigen, z. B. Durchsatz, migrierte Datensätze pro Sekunde, Festplattenund Speichernutzung sowie Latenz. Abbildung 15: Aufgabenstatus in der AWS DMS-Konsole Seite 41 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Tests und Umstellung Nachdem das Schema und die Daten erfolgreich von der Quelldatenbank zu Amazon Aurora migriert sind, können Sie für die Migration nun End-to-EndTests durchführen. Die Testmethode sollte nach jeder Testmigration verfeinert werden und der abschließende Migrationsplan sollte auch einen Testplan enthalten, damit die migrierte Datenbank entsprechend getestet werden kann. Migrationstests Testkategorie Zweck Grundlegende Diese Tests vor der Umstellung sollten nach Abschluss der Datenmigration automatisch ausgeführt werden. Mit ihnen soll in erster Linie überprüft werden, ob die Datenmigration erfolgreich war. Nachfolgend finden Sie einige gängige Ergebnisse dieser Tests: Akzeptanztests • Gesamtanzahl der verarbeiteten Elemente • Gesamtanzahl der importierten Elemente • Gesamtanzahl der übersprungenen Elemente • Gesamtanzahl der Warnungen • Gesamtanzahl der Fehler Falls eines dieser in den Tests ausgegebenen Ergebnisse vom Prognosewert abweicht, gilt die Migration als fehlgeschlagen. Die aufgetretenen Probleme müssen vor dem nächsten Schritt oder der nächsten Testphase behoben werden. Funktionstests Bei diesen Tests nach der Umstellung wird die Funktionalität der Anwendungen getestet, die Aurora als Datenspeicher verwenden. Die Tests sind eine Kombination aus automatischen und manuellen Tests. Diese Funktionstests sollen in erster Linie Anwendungsprobleme ermitteln, die aus der Datenmigration zu Aurora resultieren. Nicht funktionsbezogene Bei diesen Tests nach der Umstellung werden die Anwendungseigenschaften, die nicht funktionsbezogen sind, getestet (z. B. die Leistung mit verschiedenen Lasten). Tests Benutzerakzeptanztests Seite 42 von 46 Diese Tests nach der Umstellung sollten von den Anwendungsbenutzern nach Abschluss der Datenmigration und der erfolgten Umstellung durchgeführt werden. Mit diesen Tests sollen die Benutzer entscheiden, ob die Anwendung zweckmäßig in der Organisation eingesetzt werden kann. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Umstellung Nach Abschluss der Migration und erfolgten Tests können Sie nun die Anwendung auf die Amazon Aurora-Datenbank ausrichten. Diese Migrationsphase wird als Umstellung (Cutover) bezeichnet. Sofern die Planungsund die Testphase ordnungsgemäßdurchgeführt wurden, sollte die Umstellung nicht zu unerwarteten Problemen führen. Aktionen vor der Umstellung Seite 43 von 46 Legen Sie ein Umstellungsfenster fest: Ermitteln Sie einen Zeitpunkt, an dem die Umstellung auf die neue Datenbank mit minimaler Störung des Geschäftsablaufs ausgeführt werden kann. In der Regel bietet sich dafür ein Zeitraum an, in dem die Datenbank möglichst wenig genutzt wird (meist in der Nacht oder am Wochenende). Stellen Sie sicher, dass alle Änderungen aktualisiert wurden: Sie haben die Migrationsmethode der Fast-Null-Ausfallzeit verwendet, um die Datenbankänderungen von der Quell- in die Zieldatenbank zu replizieren. Daher müssen Sie sicherstellen, dass alle Datenbankänderungen übernommen werden und in der Zieldatenbank keine nennenswerte Aktualisierungsverzögerung im Vergleich zur Quelldatenbank vorliegt. Bereiten Sie Scripts für die Konfigurationsä nderungen der Anwendung vor: Für die Umstellung müssen die Details der Datenbankverbindung in den Konfigurationsdateien der Anwendung geändert werden. Bei großen und komplexen Anwendungen müssen die Verbindungsdetails ggf. an mehreren Stellen angepasst werden. Sorgen Sie dafür, dass die benötigten Scripts einsatzbereit sind, damit die Verbindungskonfiguration schnell und zuverlässig aktualisiert werden kann. Stoppen Sie die Anwendung: Halten Sie die Anwendungsprozesse in der Quelldatenbank an und versetzen Sie die Quelldatenbank in den schreibgeschützten Modus, damit keine weiteren Schreibvorgänge mehr in die Quelldatenbank erfolgen können. Falls die Änderungen in der Quelldatenbank nicht sofort vollständig in die Zieldatenbank übernommen werden können, warten Sie, bis diese Änderungen vollständig in die Zieldatenbank repliziert wurden. Führen Sie Tests vor der Umstellung aus: Führen Sie die automatischen Test vor der Umstellung aus, um die erfolgreiche Datenmigration sicherzustellen. Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Umstellung Führen Sie die Umstellung durch: Wurden die Tests vor der Umstellung erfolgreich beendet, können Sie die Anwendung nun auf Amazon Aurora ausrichten. Führen Sie die in der Phase vor der Umstellung erstellten Scripts zur Änderung der Anwendungskonfiguration aus, damit die Anwendung auf die neue Aurora-Datenbank ausgerichtet wird. Starten Sie die Anwendung: Sie können die Anwendung nun starten. Falls möglich, unterbinden Sie den Benutzerzugriff auf die Anwendung während der Anwendungsausführung, bis die Tests nach der Umstellung ausgeführt wurden. Tests nach der Umstellung Führen Sie Tests nach der Umstellung aus: Führen Sie die vordefinierten automatischen oder manuellen Testfälle aus. So stellen Sie sicher, dass das Zusammenspiel von Anwendung und neuer Datenbank erwartungsgemäß funktioniert. Als gute Strategie gilt, zunächst die schreibgeschützte Funktionalität der Datenbank zu testen. Anschließend können Sie die Tests ausführen, bei denen in die Datenbank geschrieben wird. Gewähren Sie den Benutzern Zugriff und überwachen Sie sorgfältig: Nach der erfolgreichen Ausführung der Testfälle können Sie den Benutzern Zugriff auf die Anwendung gewähren, um die Migration abzuschließen. Sowohl die Anwendung als auch die Datenbank sollten dabei sorgfältig überwacht werden. Fazit Amazon Aurora ist eine für die Cloud entwickelte Datenbank für Unternehmen, die hohe Leistung und Hochverfügbarkeit bietet. Der Einsatz von Amazon Aurora ermöglicht eine bessere Leistung und höhere Verfügbarkeit als andere Open Source-Datenbanken, zudem sind die Kosten deutlich geringer als bei den meisten kommerziellen Datenbanken. In diesem Whitepaper werden Strategien vorgestellt, um die beste Methode für die Datenbankmigration zu Amazon Aurora zu ermitteln. Zudem werden die Schritte für die Migrationsplanung und -ausführung detailliert erlä utert. Für heterogene Migrationsszenarios werden insbesondere die Tools AWS Database Migration Service (AWS DMS) und AWS Schema Conversion Tool empfohlen. Diese leistungsstarken Tools können die Kosten sowie die Komplexität von Datenbankmigrationen ganz erheblich reduzieren. Seite 44 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora Juni 2016 Mitwirkende Dieses Dokument ist unter der Mitarbeit folgender Personen und Organisationen entstanden: Puneet Agarwal, Solutions Architect, Amazon Web Services Scott Williams, Solutions Architect, Amazon Web Services Weitere Informationen Zusätzliche Informationen finden Sie in den folgenden Ressourcen: Amazon Aurora – Produktdetails Häufig gestellte Fragen zu Amazon Aurora Amazon Database Migration Service Amazon Database Migration Service – Häufig gestellte Fragen Anmerkungen 1 https://aws.amazon.com/rds/aurora/ 2 http://aws.amazon.com/rds/aurora/pricing/ 3 https://d0.awsstatic.com/productmarketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf 4 http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/ Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication 5 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/ Aurora.Migrate.html#USER_ImportAurora.PreImport 6 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html 7 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html 8 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/ Aurora.Migrate.html#USER_ImportAuroraCluster.Console Seite 45 von 46 Amazon Web Services – Migrieren von Datenbanken zu Amazon Aurora 9 Juni 2016 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html 10 https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html 11 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html 12 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/ CHAP_SchemaConversionTool.GettingStarted.html 13 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/ CHAP_SchemaConversionTool.Installing.html 14 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide /CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing .JDBCDrivers 15 https://forums.aws.amazon.com/forum.jspa?forumID=208 16 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html 17 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/ CHAP_SchemaConversionTool.BestPractices.html Seite 46 von 46 18 http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html 19 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html
