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:

• Arbeiten mit MariaDB Read Replicas

• Arbeiten mit Read Replicas für Microsoft SQL Server in Amazon RDS

• Arbeiten mit MySQL-Lesereplikaten

• Arbeiten mit Lese-Replikaten für Amazon RDS für Oracle

• Arbeiten mit Read Replicas in Amazon RDS for PostgreSQL

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. Clients haben Lese-/Schreibzugriff auf die primäre DB-Instance und Nur-Lese-Zugriff auf das Replikat.

Ü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.

Themen

• Anwendungsfälle für Lesereplikate
• Funktionsweise von Lesereplikaten
• Lesereplikate in einer Multi-AZ-Bereitstellung
• Regionsübergreifende Lesereplikate
• Unterschiede zwischen Lesereplikaten für DB-Engines
• Lesereplikat-Speichertypen
• Einschränkungen beim Erstellen eines Replikats aus einem Replikat
• Überlegungen zum Löschen von Replikaten

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.

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 eine Lesereplik in einer anderen als ihrer primären DB-Instance. AWS-Region 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 zur Aktivierung des sicheren Kanals erforderlich sind, z. B. das Hinzufügen von Sicherheitsgruppeneinträgen. Weitere Informationen zu regionsübergreifenden Read Replicas finden Sie unter Erstellen Sie eine Read Replica in einer anderen AWS-Region.

Die Informationen in diesem Kapitel beziehen sich auf die Erstellung von Amazon RDS-Read Replicas 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 Read Replicas in derselben zu löschen AWS-Region, wird jede Read Replica zu einer eigenständigen DB-Instance heraufgestuft. 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 mithilfe der, oder RDS-API eine Read Replica aus einer vorhandenen DB-Instance erstellen. AWS Management Console AWS CLI 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. Bei der Quell-DB-Instance kommt es zu einer sehr kurzen I/O-Unterbrechung, wenn der DB-Snapshot-Vorgang beginnt. Die I/O-Unterbrechung dauert in der Regel etwa eine Sekunde. 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 eines empfehlen wir dringend AWS-Region, alle Read Replicas in derselben Virtual Private Cloud (VPC) auf Basis von 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, AWS-Konto mithilfe der Konsole oder eine Read Replica in einer anderen zu erstellen. AWS CLI

Konsole

Zum Erstellen einer Read Replica aus einer Quell-DB-Instance

1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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. Wählen Sie für AWS KMS keydie AWS KMS key Kennung des KMS-Schlüssels.

    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.

AWS CLI

Um eine Read Replica 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

LinuxmacOSUnixFür, oder:

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

RDS-API

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 eine Read Replica hochstufen, startet RDS die DB-Instance neu, bevor sie verfügbar gemacht wird. Das Hochstufen kann einige Minuten oder mehr in Anspruch nehmen, abhängig von der Größe des Lesereplikats.

Anwendungsfälle für das Heraufstufen einer Read Replica

Möglicherweise möchten Sie eine Read Replica aus einem der folgenden Gründe zu einer eigenständigen DB-Instance heraufstufen:

• 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 Ihrer Read Replica um eine RDS für Oracle-DB-Instance handelt, können Sie statt einer Heraufstufung einen Switchover durchführen. Bei einem Switchover 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.

Eigenschaften einer hochgestuften Read Replica

Nachdem Sie die Read Replica heraufgestuft haben, funktioniert sie nicht mehr als Read Replica und wird zu einer eigenständigen DB-Instance. Die neue eigenständige DB-Instance weist die folgenden Eigenschaften auf:

• Die eigenständige DB-Instance behält die Optionsgruppe und die Parametergruppe der Read Replica vor der Promotion bei.

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

• Sie können die DB-Instance nicht als Replikationsziel verwenden, da es sich nicht mehr um eine Read Replica handelt.

Voraussetzungen für das Heraufstufen einer Read Replica

Gehen Sie wie folgt vor, bevor Sie ein Read Replica heraufstufen:

• Überprüfen Sie Ihre Backup-Strategie:

  • Wir empfehlen, dass Sie Backups aktivieren und mindestens ein Backup durchführen. 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 Ihre Read Replica nicht den backing-up Status hat. Sie können eine Read Replica nicht heraufstufen, wenn sie sich in diesem Status befindet.

• Beenden Sie das Schreiben aller Transaktionen in die primäre DB-Instance und warten Sie dann, bis RDS alle Aktualisierungen auf die Read Replica angewendet hat.

  Datenbank-Updates werden im Lesereplikat durchgeführt, nachdem sie in der primären DB-Instance vorgenommen wurden. Die Verzögerung bei der Replikation 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 einer MySQL- oder MariaDB-Read Replica vorzunehmen, bevor Sie sie heraufstufen, setzen Sie den Parameter 0 in der read_only DB-Parametergruppe für die Read Replica auf. 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.

Eine Read Replica heraufstufen: grundlegende Schritte

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

1. Bewerben Sie die Read Replica, indem Sie die Option Promote auf der Amazon RDS-Konsole, den AWS CLI Befehl promote-read-replicaoder den PromoteReadReplicaAmazon RDS-API-Vorgang verwenden.

   Anmerkung

   Das Hochstufen kann einige Minuten in Anspruch nehmen. Wenn Sie eine Read Replica heraufstufen, stoppt RDS die Replikation und startet die Read Replica 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.

Konsole

Hochstufen einer Read Replica zu einer eigenständigen DB-Instance

1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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.

AWS CLI

Verwenden Sie den AWS CLI promote-read-replicaBefehl, um eine Read Replica zu einer eigenständigen DB-Instance hochzustufen.

Beispiel

Für LinuxmacOS, oderUnix:

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

Windows:

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

RDS-API

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.

Sie können den Status einer Read Replica auch mithilfe des AWS CLI describe-db-instances Befehls oder des Amazon DescribeDBInstances RDS-API-Vorgangs 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 sich die Amazon ReplicaLag RDS-Metrik ansehen.

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 CloudWatch Amazon-Metriken Oldest Replication Slot Lag und zeigenTransaction Logs Disk Usage, wie weit das verzögerteste Replikat 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 finden Sie CloudWatch unter. Überwachen von Amazon RDS-Metriken mit Amazon CloudWatch

Erstellen Sie eine Read Replica in einer anderen AWS-Region

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

Sie erstellen eine Read Replica in einer anderen AWS-Region , um Folgendes zu tun:

• Verbessern Ihrer Notfallwiederherstellungsfähigkeiten.

• Skalieren Sie Lesevorgänge so, dass sie Ihren Benutzern AWS-Region näher kommen.

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

Das Erstellen eines Read Replicas in einer AWS-Region anderen als der Quellinstanz ähnelt dem Erstellen eines Replikats in derselben. AWS-Region Sie können den API-Vorgang verwenden AWS Management Console, den create-db-instance-read-replicaBefehl ausführen oder den CreateDBInstanceReadReplicaAPI-Vorgang aufrufen.

Anmerkung

Um eine verschlüsselte Read Replica 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 Unterstützte Regionen und DB-Engines für regionsübergreifende Read Replicas in Amazon RDS.

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.

Konsole

Sie können eine Read Replica erstellen, indem Sie die AWS-Regionen verwenden. AWS Management Console

Um eine Read Replica auf der anderen Seite der Konsole AWS-Regionen zu erstellen

1. Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie 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. Um eine verschlüsselte Read Replica in einem anderen AWS-Region zu erstellen:

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

   2. Wählen Sie für AWS KMS keydie AWS KMS key ID des KMS-Schlüssels im Ziel AWS-Region aus.

   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.

AWS CLI

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 die Read Replica von der gewünschten AWS-Region Stelle create-db-instance-read-replicaaus (Zielregion) 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 eine Read Replica in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen, können Sie den AWS CLI create-db-instance-read-replicaBefehl vom Ziel aus 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 die Read Replica 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 LinuxmacOS, oderUnix:

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 der Read Replica im 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ürLinux, odermacOS: 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 eine verschlüsselte Lesereplik zwischen den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (US-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 über die Option pre-signed-url finden Sie unter create-db-instance-read-replica in der AWS CLI -Befehlsreferenz.

RDS-API

Um eine Read Replica aus einer Quell-MySQL-, Microsoft SQL Server-, MariaDB-, Oracle- oder PostgreSQL-DB-Instance in einer anderen zu erstellen AWS-Region, können Sie die Amazon RDS-API-Operation CreateDB Replica aufrufen. InstanceRead In diesem Fall rufen Sie CreateDB InstanceRead Replica von der AWS-Region Stelle aus auf, an der Sie die Read Replica haben möchten (Zielregion), 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 eine verschlüsselte Read Replica in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen, können Sie den Amazon CreateDBInstanceReadReplicaRDS-API-Vorgang vom Ziel AWS-Region aus verwenden. Um eine verschlüsselte Read Replica in einer anderen zu erstellen AWS-Region, müssen Sie einen Wert für angeben. PreSignedURL PreSignedURLsollte eine Anforderung für den CreateDBInstanceReadReplicaVorgang enthalten, um die Quelle AWS-Region aufzurufen, in der das Lesereplikat erstellt wurde. 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. Je nach den AWS-Regionen beteiligten Daten und der Menge der Daten in den Datenbanken kann dieser Vorgang Stunden in Anspruch nehmen. 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 der angegebenen Read Replica im Ziel AWS-Region und setzt den Status auf Creating.

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 im Ziel als automatisierter Snapshot AWS-Region mit dem Status Wird erstellt 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 zur Durchführung einer Replikation innerhalb einer 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. Aufgrund der Beschränkung der Anzahl der ACL-Einträge (Access Control List) für die Quell-VPC kann RDS nicht mehr als fünf regionsübergreifende Read Replica-DB-Instances garantieren.

• Sie können zwischen den Regionen GovCloud (USA-Ost) und GovCloud (US-West) replizieren, jedoch nicht innerhalb oder außerhalb von (USA). GovCloud

• 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 für jede Read Replica, die sich in einer anderen Instance AWS-Region als der Quell-Instance befindet, mit einer höheren Verzögerungszeit rechnen. 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.

• 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 in der --db-parameter-group-name Option des AWS CLI Befehls create-db-instance-read-replicaeine benutzerdefinierte Parametergruppe für die Read Replica angeben. 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. Lehnen Sie für eine erfolgreiche Anfrage keine Aufrufe von AWS Diensten ab.

• 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.

AWS Security Token Service Anmeldeinformationen verwenden

Sitzungstoken vom Endpunkt global AWS Security Token Service (AWS STS) sind nur in Bereichen gültig AWS-Regionen , die standardmäßig aktiviert sind (kommerzielle Regionen). Wenn Sie Anmeldeinformationen aus dem assumeRole API-Vorgang 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 liegt daran, dass Ihre Anmeldeinformationen in beiden Regionen gültig sein müssen. Dies gilt nur für Opt-in-Regionen, 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. Stellen Sie den globalen Endpunkt Valid in all AWS-Regionen in den AWS STS Kontoeinstellungen auf ein.

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

Weitere Informationen finden Sie unter Verwaltung AWS STS in an 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 vorgenommene Datenänderung überträgt Amazon RDS Daten von der Quelle AWS-Region zur Read Replica 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. Nehmen wir zum Beispiel an, Sie haben eine Quell-DB-Instance in einer AWS-Region und möchten in einer anderen drei Read Replicas 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 das Neue AWS-Region und geben Sie source-instance-1 es 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.