Arbeiten mit DB-Instance-Lesereplikaten - Amazon Relational Database Service

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Arbeiten mit DB-Instance-Lesereplikaten

Ein Lesereplikat ist eine schreibgeschützte Kopie einer DB-Instance. Sie können die Arbeitslast Ihrer primären DB-Instance reduzieren, indem Sie Abfragen aus Ihren Anwendungen an das Lesereplikat weiterleiten. Dies ermöglicht eine elastische Aufskalierung über die Kapazitätseinschränkungen einer einzelnen DB-Instance für leseintensive Datenbank-Workloads hinaus.

Amazon RDS nutzt die integrierten Replikationsfunktionen der DB-Engine, um ein Lesereplikat aus einer Quell-DB-Instance zu erstellen. Weitere Informationen zur Verwendung dieser Lesereplikate mit einer bestimmten Engine finden Sie in den folgenden Abschnitten:

Nachdem Sie ein Lesereplikat aus einer Quell-DB-Instance erstellt haben, wird die Quelle zur primären DB-Instance. Wenn Sie Updates an der primären DB-Instance vornehmen, kopiert Amazon RDS sie asynchron in das Lesereplikat. Das folgende Diagramm zeigt eine Quell-DB-Instance, die auf ein Lesereplikat in einer anderen Availability Zone (AZ) repliziert. Die Clients haben Lese-/Schreibzugriff auf die primäre DB-Instance und schreibgeschützten Zugriff auf das Replikat.


            Read Replica-Konfiguration

Übersicht über Amazon RDS-Lesereplikate

In den folgenden Abschnitten werden DB-Instance-Lesereplikate behandelt. Informationen zu Lesereplikaten von Multi-AZ-DB-Clustern finden Sie unter Arbeiten mit Multi-AZ-DB-Cluster-Lesereplikaten.

Anwendungsfälle für Lesereplikate

Die Bereitstellung eines oder mehrerer Lesereplikate für eine bestehende Quell-DB-Instance kann in einer Vielfalt von Szenarien sinnvoll sein, einschließlich der Folgenden:

  • Skalierung über die Rechen- oder I/O-Kapazität einer einzelnen DB-Instance hinaus, bei Datenbank-Workloads mit intensiven Lesevorgängen. Sie können diesen übermäßigen Datenverkehr an Lesevorgängen einem oder mehreren Lesereplikaten zuweisen.

  • Unterstützung des Lesedatenverkehrs bei einer nicht verfügbaren Quell-DB-Instance. In einigen Fällen kann Ihre Quell-DB-Instance möglicherweise keine I/O-Anforderungen bearbeiten, z. B. aufgrund von I/O-Einschränkungen für Backups oder geplante Wartungsarbeiten. In diesen Fällen können Sie den Lesedatenverkehr an Ihre Lesereplikate leiten. Denken Sie bei diesem Anwendungsfall daran, dass die Daten im Lesereplikat "veraltet" sein können, da die Quell-DB-Instance nicht verfügbar ist.

  • Szenarien mit Geschäftsberichten oder Data-Warehousing, bei denen es sich eventuell empfiehlt, Abfragen zu Geschäftsberichten über ein Lesereplikat und nicht über Ihre Produktions-DB-Instance laufen zu lassen.

  • Implementieren der Notfallwiederherstellung Sie können ein Lesereplikat als Lösung zur Notfallwiederherstellung auf eine eigenständige Instance hochstufen, wenn die primäre DB-Instance ausfällt.

Funktionsweise von Lesereplikaten

Wenn Sie ein Lesereplikat erstellen, legen Sie zuerst eine bestehende DB-Instance als Quelle fest. Dann erstellt Amazon RDS einen Snapshot von der Quell-Instance und erstellt eine schreibgeschützte Instance aus diesem Snapshot. Dann verwendet Amazon RDS die asynchrone Replikationsmethode für die DB-Engine, um das Lesereplikat bei jeder Änderung an der primären DB-Instance zu aktualisieren.

Das Lesereplikat wird als eine DB-Instance ausgeführt, die nur schreibgeschützte Verbindungen zulässt. Eine Ausnahme bildet die DB-Engine von RDS für Oracle, die Replikat-Datenbanken im gemounteten Modus unterstützt. Ein aufgespieltes Replikat akzeptiert keine Benutzerverbindungen und kann daher keinen schreibgeschützten Workload bereitstellen. Die primäre Verwendung für aufgespielte Replikate ist die überregionale Notfallwiederherstellung. Weitere Informationen finden Sie unter Arbeiten mit Lese-Replikaten für Amazon RDS für Oracle.

Anwendungen verbinden sich mit dem Lesereplikat so wie mit einer DB-Instance. Amazon RDS repliziert alle Datenbanken in der Quell-DB-Instance.

Lesereplikate in einer Multi-AZ-Bereitstellung

Sie können ein Lesereplikat für eine DB-Instance konfigurieren, für die auch ein Standby-Replikat für hohe Verfügbarkeit in einer Multi-AZ-Bereitstellung konfiguriert ist. Die Replikation mit dem Standby-Replikat erfolgt synchron. Im Gegensatz zu Lesereplikaten kann ein Standby-Replikat keinen Lesedatenverkehr bereitstellen.

Im folgenden Szenario haben Clients Lese-/Schreibzugriff auf eine primäre DB-Instance in einer AZ. Die primäre Instance kopiert Updates asynchron auf ein Lesereplikat in einer zweiten AZ und kopiert sie auch synchron auf ein Standby-Replikat in einer dritten AZ. Clients haben nur Lesezugriff auf das Lesereplikat.


                    Konfiguration von Read Replica und Standby-Replikat

Weitere Informationen zu Hochverfügbarkeits- und Standby-Replikaten finden Sie unter Konfiguration und Verwaltung einer Multi-AZ-Bereitstellung.

Regionsübergreifende Lesereplikate

In einigen Fällen befindet sich ein Lesereplikat in einer anderen AWS-Region als seine primäre DB-Instance. In diesen Fällen richtet Amazon RDS einen sicheren Kommunikationskanal zwischen der primären DB-Instance und dem Lesereplikat ein. Amazon RDS richtet alle AWS Sicherheitskonfigurationen ein, die zum Aktivieren des sicheren Kanals erforderlich sind, z. B. das Hinzufügen von Sicherheitsgruppeneinträgen. Weitere Informationen zu regionsübergreifenden Read Replicas finden Sie unter Erstellen eines Lesereplikats in einer anderen AWS-Region.

Die Informationen in diesem Kapitel gelten für das Erstellen von Amazon-RDS-Lesereplikaten entweder in derselben AWS-Region wie die Quell-DB-Instance oder in einer separaten AWS-Region. Die folgenden Informationen gelten nicht für das Einrichten einer Replikation für eine Instance die mit einer Amazon-EC2-Instance oder On-Premises ausgeführt wird.

Unterschiede zwischen Lesereplikaten für DB-Engines

Da Amazon RDS-DB-Engines die Replikation jeweils anders implementieren, gibt es einige wichtige Unterschiede, die Sie kennen sollten, wie in der folgenden Tabelle aufgezeigt.

Funktion oder Verhalten MySQL und MariaDB Oracle PostgreSQL SQL Server

Was ist die Replikationsmethode?

Logische Replikation.

Physikalische Replikation.

Physikalische Replikation.

Physikalische Replikation.

Wie werden Transaktionsprotokolle bereinigt?

RDS for MySQL und RDS for MariaDB behalten alle Binärprotokolle bei, die nicht angewendet wurden.

Wenn eine primäre DB-Instance keine regionsübergreifenden Lesereplikate hat, behält Amazon RDS for Oracle Transaktionsprotokolle im Umfang von mindestens zwei Stunden auf der Quell-DB-Instance bei. Protokolle werden nach zwei Stunden oder nach Ablauf der Einstellung für die Aufbewahrungszeit der Archivprotokolle, je nachdem, welcher Zeitraum länger dauert, aus der Quell-DB-Instance bereinigt. Protokolle werden nach Ablauf der Einstellung für die Aufbewahrungszeit der Archivprotokolle nur dann aus dem Lesereplikat bereinigt, wenn sie erfolgreich auf die Datenbank angewendet wurden.

In manchen Fällen kann eine primäre DB-Instance ein oder mehrere regionsübergreifende Lesereplikate haben. Wenn dies der Fall ist, behält Amazon RDS for Oracle die Transaktionsprotokolle auf der Quell-DB-Instance bei, bis diese übertragen und auf alle regionsübergreifenden Lesereplikate angewendet wurden.

Weitere Informationen zum Festlegen von Aufbewahrungszeiten für Archivprotokolle finden Sie unter Beibehaltung von archivierten Redo-Log-Dateien.

PostgreSQL verfügt über den Parameter wal_keep_segments, der vorgibt, wie viele Write-Ahead-Log-Dateien (WAL) für die Bereitstellung von Daten an die Lesereplikate beibehalten werden. Der Parameterwert gibt die Anzahl an beizubehaltenden Protokollen an.

Die Virtual Log File (VLF) der Transaktionsprotokolldatei auf dem primären Replikat kann abgeschnitten werden, nachdem sie für die sekundären Replikate nicht mehr benötigt wird.

Die VLF kann nur dann als inaktiv markiert werden, wenn die Protokolldatensätze in den Replikaten gehärtet wurden. Unabhängig davon, wie schnell sich die Datenträger-Subsysteme im primären Replikat befinden, werden die VLFs im Transaktionsprotokoll beibehalten, bis das langsamste Replikat es ausgehärtet hat.

Kann ein Replica beschreibbar gemacht werden?

Ja. Sie können die MySQL- oder MariaDB-Lesereplikate aktivieren, um sie beschreibbar zu machen.

Nein. Ein Oracle-Lesereplikat ist eine physische Kopie und Oracle erlaubt keine Schreibvorgänge in ein Lesereplikat. Sie können das Lesereplikat hochstufen, um es beschreibbar zu machen. Das hochgestufte Lesereplikat weist die replizierten Daten bis zu dem Punkt auf, an dem die Anforderung zum Hochstufen ausgegeben wurde.

Nein. Ein PostgreSQL-Lesereplikat ist eine physische Kopie und PostgreSQL lässt nicht zu, dass ein Lesereplikat beschreibbar gemacht wird.

Nein. Ein SQL Server-Lesereplikat ist eine physische Kopie und erlaubt auch keine Schreibvorgänge. Sie können das Lesereplikat hochstufen, um es beschreibbar zu machen. Das hochgestufte Lesereplikat weist die replizierten Daten bis zu dem Punkt auf, an dem die Anforderung zum Hochstufen ausgegeben wurde.

Können Backups von Replica erstellt werden?

Ja. Automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für MySQL oder RDS für MariaDB unterstützt.

Ja. Automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für Oracle unterstützt.

Ja, Sie können einen manuellen Snapshot von Lesereplikaten von RDS für PostgreSQL erstellen. Automatisierte Backups für Lesereplikate werden nur für RDS for PostgreSQL 14.1 und höhere Versionen unterstützt. Sie können keine automatisierten Backups für PostgreSQL-Lesereplikate für RDS for PostgreSQL Versionen vor 14.1 aktivieren. Erstellen Sie für RDS for PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen.

Nein, automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für SQL Server nicht unterstützt.

Kann ich parallele Replikation anwenden?

Ja. Alle unterstützten MariaDB- und MySQL-Versionen lassen parallele Replikations-Threads zu.

Ja. Wiederholungsprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt.

Nein. PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation.

Ja. Wiederholungsprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt.

Können Sie ein Replikat in einem aufgespielten und nicht in einem schreibgeschützten Zustand pflegen?

Nein.

Ja. Die primäre Verwendung für aufgespielte Replikate ist die überregionale Notfallwiederherstellung. Für aufgespielte Replikate ist keine Active Data Guard-Lizenz erforderlich. Weitere Informationen finden Sie unter Arbeiten mit Lese-Replikaten für Amazon RDS für Oracle.

Nein.

Nein.

Lesereplikat-Speichertypen

Ein Lesereplikat wird standardmäßig mit dem selben Speichertyp erstellt wie die Quell-DB-Instance. Jedoch können Sie ein Lesereplikat erstellen, das einen anderen Speicherchip aufweist als die Quell-DB-Instance, basierend auf den in der folgenden Tabelle gelisteten Optionen.

Quell-DB-Instance-Speichertyp Quell-DB-Instance-Speicherzuteilung Optionen für den Lesereplikat-Speichertyp
Bereitgestellte IOPS 100 GiB–64 TiB Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch
Allgemeine Zwecke 100 GiB–64 TiB Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch
Allgemeine Zwecke <100 GiB Allgemeine Zwecke, magnetisch
Magnetic 100 GiB–6 TiB Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch
Magnetic <100 GiB Allgemeine Zwecke, magnetisch
Anmerkung

Wenn Sie den zugewiesenen Speicher eines Lesereplikats erhöhen, muss er um mindestens 10 Prozent erhöht werden. Wenn Sie versuchen, den Wert um weniger als 10 Prozent zu erhöhen, erhalten Sie einen Fehler.

Einschränkungen beim Erstellen eines Replikats aus einem Replikat

Amazon RDS unterstützt keine zirkulierende Replikation. Sie können eine DB-Instance nicht so konfigurieren, dass Sie als Replikationsquelle für eine vorhandene DB-Instance dient. Sie können ein neues Lesereplikat nur aus einer vorhandenen DB-Instance erstellen. Wenn beispielsweise MySourceDBInstance in ReadReplica1 repliziert wird, können Sie ReadReplica1 nicht für eine Rückreplikation auf MySourceDBInstance konfigurieren.

Bei RDS für MariaDB und RDS für MySQL und bei bestimmten Versionen von RDS für PostgreSQL ist es möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen. Sie können beispielsweise ein neues Lesereplikat ReadReplica2 aus einem vorhandenen Replikat ReadReplica1 erstellen. Bei RDS für Oracle und RDS für SQL Server ist es nicht möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen.

Überlegungen zum Löschen von Replikaten

Wenn Sie keine Read Replicas mehr benötigen, können Sie diese mit denselben Mechanismen wie zum Löschen einer DB-Instance explizit löschen. Wenn Sie eine Quell-DB-Instance löschen, ohne ihre Lesereplikate in derselben zu löschen AWS-Region, wird jedes Lesereplikat zu einer eigenständigen DB-Instance hochgestuft. Weitere Informationen zum Löschen einer DB-Instance finden Sie unter Löschen einer DB-Instance. Weitere Informationen zum Hochstufen von Read Replicas finden Sie unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance.

Wenn Sie regionsübergreifende Lesereplikate haben, finden Sie unter Überlegungen zur regionsübergreifenden Replikation Informationen zum Löschen der Quell-DB-Instance für regionsübergreifende Lesereplikate.

Erstellen eines Lesereplikats

Sie können ein Lesereplikat aus einer vorhandenen DB-Instance mithilfe der AWS Management Console, AWS CLIoder RDS-API erstellen. Sie erstellen ein Lesereplikat, indem Sie SourceDBInstanceIdentifier angeben, die eine DB-Instance-Kennung der Quell-DB-Instance ist, aus der Sie replizieren möchten.

Wenn Sie ein Lesereplikat erstellen, fertigt Amazon RDS einen DB-Snapshot Ihrer Quell-DB-Instance an und beginnt mit der Replikation. Das hat eine kurze Aussetzung des I/O-Datenverkehrs Ihrer Quell-DB-Instance während des DB-Snapshots zur Folge.

Anmerkung

Die I/O-Aussetzung dauert in der Regel etwa eine Minute. Sie können die I/O-Aussetzung vermeiden, wenn es sich bei der DB-Instance um eine Multi-AZ-Bereitstellung handelt, weil in diesem Fall der Snapshot von der sekundären DB-Instance aufgenommen wird.

Eine aktive, langlaufende Transaktion kann den Prozess der Erstellung des Lesereplikats verlangsamen. Wir empfehlen Ihnen zu warten, bis langlaufende Transaktionen abgeschlossen sind, bevor ein Lesereplikat erstellt wird. Wenn Sie mehrere Lesereplikate parallel aus derselben Quell-DB-Instance erstellen, macht Amazon RDS nur einen Snapshot zu Beginn der ersten Erstellungsaktion.

Beim Erstellen eines Lesereplikats müssen einige Dinge beachtet werden. Als Erstes müssen Sie automatische Backups für die DB-Instance aktivieren, indem sie den Aufbewahrungszeitraum für Backups auf einen anderen Wert als 0 festlegen. Diese Erfordernis gilt auch für ein Lesereplikat, das die Quell-DB-Instance für ein anderes Lesereplikat ist. Wenn Sie automatische Backups auf einem Lesereplikat für RDS for MySQL aktivieren möchten, erstellen Sie zuerst das Lesereplikat und ändern Sie es dann, um automatische Backups zu aktivieren.

Anmerkung

Innerhalb einer wird dringend empfohlen AWS-Region, alle Lesereplikate in derselben Virtual Private Cloud (VPC) basierend auf Amazon VPC als Quell-DB-Instance zu erstellen. Wenn Sie ein Lesereplikat in einer anderen VPC als der Quell-DB-Instance erstellen, können Classless Inter-Domain Routing (CIDR)-Bereiche zwischen dem Replikat und dem RDS-System einander überlappen. Die CIDR-Überlappung macht das Replikat instabil, was sich negativ auf Anwendungen auswirken kann, die eine Verbindung herstellen. Wenn beim Erstellen des Lesereplikats eine Fehlermeldung angezeigt wird, wählen Sie eine andere Ziel-DB-Subnetzgruppe aus. Weitere Informationen finden Sie unter Arbeiten mit einer DB-Instance in einer VPC.

Es gibt keine direkte Möglichkeit, ein Lesereplikat in einem anderen AWS-Konto mit der Konsole oder zu erstellen AWS CLI.

Zum Erstellen einer Read Replica aus einer Quell-DB-Instance
  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Databases (Datenbanken) aus.

  3. Wählen Sie die DB-Instance aus, die Sie als Quelle für eine Read Replica verwenden möchten.

  4. Wählen Sie unter Aktionen Create read replica (Read Replica erstellen) aus.

  5. Geben Sie unter DB instance identifier (DB-Instance-Kennung) einen Namen für das Lesereplikat ein.

  6. Wählen Sie Ihre Instance-Konfiguration. Wir empfehlen Ihnen, dieselbe oder eine größere DB-Instance-Klasse und denselben Speichertyp wie bei der Quell-DB-Instance für das Lesereplikat zu verwenden.

  7. Legen Sie unter AWS-Region die Zielregion für das Lesereplikat fest.

  8. Legen Sie unter Speicher die Größe des zugewiesenen Speichers fest und geben Sie an, ob Sie die automatische Speicherskalierung verwenden möchten.

    Wenn Ihre Quell-DB-Instance nicht die neueste Speicherkonfiguration aufweist, ist die Option Speicherdateisystemkonfiguration aktualisieren verfügbar. Sie können diese Einstellung aktivieren, um das Speicherdateisystem des Lesereplikats auf die bevorzugte Konfiguration zu aktualisieren. Weitere Informationen finden Sie unter Upgrade des Speicherdateisystems für eine DB-Instance.

  9. Wählen Sie unter Verfügbarkeit aus, ob eine Standby-Version des Replikats in einer anderen Availability Zone als Failover-Support für das Replikat erstellt werden soll.

    Anmerkung

    Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

  10. Legen Sie weitere DB-Instance-Einstellungen fest. Weitere Informationen zu den verfügbaren Einstellungen finden Sie unter Einstellungen für DB-Instances.

  11. Um ein verschlüsseltes Lesereplikat zu erstellen, erweitern Sie Zusätzliche Konfiguration und geben Sie die folgenden Einstellungen an:

    1. Wählen Sie Enable encryption (Verschlüsselung aktivieren) aus.

    2. AWS KMS keyWählen Sie für die AWS KMS key Kennung des KMS-Schlüssels aus.

    Anmerkung

    Die DB-Quell-Instance muss verschlüsselt werden. Weitere Informationen über das Verschlüsseln der Quell-DB-Instance finden Sie unter Verschlüsseln von Amazon RDS-Ressourcen.

  12. Wählen Sie Read Replica erstellen aus.

Nachdem die Read Replica erstellt wurde, können Sie sie auf der Seite „ Datenbanken “ in der RDS-Konsole sehen. Es zeigt Replica in der Spalte Rolle.

Um ein Lesereplikat aus einer Quell-DB-Instance zu erstellen, verwenden Sie den AWS CLI Befehl create-db-instance-read-replica . In diesem Beispiel wird außerdem die Größe des zugewiesenen Speichers festgelegt, die automatische Speicherskalierung aktiviert und das Dateisystem auf die bevorzugte Konfiguration aktualisiert.

Sie können andere Einstellungen festlegen. Weitere Informationen zu den einzelnen Einstellungen finden Sie unter Einstellungen für DB-Instances.

Beispiel

Für Linux, macOSoder Unix:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-instance-identifier mydbinstance \ --allocated-storage 100 \ --max-allocated-storage 1000 \ --upgrade-storage-config

Windows:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-instance-identifier mydbinstance ^ --allocated-storage 100 ^ --max-allocated-storage 1000 ^ --upgrade-storage-config

Um eine Read Replica aus einer MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-Quell-DB-Instance zu erstellen, verwenden Sie die Amazon RDS-API-Aktion CreateDBInstanceReadReplica mit den folgenden erforderlichen Parametern:

  • DBInstanceIdentifier

  • SourceDBInstanceIdentifier

Hochstufen eines Lesereplikats zur eigenständigen DB-Instance

Sie können eine Read Replica in eine eigenständige DB-Instance hochstufen. Wenn eine Quell-DB-Instance über mehrere Lesereplikate verfügt, hat das Hochstufen eines der Lesereplikate zu einer DB-Instance keine Auswirkung auf die anderen Replikate.

Wenn Sie ein Lesereplikat hochstufen, startet RDS die DB-Instance neu, bevor es verfügbar gemacht wird. Das Hochstufen kann einige Minuten oder mehr in Anspruch nehmen, abhängig von der Größe des Lesereplikats.


            Hochstufen eines Lesereplikats

Anwendungsfälle für das Hochstufen eines Lesereplikats

Möglicherweise möchten Sie aus einem der folgenden Gründe ein Lesereplikat zu einer eigenständigen DB-Instance hochstufen:

  • Implementierung einer Failover-Wiederherstellung – Sie können die Hochstufung des Lesereplikats als Datenwiederherstellungsschema verwenden, wenn die primäre DB-Instance fehlschlägt. Dieser Ansatz ergänzt die synchrone Replikation, die automatische Fehlererkennung und das Failover.

    Wenn Sie sich der Auswirkungen und Beschränkungen von asynchroner Replikation bewusst sind und Sie dennoch Lesereplikathochstufung für die Datenwiederherstellung verwenden möchten, können Sie das tun. Erstellen Sie dazu zuerst ein Lesereplikat und überwachen Sie anschließend die primäre DB-Instance auf Fehler. Im Fall eines Ausfalls machen Sie Folgendes:

    1. Stufen Sie das Lesereplikat hoch.

    2. Leiten Sie den Datenverkehr der Datenbank an die hochgestufte DB-Instance weiter.

    3. Erstellen Sie ein Ersatzlesereplikat mit der hochgestuften DB-Instance als Quelle.

  • Aktualisieren der Speicherkonfiguration – Wenn Ihre Quell-DB-Instance nicht die bevorzugte Speicherkonfiguration aufweist, können Sie ein Lesereplikat der Instance erstellen und die Konfiguration des Speicherdateisystems aktualisieren. Mit dieser Option wird das Dateisystem des Lesereplikats auf die bevorzugte Konfiguration migriert. Sie können dann das Lesereplikat zu einer eigenständigen Instance hochstufen.

    Sie können diese Option verwenden, um die Skalierungsbeschränkungen in Bezug auf Speicher und Dateigröße für ältere 32-Bit-Dateisysteme zu überwinden. Weitere Informationen finden Sie unter Upgrade des Speicherdateisystems für eine DB-Instance.

    Diese Option ist nur verfügbar, wenn Ihre Quell-DB-Instance nicht die neueste Speicherkonfiguration aufweist oder wenn Sie die DB-Instance-Klasse in derselben Anfrage ändern.

  • Sharding: Sharding verkörpert die Shared-Nothing-Architektur. Ihr wesentliches Prinzip besteht darin, eine große Datenbank in mehrere kleinere Datenbanken aufzuteilen. Normalerweise erfolgt die Aufteilung einer Datenbank, indem die Tabellen, die nicht in derselben Abfrage enthalten sind, auf verschiedene Hosts aufgeteilt werden. Ein weitere Methode besteht darin, die Tabelle auf mehrere Hosts zu duplizieren und dann einen Hash-Algorithmus zu verwenden, um festzustellen, welcher Host eine bestimmte Aktualisierung erhalten hat. Sie können Lesereplikate erstellen, die Ihren einzelnen Shards (kleineren Datenbanken) entsprechen, und sie hochstufen, wenn Sie beschließen, sie zu unabhängigen Shards zu konvertieren. Sie können anschließend je nach Ihren Erfordernissen den Schlüsselraum (wenn Sie Zeilen aufteilen) oder die Verteilung von Tabellen für jedes der Shards aufteilen.

  • Ausführen von DDL-Operations (ausschließlich MySQL und MariaDB): DDL-Operationen wie das Erstellen oder Wiederaufbauen von Indizes sind zeitaufwendig und sorgen für eine beträchtliche Leistungsminderung der DB-Instance. Sie können diese Operationen in einem MySQL- oder MariaDB-Lesereplikat ausführen, sobald das Lesereplikat mit seiner primären DB-Instance synchronisiert ist. Anschließend können Sie das Lesereplikat hochstufen und Ihre Anwendungen für die Nutzung der hochgestuften Instance weiterleiten.

Anmerkung

Wenn es sich bei Ihrem Lesereplikat um eine DB-Instance von RDS für Oracle handelt, können Sie eine Umstellung statt einer Hochstufung durchführen. Bei einer Umstellung wird die Quell-DB-Instance zum neuen Replikat und das Replikat zur neuen Quell-DB-Instance. Weitere Informationen finden Sie unter So führen Sie eine Oracle Data Guard-Umschaltung aus.

Merkmale eines hochgestuften Lesereplikats

Nachdem Sie das Lesereplikat hochgestuft haben, funktioniert es nicht mehr als Lesereplikat und wird zu einer eigenständigen DB-Instance. Die neue eigenständige DB-Instance hat die folgenden Merkmale:

  • Die eigenständige DB-Instance behält die Optionsgruppe und die Parametergruppe des Lesereplikats vor der Hochstufung bei.

  • Sie können Lesereplikate aus der eigenständigen DB-Instance erstellen und point-in-time Wiederherstellungsvorgänge durchführen.

  • Sie können die DB-Instance nicht als Replikationsziel verwenden, da sie kein Lesereplikat mehr ist.

Voraussetzungen für das Hochstufen eines Lesereplikats

Bevor Sie ein Lesereplikat hochstufen, gehen Sie wie folgt vor:

  • Überprüfen Sie Ihre Backup-Strategie:

    • Wir empfehlen Ihnen, Backups zu aktivieren und mindestens ein Backup abzuschließen. Die Sicherungsdauer ist eine Funktion der Anzahl von Änderungen an der Datenbank seit der letzten Backup.

    • Wenn Sie Backups für Ihre Lesereplikate aktiviert haben, konfigurieren Sie das automatische Sicherungsfenster so, dass die täglichen Backups das Hochstufen des Lesereplikats nicht beeinträchtigen.

    • Stellen Sie sicher, dass Ihr Lesereplikat nicht den backing-up Status hat. Sie können ein Lesereplikat nicht hochstufen, wenn es sich in diesem Zustand befindet.

  • Halten Sie alle Transaktionen an, die auf die primäre DB-Instance geschrieben werden, und warten Sie, bis RDS alle Updates auf das Lesereplikat angewendet hat.

    Datenbank-Updates werden im Lesereplikat durchgeführt, nachdem sie in der primären DB-Instance vorgenommen wurden. Die Replikationsverzögerung kann erheblich variieren. Verwenden Sie die Metrik Replica Lag, um zu bestimmen, wann alle Aktualisierungen am Lesereplikat vorgenommen wurden.

  • (Nur MySQL und MariaDB) Um Änderungen an einem MySQL- oder MariaDB-Lesereplikat vorzunehmen, bevor Sie es hochstufen, legen Sie den read_only Parameter 0 in der DB-Parametergruppe für das Lesereplikat auf fest. Sie können anschließend alle nötigen DDL-Operationen, wie das Erstellen von Indizes, im Lesereplikat ausführen. Im Lesereplikat vorgenommene Aktionen haben keine Auswirkung auf die Leistungen der primären DB-Instance.

Hochstufen eines Lesereplikats: grundlegende Schritte

Die folgenden Schritte zeigen den allgemeinen Vorgang für das Hochstufen eines Lesereplikats zu einer DB-Instance:

  1. Stufen Sie das Lesereplikat mit der Option Hochstufen in der Amazon-RDS-Konsole, dem AWS CLI Befehl promote-read-replicaoder der PromoteReadReplica Amazon-RDS-API-Operation hoch.

    Anmerkung

    Das Hochstufen kann einige Minuten in Anspruch nehmen. Wenn Sie ein Lesereplikat hochstufen, stoppt RDS die Replikation und startet das Lesereplikat neu. Sobald der Neustart abgeschlossen ist, steht das Lesereplikat als neue DB-Instance zur Verfügung.

  2. (Optional) Ändern Sie die neue DB-Instance in eine Multi-AZ-Bereitstellung. Weitere Informationen erhalten Sie unter Ändern einer Amazon RDS-DB-Instance und Konfiguration und Verwaltung einer Multi-AZ-Bereitstellung.

Hochstufen einer Read Replica zu einer eigenständigen DB-Instance
  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie in der Amazon RDS-Konsole Databases (Datenbanken) aus.

    Der Bereich Databases (Datenbanken) wird angezeigt. Jedes Lesereplikat zeigt Replica (Replikat) in der Spalte Role (Rolle) an.

  3. Wählen Sie das Lesereplikat aus, das Sie hochstufen möchten.

  4. Wählen Sie für Actions (Aktionen) Promote (Hochstufen) aus.

  5. Geben Sie auf der Seite Read Replica hochstufen den Aufbewahrungszeitraum und das Sicherungsfenster für die neu hochgestufte DB-Instance an.

  6. Wenn die Optionen nach Ihrem Bedarf eingestellt sind, wählen Sie Weiter aus.

  7. Wählen Sie auf der Bestätigungsseite Read Replica hochstufen aus.

Verwenden Sie den AWS CLI promote-read-replica Befehl , um ein Lesereplikat zu einer eigenständigen DB-Instance hochzustufen.

Beispiel

Für Linux, macOSoder Unix:

aws rds promote-read-replica \ --db-instance-identifier myreadreplica

Windows:

aws rds promote-read-replica ^ --db-instance-identifier myreadreplica

Um ein Lesereplikat auf eine eigenständige DB-Instance hochzustufen, rufen Sie die Amazon-RDS-API-Operation PromoteReadReplica mit dem erforderlichen Parametern DBInstanceIdentifier auf.

Überwachen der Lesereplikation

Es gibt mehrere Arten, den Status eines Lesereplikats zu überwachen. Die Amazon-RDS-Konsole zeigt den Status eines Lesereplikats in den Lesereplikat-Details im Abschnitt Replication (Replikation) der Registerkarte Connectivity & security (Konnektivität & Sicherheit) an. Um die Details für ein Lesereplikat anzuzeigen, klicken Sie in der Liste der DB-Instances in der Amazon-RDS-Konsole auf den Namen des Lesereplikats.


            Lesereplikatsstatus

Sie können den Status eines Lesereplikats auch mit dem AWS CLI describe-db-instances -Befehl oder der Amazon-RDS-API-DescribeDBInstancesOperation anzeigen.

Der Status eines Lesereplikats kann einer der folgenden sein:

  • replicating (replizierend)– Das Lesereplikat wird erfolgreich repliziert.

  • Replikation beeinträchtigt (nur SQL Server und PostgreSQL) – Replikate erhalten Daten von der primären Instance, doch mindestens eine Datenbank erhält möglicherweise keine Aktualisierungen. Dies kann beispielsweise auftreten, wenn ein Replikat gerade neu erstellte Datenbanken einrichtet. Dies kann auch passieren, wenn nicht unterstützte DDL- oder große Objektänderungen in der blauen Umgebung einer Blau/Grün-Bereitstellung vorgenommen werden.

    Der Status wechselt nicht von replication degraded zu error, es sei denn, während des beeinträchtigten Zustands tritt ein Fehler auf.

  • error (Fehler) – Während des Replikationsvorgangs ist ein Fehler aufgetreten. Überprüfen Sie das Feld Replikationsfehler in der Amazon RDS-Konsole oder im Ereignisprotokoll, um den genauen Fehler zu bestimmen. Weitere Informationen über Fehlerbehebung eines Replikationsfehlers finden Sie unter Fehlerbehebung für ein Problem mit einer MySQL Read Replica.

  • terminated (beendet) (nur MariaDB, MySQL oder PostgreSQL) – Die Replikation ist beendet. Dies tritt auf, wenn die Replikation für mehr als 30 aufeinanderfolgende Tage entweder manuell oder aufgrund eines Replikationsfehlers angehalten wurde. In diesem Fall beendet Amazon RDS die Replikation zwischen der primären DB-Instance und allen Lesereplikaten. Amazon RDS tut dies, um erhöhten Speicheranforderungen in der Quell-DB-Instance vorzubeugen und lange Failover-Zeiten zu vermeiden.

    Unterbrochene Replikation kann sich auf den Speicher auswirken, da die Protokolle aufgrund des hohen Volumens an Fehlermeldungen, die in das Protokoll geschrieben werden, an Größe und Anzahl zunehmen können. Unterbrochene Replikation kann sich auch auf die Ausfallwiederherstellung auswirken, bedingt durch den Zeitaufwand von Amazon RDS für das Warten und Verarbeiten einer großen Anzahl an Protokollen während der Wiederherstellung.

  • terminated (beendet) (nur Oracle) – Die Replikation wurde beendet. Dies tritt auf, wenn die Replikation länger als 8 Stunden angehalten wurde, weil auf dem Lesereplikat nicht mehr genügend Speicherplatz vorhanden ist. In diesem Fall beendet Amazon RDS die Replikation zwischen der primären DB-Instance und den betroffenen Lesereplikaten. Dieser Status ist ein Terminalstatus und das Lesereplikat muss neu erstellt werden.

  • stopped (angehalten) (nur für MySQL oder MariaDB) – Die Replikation wurde aufgrund einer benutzerseitigen Anfrage angehalten.

  • replication stop point set (Stopppunkt für das Beenden der Replikation festgelegt) (nur MySQL) – Ein vom Benutzer initiierter Stopppunkt wurde mit der gespeicherten Prozedur mysql.rds_start_replication_until festgelegt und die Replikation ist im Gange.

  • replication stop point reached (Stopppunkt für das Beenden der Replikation erreicht) (nur MySQL) – Ein vom Benutzer initiierter Stopppunkt wurde mit der gespeicherten Prozedur mysql.rds_start_replication_until festgelegt und die Replikation wurde gestoppt, da der Stopppunkt erreicht wurde.

Sie können sehen, wo eine DB-Instance repliziert wird, und wenn ja, ihren Replizierungsstatus überprüfen. Auf der Seite „ Datenbanken “ in der RDS-Konsole wird „ Primär “ in der Spalte „ Rolle “ angezeigt. Wählen Sie seinen DB-Instance-Namen. Auf der Detailseite auf der Registerkarte Connectivity & Security befindet sich der Replikationsstatus unter Replikation.

Überwachen einer Replikationsverzögerung

Sie können die Replikationsverzögerung in Amazon überwachen, CloudWatch indem Sie die Amazon-RDS-ReplicaLagMetrik anzeigen.

Für MariaDB und MySQL gibt dieReplicaLag Metrik den Wert desSeconds_Behind_Master Feldes desSHOW REPLICA STATUS Befehls an. Häufige Ursachen für Replikationsverzögerungen in MySQL und MariaDB sind die Folgenden:

  • Ein Netzwerkausfall.

  • Schreibvorgänge auf Tabellen mit Indizes auf einem Lesereplikat. Wenn der Parameter read_only im Lesereplikat nicht auf 0 gesetzt ist, kann es die Replikation unterbrechen.

  • Die Verwendung einer nicht-transaktionalen Speicher-Engine wie MyISAM: Replikation wird nur für die InnoDB-Speicher-Engine in MySQL und die XtraDB-Speicher-Engine in MariaDB unterstützt.

Anmerkung

In früheren Versionen von MariaDB und MySQL werden SHOW SLAVE STATUS anstelle von SHOW REPLICA STATUS verwendet. Wenn Sie eine MariaDB-Version vor 10.5 oder eine MySQL-Version vor 8.0.23 verwenden, verwenden Sie SHOW SLAVE STATUS.

Wenn die Metrik ReplicaLag den Wert 0 erreicht, hat das Replikat den Stand der primären DB-Instance erreicht. Wenn die ReplicaLag-Metrik -1 zurückgibt, ist die Replikation aktuell nicht aktiv. ReplicaLag = -1 ist gleich Seconds_Behind_Master = NULL.

Für Oracle ist die Metrik ReplicaLag die Summe des Apply Lag-Wertes und der Differenz zwischen der aktuellen Zeit und dem DATUM_TIME-Wert der zeitlichen Verzögerung. Der DATUM_TIME-Wert ist der Zeitpunkt, an dem das Lesereplikat zuletzt Daten von seiner Quell-DB-Instance erhalten hat. Weitere Informationen finden Sie unter V$DATAGUARD_STATS in der Oracle-Dokumentation.

Für SQL Server ist die ReplicaLag-Metrik die maximale Verzögerung von Datenbanken, die zurückgefallen sind, in Sekunden. Wenn Sie beispielsweise zwei Datenbanken haben, die eine Verzögerung von 5 bzw. 10 Sekunden aufweisen, dann beträgt ReplicaLag 10 Sekunden. Die ReplicaLag-Metrik gibt den Wert der folgenden Abfrage zurück.

SELECT MAX(secondary_lag_seconds) max_lag FROM sys.dm_hadr_database_replica_states;

Weitere Informationen finden Sie unter secondary_lag_seconds in der Microsoft-Dokumentation.

ReplicaLag gibt -1 zurück, wenn RDS die Verzögerung nicht ermitteln kann, z. B. während der Replikateinrichtung oder wenn sich das Lesereplikat im Status error befindet.

Anmerkung

Neue Datenbanken werden erst dann in die Verzögerungsberechnung einbezogen, wenn auf dem Lesereplikat auf sie zugegriffen werden kann.

Für PostgreSQL gibt die ReplicaLag-Metrik den Wert der folgenden Abfrage zurück.

SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS reader_lag

Die PostgreSQL-Versionen 9.5.2 und höher verwenden physische Replikations-Slots, um die Write-Ahead-Log-Aufbewahrung (WAL) in der Quell-Instance zu verwalten. Für jede regionsübergreifende Lesereplikat-Instance erstellt Amazon RDS einen physischen Replikations-Slot und weist diesen der Instance zu. Zwei Amazon- CloudWatch Metriken, Oldest Replication Slot Lag und Transaction Logs Disk Usage, zeigen an, wie weit das Replikat mit der größten Verzögerung in Bezug auf die empfangenen WAL-Daten zurückliegt und wie viel Speicher für WAL-Daten verwendet wird. Der Wert Transaction Logs Disk Usage kann erheblich ansteigen, wenn ein regionsübergreifendes Lesereplikat signifikant verzögert ist.

Weitere Informationen zur Überwachung einer DB-Instance mit CloudWatchfinden Sie unter Überwachen von Amazon RDS-Metriken mit Amazon CloudWatch.

Erstellen eines Lesereplikats in einer anderen AWS-Region

Mit Amazon RDS können Sie ein Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance erstellen.


                Konfiguration einer regionsübergreifenden Read Replica

Sie erstellen ein Lesereplikat in einer anderen , AWS-Region um Folgendes zu tun:

  • Verbessern Ihrer Notfallwiederherstellungsfähigkeiten.

  • Skalieren Sie Lesevorgänge in eine , die AWS-Region näher an Ihren Benutzern liegt.

  • Vereinfachen Sie die Migration von einem Rechenzentrum in einer AWS-Region zu einem Rechenzentrum in einer anderen AWS-Region.

Das Erstellen eines Lesereplikats in einer anderen AWS-Region als der Quell-Instance ähnelt dem Erstellen eines Replikats in derselben AWS-Region. Sie können die verwenden AWS Management Console, den create-db-instance-read-replica Befehl ausführen oder die CreateDBInstanceReadReplica-API-Operation aufrufen.

Anmerkung

Um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen, muss die Quell-DB-Instance verschlüsselt sein.

Verfügbarkeit von Regionen und Versionen

Verfügbarkeit von Funktionen und Support variiert zwischen bestimmten Versionen der einzelnen Datenbank-Engines und über alle AWS-Regionen hinweg. Weitere Informationen zur Version und Region mit regionsübergreifender Replikation finden Sie unter Regionsübergreifende Lesereplikate.

Erstellen einer regionsübergreifenden Read Replica

Die folgenden Verfahren zeigen das Erstellen eines Lesereplikats aus einer Quell-DB-Instance von MariaDB, Microsoft SQL Server, MySQL, Oracle oder PostgreSQL in einer anderen AWS-Region.

Sie können AWS-Regionen mit der ein Lesereplikat über hinweg erstellen AWS Management Console.

So erstellen Sie ein Lesereplikat über hinweg AWS-Regionen mit der Konsole
  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Datenbanken aus.

  3. Wählen Sie die DB-Instance von MariaDB, Microsoft SQL Server, MySQL, Oracle oder PostgreSQL aus, die Sie als Quelle für ein Lesereplikat verwenden möchten.

  4. Wählen Sie unter Aktionen Create read replica (Read Replica erstellen) aus.

  5. Geben Sie unter DB instance identifier (DB-Instance-Kennung) einen Namen für das Lesereplikat ein.

  6. Wählen Sie die Zielregion aus.

  7. Wählen Sie die Instance-Spezifikationen aus, die Sie verwenden möchten. Wir empfehlen Ihnen, dieselbe oder eine größere DB-Instance-Klasse und denselben Speichertyp für das Lesereplikat zu verwenden.

  8. So erstellen Sie ein verschlüsseltes Lesereplikat in einer anderen AWS-Region:

    1. Wählen Sie Enable encryption (Verschlüsselung aktivieren) aus.

    2. AWS KMS keyWählen Sie für die AWS KMS key Kennung des KMS-Schlüssels in der Ziel- aus AWS-Region.

    Anmerkung

    Die Quell-DB-Instance muss verschlüsselt sein, um ein verschlüsseltes Lesereplikat zu erstellen. Weitere Informationen über das Verschlüsseln der Quell-DB-Instance finden Sie unter Verschlüsseln von Amazon RDS-Ressourcen.

  9. Wählen Sie andere Optionen wie Autoscaling von Speicher.

  10. Wählen Sie Read Replica erstellen aus.

Sie können den Befehl AWS-Region verwenden, um ein Lesereplikat aus einer Quell-DB-Instance von MySQL, Microsoft SQL Server, MariaDB, Oracle oder PostgreSQL in einer anderen create-db-instance-read-replica zu erstellen. In diesem Fall verwenden Sie create-db-instance-read-replica aus der , AWS-Region in der Sie das Lesereplikat (Zielregion) haben möchten, und geben den Amazon-Ressourcennamen (ARN) für die Quell-DB-Instance an. Ein ARN bezeichnet eindeutig eine in Amazon Web Services erstellte Quelle.

Wenn sich beispielsweise Ihre Quell-DB-Instance in der Region US East (N. Virginia) befindet, sieht der ARN ähnlich wie in diesem Beispiel aus:

arn:aws:rds:us-east-1:123456789012:db:mydbinstance

Weitere Informationen zu ARNs finden Sie unter Arbeiten mit Amazon-Ressourcennamen (ARN) in Amazon RDS.

Um ein Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen, können Sie den AWS CLI create-db-instance-read-replica Befehl aus der Ziel- verwenden AWS-Region. Die folgenden Parameter sind für die Erstellung einer Read Replica in einer anderen AWS-Region erforderlich:

  • --region – Das Ziel AWS-Region , an dem das Lesereplikat erstellt wird.

  • --source-db-instance-identifier – Die DB-Instance-Kennung für die Quell-DB-Instance. Dieser Bezeichner muss im ARN-Format der Quell- AWS-Region angegeben werden.

  • --db-instance-identifier – Die Kennung für die Read Replica in der Ziel- AWS-Region.

Beispiel eine regionsübergreifende Read Replica

Der folgende Code erstellt ein Read Replica in der USA West (Oregon)-Region von einer Quell-DB-Instance in der US East (N. Virginia)-Region.

Für Linux, macOSoder Unix:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --region us-west-2 \ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance

Windows:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --region us-west-2 ^ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance

Die folgenden Parameter sind auch für die Erstellung einer verschlüsselten Read Replica in einer anderen AWS-Region erforderlich:

  • --kms-key-id – Die AWS KMS key Kennung des KMS-Schlüssels, der zum Verschlüsseln des Lesereplikats in der Ziel- verwendet werden soll AWS-Region.

Beispiel einer verschlüsselten regionsübergreifenden Read Replica

Der folgende Code erstellt ein verschlüsseltes Read Replica in der USA West (Oregon)-Region von einer Quell-DB-Instance in der US East (N. Virginia)-Region.

Für Linux, macOSoder Unix:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --region us-west-2 \ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance \ --kms-key-id my-us-west-2-key

Windows:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --region us-west-2 ^ --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:mydbinstance ^ --kms-key-id my-us-west-2-key

Die --source-region Option ist erforderlich, wenn Sie ein verschlüsseltes Lesereplikat zwischen den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (USA-West) erstellen. Geben Sie für --source-region die AWS-Region der Quell-DB-Instance an.

Wenn --source-region nicht festgelegt ist, geben Sie einen --pre-signed-url-Wert an. Eine vorsignierte URL ist eine URL, die eine mit der Signaturversion 4 signierte Anforderung für den Befehl create-db-instance-read-replica enthält, die in der Quell- AWS-Region aufgerufen wird. Weitere Informationen zur pre-signed-url Option finden Sie unter create-db-instance-read-replica in der AWS CLI -Befehlsreferenz.

Um ein Lesereplikat aus einer MySQL-, Microsoft SQL Server-, MariaDB-, Oracle- oder PostgreSQL-Quell-DB-Instance in einer anderen zu erstellen AWS-Region, können Sie die Amazon RDS-API-Operation CreateDBInstanceReadReplica aufrufen. In diesem Fall rufen Sie CreateDBInstanceReadReplica von der auf, AWS-Region in der Sie das Lesereplikat (Zielregion) haben möchten, und geben den Amazon-Ressourcennamen (ARN) für die Quell-DB-Instance an. Ein ARN bezeichnet eindeutig eine in Amazon Web Services erstellte Quelle.

Um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen, können Sie die Amazon RDS-API-CreateDBInstanceReadReplicaOperation aus der Ziel- verwenden AWS-Region. Um ein verschlüsseltes Lesereplikat in einem anderen zu erstellen AWS-Region, müssen Sie einen Wert für angebenPreSignedURL. PreSignedURL sollte eine Anforderung für die -CreateDBInstanceReadReplicaOperation zum Aufrufen von in der Quelle enthalten AWS-Region , in der das Lesereplikat erstellt wird. Weitere Informationen über PreSignedUrl finden Sie unter CreateDBInstanceReadReplica.

Wenn sich beispielsweise Ihre Quell-DB-Instance in der Region US East (N. Virginia) befindet, sieht der ARN ähnlich wie der folgende aus.

arn:aws:rds:us-east-1:123456789012:db:mydbinstance

Weitere Informationen zu ARNs finden Sie unter Arbeiten mit Amazon-Ressourcennamen (ARN) in Amazon RDS.

Beispiel
https://us-west-2.rds.amazonaws.com/ ?Action=CreateDBInstanceReadReplica &KmsKeyId=my-us-east-1-key &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBInstanceReadReplica %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%123456789012%25253Adb%25253Amydbinstance %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4%2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Ainstance%25253Amydbinstance %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &DBInstanceIdentifier=myreadreplica &SourceDBInstanceIdentifier=&region-arn;rds:us-east-1:123456789012:db:mydbinstance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<&AWS; Access Key ID> &Signature=<Signature>

Wie Amazon RDS regionsübergreifende Replikationen durchführt

Amazon RDS verwendet den folgenden Vorgang, um ein regionsübergreifendes Lesereplikat zu erstellen. Abhängig von den AWS-Regionen beteiligten und der Datenmenge in den Datenbanken kann es Stunden dauern, bis dieser Vorgang abgeschlossen ist. Sie können diese Informationen verwenden, um zu bestimmen, wie weit fortgeschritten der Vorgang ist, wenn Sie ein regionsübergreifendes Lesereplikat erstellen:

  1. Amazon RDS beginnt mit der Konfiguration der Quell-DB-Instance als Replikationsquelle und setzt den Status auf Wird geändert ….

  2. Amazon RDS beginnt mit der Einrichtung des angegebenen Lesereplikats im Ziel AWS-Region und legt den Status auf „Erstellen“ fest.

  3. Amazon RDS erstellt einen automatisierten DB-Snapshot der Quell-DB-Instance in der Quell- AWS-Region. Das Format des DB-Snapshot-Namens ist rds:<InstanceID>-<timestamp>, wobei <InstanceID> die Kennung der Quell-Instance ist und <timestamp> Startdatum und -zeit der Kopie sind. Beispielsweise wurde rds:mysourceinstance-2013-11-14-09-24 aus der Instance mysourceinstance am 2013-11-14-09-24 erstellt. Während der Erstellung eines automatischen DB-Snapshots bleibt der Status der Quell-DB-Instance modifying (wird geändert), der Status des Lesereplikats creating (wird erstellt) und der Status des DB-Snapshots creating (wird erstellt). Die Fortschrittsspalte auf der DB-Snapshot-Seite in der Konsole meldet, wie weit die Erstellung des DB-Snapshots fortgeschritten ist. Wenn der DB-Snapshot fertiggestellt ist, wird sowohl der Status des DB-Snapshots als auch der Quell-DB-Instance auf Verfügbar gesetzt.

  4. Amazon RDS beginnt mit einer regionsübergreifenden Snapshot-Kopie für die erste Datenübertragung. Die Snapshot-Kopie wird als automatisierter Snapshot im Ziel AWS-Region mit dem Status zum Erstellen von aufgeführt. Sie hat denselben Namen wie der Quell-DB-Snapshot. Die Fortschrittspalte in der DB-Snapshot-Anzeige in der Konsole gibt an, wie weit die Kopie fortgeschritten ist. Wenn die Kopie fertiggestellt ist, wird der Status der DB-Snapshot-Kopie auf Verfügbar gesetzt.

  5. Amazon RDS verwendet dann den kopierten DB-Snapshot für den ersten Datenladevorgang in das Lesereplikat. Während dieser Phase wird das Lesereplikat mit dem Status creating (wird erstellt) in der Liste von DB-Instances im Ziel aufgelistet. Wenn der Ladevorgang abgeschlossen ist, wird der Status des Lesereplikats auf available (verfügbar) gesetzt und die DB-Snapshot-Kopie wird gelöscht.

  6. Wenn das Lesereplikat den Status "available (verfügbar)" erreicht, startet Amazon RDS mit der Replikation der Änderungen, die in der Quell-Instance seit dem Start der Operation zum Erstellen des Lesereplikats vorgenommen wurden. Während dieser Phase ist die Verzögerungszeit der Replikation für das Lesereplikat größer als 0.

    Weitere Informationen zur zeitlichen Verzögerung bei der Replikation finden Sie unter Überwachen der Lesereplikation.

Überlegungen zur regionsübergreifenden Replikation

Alle Überlegungen zum Durchführen einer Replikation innerhalb eines AWS-Region gelten für die regionsübergreifende Replikation. Die folgenden zusätzlichen Überlegungen gelten, wenn zwischen AWS-Regionen repliziert wird:

  • Eine Quell-DB-Instance kann über regionsübergreifende Read Replicas in mehreren AWS-Regionen verfügen.

  • Sie können zwischen den Regionen GovCloud (USA-Ost) und GovCloud (USA-West) replizieren, jedoch nicht in oder aus GovCloud (USA).

  • Für DB-Instances von Microsoft SQL Server, Oracle und PostgreSQL können Sie nur ein regionsübergreifendes Amazon-RDS-Lesereplikat aus einer Amazon-RDS-Quell-DB-Instance erstellen, die kein Lesereplikat einer anderen Amazon-RDS-DB-Instance ist. Diese Einschränkung gilt nicht für MariaDB- und MySQL-DB-Instances.

  • Sie können erwarten, dass für jedes Lesereplikat, das sich in einer anderen AWS-Region als die Quell-Instance befindet, eine höhere Verzögerungszeit zu erwarten ist. Die zeitliche Verzögerung lässt sich auf längere Netzwerkkanäle zwischen regionalen Rechenzentren zurückführen.

  • Für regionsübergreifende Lesereplikate muss jeder der Befehle zum Erstellen eines Lesereplikats, der den Parameter --db-subnet-group-name angibt, eine DB-Subnetzgruppe aus derselben VPC angeben.

  • Aufgrund der Beschränkung für die Zahl der Einträge in der Zugriffssteuerungsliste (ACL) für die Quell-VPC können wir nicht mehr als fünf regionsübergreifende Lesereplikat-Instances garantieren.

  • In den meisten Fällen verwendet das Lesereplikat die Standard-DB-Parametergruppe und DB-Optionsgruppe für die angegebene DB-Engine.

    Für die MySQL- und Oracle-DB-Engines können Sie eine benutzerdefinierte Parametergruppe für das Lesereplikat in der --db-parameter-group-name Option des AWS CLI Befehls angebencreate-db-instance-read-replica. Sie können keine benutzerdefinierte Parametergruppe angeben, wenn Sie die AWS Management Console verwenden.

  • Das Lesereplikat verwendet die Standardsicherheitsgruppe.

  • Wenn bei DB-Instances von MariaDB, Microsoft SQL Server, MySQL und Oracle die Quell-DB-Instance für ein nicht-regionsübergreifendes Lesereplikat gelöscht wird, wird das Lesereplikat hochgestuft.

  • Für PostgreSQL-DB-Instances wird der Replikationsstatus des Lesereplikats auf terminated gesetzt, wenn die Quell-DB-Instance für ein regionsübergreifendes Lesereplikat gelöscht wird. Das Lesereplikat wird nicht hochgestuft.

    Sie müssen das Lesereplikat manuell hochstufen oder löschen.

Anfordern einer regionsübergreifenden Read Replica

Um mit der Quellregion zu kommunizieren und die Erstellung einer regionsübergreifenden Read Replica anzufordern, muss der Anforderer (IAM-Rolle oder IAM-Benutzer) Zugriff auf die Quell-DB-Instance und die Quellregion haben.

Bestimmte Bedingungen in der IAM-Richtlinie des Anforderers können dazu führen, dass die Anfrage fehlschlägt. Die folgenden Beispiele gehen davon aus, dass sich die Quell-DB-Instance in USA Ost (Ohio) befindet, und die Read Replica in US East (N. Virginia) erstellt wird. Diese Beispiele zeigen die Bedingungen in der IAM-Richtlinie des Anforderers, die dazu führen, dass die Anfrage fehlschlägt:

  • Die Richtlinie des Anforderers hat eine Bedingung für aws:RequestedRegion.

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-1" } }

    Die Anfrage schlägt fehl, weil die Richtlinie den Zugriff auf die Quellregion nicht zulässt. Für eine erfolgreiche Anfrage geben Sie sowohl die Quell- als auch die Zielregion an.

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": [ "us-east-1", "us-east-2" ] } }
  • Die Richtlinie des Anforderers erlaubt keinen Zugriff auf die Quell-DB-Instance.

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "arn:aws:rds:us-east-1:123456789012:db:myreadreplica" ...

    Geben Sie für eine erfolgreiche Anfrage sowohl die Quell-Instance als auch das Replikat an.

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": [ "arn:aws:rds:us-east-1:123456789012:db:myreadreplica", "arn:aws:rds:us-east-2:123456789012:db:mydbinstance" ] ...
  • Die Richtlinie des Anforderers lehnt aws:ViaAWSService ab.

    ... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "Bool": {"aws:ViaAWSService": "false"} }

    Die Kommunikation mit der Quellregion erfolgt über RDS im Namen des Anforderers. Verweigern Sie bei einer erfolgreichen Anforderung keine Aufrufe von - AWS Services.

  • Die Richtlinie des Anforderers hat eine Bedingung für aws:SourceVpc oder aws:SourceVpce.

    Diese Anforderungen können fehlschlagen, da RDS den Aufruf an die entfernte Region nicht vom angegebenen VPC- oder VPC-Endpunkt ausführt.

Wenn Sie eine der vorherigen Bedingungen verwenden müssen, die dazu führen würde, dass eine Anfrage fehlschlägt, können Sie eine zweite Anweisung mit aws:CalledVia in Ihrer Richtlinie aufnehmen, um die Anfrage erfolgreich zu machen. Zum Beispiel können Sie aws:CalledVia mit aws:SourceVpce wie hier gezeigt verwenden:

... "Effect": "Allow", "Action": "rds:CreateDBInstanceReadReplica", "Resource": "*", "Condition": { "Condition" : { "ForAnyValue:StringEquals" : { "aws:SourceVpce": "vpce-1a2b3c4d" } } }, { "Effect": "Allow", "Action": [ "rds:CreateDBInstanceReadReplica" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:CalledVia": [ "rds.amazonaws.com" ] } } }

Weitere Informationen finden Sie unter Richtlinien und Berechtigungen in IAM im IAM-Benutzerhandbuch.

Autorisieren des Read Replica

Nachdem eine regionsübergreifende DB-Anforderung zum Erstellung der Read Replica success zurückgibt, startet RDS die Replica-Erstellung im Hintergrund. Es wird eine Berechtigung für RDS für den Zugriff auf die Quell-DB-Instance erstellt. Diese Autorisierung verknüpft die Quell-DB-Instance mit der Read Replica und ermöglicht es RDS, nur in die angegebene Read Replica zu kopieren.

Die Autorisierung wird von RDS unter Verwendung der rds:CrossRegionCommunication-Berechtigung in der serviceverknüpfte IAM-Rolle verifiziert. Wenn das Replikat autorisiert ist, kommuniziert RDS mit der Quellregion und schließt die Erstellung der Read Replica ab.

RDS hat keinen Zugriff auf DB-Instances, die zuvor nicht von einer CreateDBInstanceReadReplica-Anfrage authorisiert wurden. Die Autorisierung wird widerrufen, wenn die Erstellung der Read Replica abgeschlossen ist.

RDS verwendet die serviceverknüpfte Rolle, um die Autorisierung in der Quellregion zu überprüfen. Wenn Sie die serviceverknüpfende Rolle während des Replizierungserstellungsprozesses löschen, schlägt die Erstellung fehl.

Weitere Informationen finden Sie unter Verwenden von serviceverknüpften Rollen im -IAM-Benutzerhandbuch.

Verwenden von AWS Security Token Service Anmeldeinformationen

Sitzungstoken vom globalen AWS Security Token Service (AWS STS)-Endpunkt sind nur in gültig AWS-Regionen , die standardmäßig aktiviert sind (kommerzielle Regionen). Wenn Sie Anmeldeinformationen aus der APIassumeRole-Operation in verwenden AWS STS, verwenden Sie den regionalen Endpunkt, wenn es sich bei der Quellregion um eine Opt-in-Region handelt. Andernfalls schlägt die Anforderung fehl. Dies geschieht, weil Ihre Anmeldeinformationen in beiden Regionen gültig sein müssen, was für Opt-in-Regionen nur gilt, wenn der regionale AWS STS Endpunkt verwendet wird.

Um den globalen Endpunkt zu verwenden, stellen Sie sicher, dass er für beide Regionen in den Vorgängen aktiviert ist. Setzen Sie den globalen Endpunkt Valid in all AWS-Regionen in den AWS STS Kontoeinstellungen auf .

Die gleiche Regel gilt für Anmeldeinformationen im vorsignierten URL-Parameter.

Weitere Informationen finden Sie unter Verwalten von AWS STS in einer AWS-Region im IAM-Benutzerhandbuch.

Kosten für regionsübergreifende Replikationen

Für Daten, die für regionsübergreifende Replikation übermittelt werden, fallen Amazon RDS-Datenübertragungskosten an. Bei diesen regionsübergreifenden Replikationsaktionen fallen Gebühren für die übermittelten Daten aus der Quell- AWS-Region an:

  • Wenn Sie ein Lesereplikat erstellen, erstelllt Amazon RDS einen Snapshot der Quell-Instance und leitet den Snapshot an die AWS-Region der Read Replica weiter.

  • Für jede in den Quelldatenbanken durchgeführte Datenänderung überträgt Amazon RDS Daten von der Quelle AWS-Region an das Lesereplikat AWS-Region.

Weitere Informationen zu den Kosten von Datenübertragungen finden Sie unter Amazon RDS – Preise.

Für MySQL- und MariaDB-Instances können Sie Ihre Datenübertragungskosten senken, indem Sie die Anzahl der erstellten regionsübergreifenden Lesereplikate reduzieren. Angenommen, Sie haben eine Quell-DB-Instance in einer AWS-Region und möchten drei Lesereplikate in einer anderen haben AWS-Region. In diesem Fall können Sie nur eines der Lesereplikate aus der Quell-DB-Instance erstellen. Die anderen beiden Lesereplikate erstellen Sie aus dem ersten Lesereplikat anstelle der Quell-DB-Instance.

Wenn Sie beispielsweise source-instance-1 in einer haben AWS-Region, können Sie Folgendes tun:

  • Erstellen Sie read-replica-1 in der neuen und AWS-Regiongeben Sie source-instance-1 als Quelle an.

  • Erstellen Sie read-replica-2 aus read-replica-1.

  • Erstellen Sie read-replica-3 aus read-replica-1.

In diesem Beispiel werden Ihnen nur die übermittelten Daten von source-instance-1 nach read-replica-1 in Rechnung gestellt. Ihnen werden keine Datenübertragungen von read-replica-1 zu den anderen beiden Replikaten in Rechnung gestellt, weil sie sich in derselben AWS-Region befinden. Wenn Sie alle drei Replicas direkt aus source-instance-1 erstellen, werden Ihnen die Datenübermittlungen von allen drei Replicas in Rechnung gestellt.