Arbeiten mit Lesereplikaten - Amazon Relational Database Service

Arbeiten mit Lesereplikaten

Amazon RDS nutzt die integrierte Replikationsfunktionalität der MariaDB-, Microsoft SQL Server, MySQL, Oracle und PostgreSQL DB-Engines, um aus einer Quell-DB-Instance eine besondere Art von DB-Instance zu erstellen, die als Lesereplikat bezeichnet wird. Die Quell-DB-Instance wird zur primären DB-Instance. In der primären DB-Instance ausgeführte Updates werden asynchron in das Lesereplikat kopiert. Sie können die Arbeitslast für Ihre primären DB-Instance reduzieren, indem Sie Leseabfragen aus Ihren Anwendungen an das Lesereplikat weiterleiten. Mit Lesereplikaten können Sie die Kapazitätseinschränkungen einer einzelnen DB-Instance für leseintensive Datenbank-Workloads elastisch erweitern.


            Read Replica-Konfiguration
Anmerkung

Die folgenden Informationen gelten für das Erstellen von Amazon-RDS-Lesereplikaten in der selben AWS-Region wie der 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 lokal ausgeführt wird.

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. Anwendungen verbinden sich mit dem Lesereplikat auf dieselbe Art und Weise, wie sie es mit jeder anderen DB-Instance tun. Amazon RDS repliziert alle Datenbanken in der Quell-DB-Instance.

Anmerkung

Die Oracle DB-Engine unterstützt Replikat-Datenbanken im aufgespielten Modus. 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 Oracle-Replikaten für Amazon RDS.

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 alleAWSUm den sicheren Kanal zu ermöglichen, wie das Hinzufügen von Sicherheitsgruppeneinträgen, um den sicheren Kanal zu ermöglichen. Weitere Informationen zu regionsübergreifenden Read Replicas finden Sie unter Erstellen eines Lesereplikats in einer anderen AWS-Region.

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 ist synchron, und das Standby-Replikat kann keinen Lesedatenverkehr bereitstellen.


            Konfiguration von Read Replica und Standby-Replikat

Weitere Informationen zu Hochverfügbarkeits- und Standby-Replikaten finden Sie unter Multi-AZ-Bereitstellungen für Hochverfügbarkeit.

Read Replicas werden von den MariaDB-, Microsoft SQL Server, MySQL, Oracle und PostgreSQL DB-Engines unterstützt. In diesem Abschnitt finden Sie allgemeine Informationen zur Verwendung von Lesereplikaten mit all diesen Engines. Weitere Informationen zur Verwendung dieser Lesereplikate mit einer bestimmten Engine finden Sie in den folgenden Abschnitten:

Übersicht über Amazon RDS-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.

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
PIOPS 100 GiB–32 TiB PIOPS, GP2, Standard
GP2 100 GiB–32 TiB PIOPS, GP2, Standard
GP2 <100 GiB GP2, Standard
Standard 100 GiB–6 TiB PIOPS, GP2, Standard
Standard <100 GiB GP2, Standard
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.

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 MyDBInstance in ReadReplica1 repliziert wird, können Sie ReadReplica1 nicht für eine Rückreplikation auf MyDBInstance konfigurieren. Bei MariaDB und MySQL ist es möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen. Sie können aus ReadReplica1 z. B. ein neues Lesereplikat wie etwa ReadReplica2 erstellen. Bei Oracle und SQL Server ist es nicht möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen.

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 AWS-Region zu löschen, wird jedes Read Replica auf eine eigenständige 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.

Unterschiede zwischen Lesereplikaten für verschiedene 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. Sie können automatische Backups in einem MySQL- oder MariaDB-Lesereplikat aktivieren.

Nein. Sie können keine manuellen Snapshots von Amazon RDS for Oracle-Lesereplikaten erstellen oder automatische Backups für sie aktivieren.

Ja, Sie können einen manuellen Snapshot eines PostgreSQL-Lesereplikats erstellen, aber Sie können keine automatischen Backups einstellen.

Nein. Sie können keine manuellen Snapshots von Amazon RDS for SQL Server-Lesereplikaten erstellen oder automatische Backups für sie aktivieren.

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 Oracle-Replikaten für Amazon RDS.

Nein.

Nein.

Erstellen eines Lesereplikats

Sie können eine Read Replica aus einer vorhandenen DB-Instance mit AWS Management Console, AWS CLI oder 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 AWS-Region wird dringend empfohlen, 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.

Sie können kein Lesereplikat in einem anderen AWS-Konto als der Quell-DB-Instance erstellen.

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

  1. Melden Sie sich bei der AWS Management Console an 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-Spezifikationen aus. Wir empfehlen Ihnen, dieselbe DB-Instance-Klasse und denselben Speichertyp wie bei der Quell-DB-Instance für das Lesereplikat zu verwenden.

  7. Wählen Sie für Multi-AZ-Bereitstellung die Option Ja, um eine Standby-Version des Replica in einer anderen Availability Zone zu erstellen und um einen Failover-Support für die Replica bereitzustellen.

    Anmerkung

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

  8. So erstellen Sie ein verschlüsseltes Read Replica:

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

    2. FürAWS KMS key, wählen Sie dieAWS KMS key-Bezeichner 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.

  9. Geben Sie andere Einstellungen an, z. B. automatische Speicherskalierung.

    Weitere Informationen zu den einzelnen Einstellungen finden Sie unter Einstellungen für DB-Instances.

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

Verwenden Sie den AWS CLI-Befehl create-db-instance-read-replica, um ein Lesereplikat aus einer Quell-DB-Instance zu erstellen. In diesem Beispiel wird auch das Autoscaling von Speicher aktiviert.

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

Beispiel

Für Linux, macOS oder Unix:

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

Für Windows:

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

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 Sie ein Lesereplikat hochstufen, wird die DB-Instance neu gestartet, bevor sie wieder verfügbar ist.


                Hochstufen eines Lesereplikats

Es gibt mehrere Gründe, weshalb Sie ein Lesereplikat zu einer eigenständigen DB-Instance hochstufen möchten:

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

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

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

Wenn Sie eine Read Replica hochstufen, behält die erstellte neue DB-Instance die Optionsgruppe und die Parametergruppe der ehemaligen Read Replica bei. Das Hochstufen kann einige Minuten oder mehr in Anspruch nehmen, abhängig von der Größe des Lesereplikats. Sobald Sie das Lesereplikat zu einer neuen DB-Instance hochstufen, verhält es sich wie jede andere DB-Instance. Beispielsweise können Sie Lesereplikate aus der neuen DB-Instance erstellen und zeitpunktbezogene Wiederherstellungsoperationen durchführen. Da die hochgestufte DB-Instance kein Lesereplikat mehr ist, können Sie diese nicht mehr als Replikationsziel verwenden. 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.

Die Sicherungsdauer ist eine Funktion der Anzahl von Änderungen an der Datenbank seit der letzten Backup. Wenn Sie ein Lesereplikat zu einer eigenständigen Instance hochstufen möchten, sollten Sie Backups aktivieren und vor dem Hochstufen mindestens ein Backup durchführen. Darüber hinaus können Sie ein Lesereplikat nicht zu einer eigenständigen Instance hochstufen, wenn es den Status backing-up aufweist. 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.

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

  1. Halten Sie alle Transaktionen in die primäre DB-Instance des Lesereplikats an und warten Sie anschließend, bis alle Updates für das Lesereplikat abgeschlossen wurden. Datenbank-Updates werden im Lesereplikat durchgeführt, nachdem sie in der primären DB-Instance aufgetreten sind; diese Replikationsverzögerung kann beträchtlich variieren. Verwenden Sie die Metrik Replica Lag, um zu bestimmen, wann alle Aktualisierungen am Lesereplikat vorgenommen wurden.

  2. Nur für MySQL und MariaDB: Wenn Sie Änderungen am MySQL- oder MariaDB-Lesereplikat durchführen müssen, müssen Sie den Parameter read_only in der DB-Parametergruppe für das Lesereplikat auf 0 setzen. 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.

  3. Stufen Sie das Lesereplikat mit der Option Hochstufen in der Amazon-RDS-Konsole, dem AWS CLI-Befehl promote-read-replica oder dem Amazon-RDS-API-Vorgang PromoteReadReplica hoch.

    Anmerkung

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

  4. (Optional) Ändern Sie die neue DB-Instance in eine Multi-AZ-Bereitstellung. Weitere Informationen finden Sie unter Ändern einer Amazon RDS-DB-Instance und Multi-AZ-Bereitstellungen für Hochverfügbarkeit.

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

  1. Melden Sie sich bei der AWS Management Console an 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-Befehl promote-read-replica, um eine Read Replica zu einer eigenständigen DB-Instance hochzustufen.

Beispiel

Für Linux, macOS oder Unix:

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

Für 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

Der Status eines Lesereplikats lässt sich auch mithilfe des AWS CLI-Befehls describe-db-instances oder der Amazon-RDS-API-Operation DescribeDBInstances anzeigen.

Der Status eines Lesereplikats kann einer der folgenden sein:

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

  • replication degraded (Replikation beeinträchtigt) (nur SQL Server) – -Replicas empfangen Daten von der primären Instance, aber mindestens eine Datenbank erhält möglicherweise keine Updates. Dies kann beispielsweise auftreten, wenn ein Replikat gerade neu erstellte Datenbanken einrichtet.

    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.

  • 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 CloudWatch überwachen, indem Sie die Amazon RDS-Metrik ReplicaLag 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 die Replica mit der größten Verzögerung in Bezug auf erhaltene WAL-Daten zurückliegt und wie viel Speicherplatz von 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 CloudWatch finden Sie unter Überwachen von Amazon RDS-Metriken mit Amazon CloudWatch.