Arbeiten mit Lesereplikaten - Amazon Relational Database Service

Arbeiten mit Lesereplikaten

Amazon RDS nutzt die integrierte Replikationsfunktionalität der MariaDB-, MySQL-, Oracle-, PostgreSQL- und Microsoft SQL Server-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 skalieren.

Anmerkung

Die folgenden Informationen gelten für das Erstellen von Amazon RDS-Lesereplikaten in derselben AWS-Region wie die der DB-Instance oder in einer anderen 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. Anschließend erstellt Amazon RDS einen Snapshot von der Quell-Instance und generiert eine schreibgeschützte Instance aus diesem Snapshot. Daraufhin 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 alle notwendigen AWS-Sicherheitskonfigurationen ein, wie das Hinzufügen von Sicherheitsgruppeneinträgen, um den sicheren Kanal zu ermöglichen.

Lesereplikate werden von den MariaDB-, MySQL-, Oracle-, PostgreSQL- und Microsoft SQL Server-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 E/A-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 E/A-Anforderungen bearbeiten, z. B. aufgrund von E/A-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

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 Read Replica aus einem vorhandenen Read Replica zu erstellen. Sie können aus ReadReplica1 z. B. ein neues Lesereplikat wie etwa ReadReplica2 erstellen. Bei Oracle, PostgreSQL und SQL Server ist es nicht möglich, ein Read Replica aus einem vorhandenen Read Replica 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 Read Replicas haben, finden Sie unter Überlegungen zur regionsübergreifenden Replikation Überlegungen zum Löschen der Quelle für regionsübergreifende Read Replicas.

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 MySQL und RDS 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 Sicherungen in einem MySQL- oder MariaDB-Lesereplikat aktivieren.

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

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

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

Kann ich parallele Replikation anwenden?

Ja. MySQL in der Version 5.6 oder neuer und alle unterstützten MariaDB-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 ein Lesereplikat aus einer bestehenden MySQL-, MariaDB- , Oracle-, PostgreSQL DB- oder SQL Server-Instance mithilfe der 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 E/A-Datenverkehrs Ihrer Quell-DB-Instance während des DB-Snapshots zur Folge. Die E/A-Aussetzung dauert in der Regel etwa eine Minute. Sie können die E/A-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. Für MySQL-DB-Instances werden automatische Sicherungen nur für Lesereplikate unterstützt, die mit MySQL 5.6 oder höher ausgeführt werden, nicht aber für MySQL-Versionen 5.5. Zum Aktivieren automatischer Sicherungen für ein Lesereplikat von Amazon RDS MySQL, Version 5.6 oder höher, erstellen Sie zuerst das Lesereplikat und ändern Sie dann das Lesereplikat so, dass automatische Sicherungen aktiviert sind.

Anmerkung

Innerhalb einer AWS-Region müssen alle Lesereplikate in derselben Virtual Private Cloud (VPC) basierend auf Amazon VPC als Quell-DB-Instance erstellt werden. Diese Anforderung gilt auch dann, wenn VPC Peering in der AWS-Region konfiguriert ist.

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

Erstellen eines Lesereplikats aus einer MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-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 MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-DB-Instance 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. 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. 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. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

  6. Wählen Sie die Einstellungen, die Sie verwenden möchten. Geben Sie unter DB instance identifier (DB-Instance-Kennung) einen Namen für das Lesereplikat ein. Passen Sie weitere Einstellungen nach Ihrem Bedarf an.

  7. Wählen Sie weitere Einstellungen aus, die Sie verwenden möchten.

  8. Wählen Sie Read Replica erstellen aus.

Um ein Lesereplikat aus einer MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-Quell-DB-Instance zu erstellen, verwenden Sie den AWS CLI-Befehl create-db-instance-read-replica.

Beispiel

Für Linux, macOS oder Unix:

aws rds create-db-instance-read-replica \ --db-instance-identifier myreadreplica \ --source-db-instance-identifier mydbinstance

Für Windows:

aws rds create-db-instance-read-replica ^ --db-instance-identifier myreadreplica ^ --source-db-instance-identifier mydbinstance

Um ein Lesereplikat aus einer MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-Quell-DB-Instance zu erstellen, verwenden Sie die Amazon RDS-API-Funktion CreateDBInstanceReadReplica.

https://rds.amazonaws.com/ ?Action=CreateDBInstanceReadReplica &DBInstanceIdentifier=myreadreplica &SourceDBInstanceIdentifier=mydbinstance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

Hochstufen eines Lesereplikats zur eigenständigen DB-Instance

Sie können ein MySQL-, MariaDB-, Oracle-, PostgreSQL- oder SQL Server-Lesereplikat auf eine eigenständige DB-Instance hochstufen. Wenn Sie ein Lesereplikat hochstufen, wird die DB-Instance neu gestartet, bevor sie wieder verfügbar ist.

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 ein Lesereplikat hochstufen, behält die neue DB-Instance, die erstellt wird, den Aufbewahrungszeitraum für Backups, das Sicherungsfenster, die Optionsgruppe und die Parametergruppe der ehemaligen Lesereplikatquelle 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 Sicherung. Wenn Sie ein Lesereplikat zu einer eigenständigen Instance hochstufen möchten, sollten Sie Sicherungen aktivieren und vor dem Hochstufen mindestens eine Sicherung 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 Sicherungen für Ihre Lesereplikate aktiviert haben, konfigurieren Sie das automatische Sicherungsfenster so, dass die täglichen Sicherungen 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 Promote (Hochstufen) in der Amazon RDS-Konsole, dem AWS CLI-Befehl promote-read-replica oder der Amazon RDS-API-Operation 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 Hohe Verfügbarkeit (Multi-AZ) für Amazon RDS.

Hochstufen eines Lesereplikats zu einer 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 unter Aktionen Promote read replica (Read Replica 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 ein Lesereplikat zu einer 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

Rufen Sie PromoteReadReplica auf, um ein Lesereplikat zu einer DB-Instance hochzustufen.

https://rds.amazonaws.com/ ?Action=PromoteReadReplica &DBInstanceIdentifier=myreadreplica &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

Erstellen eines Lesereplikats in einer anderen AWS-Region

Mit Amazon RDS können Sie ein MariaDB-, MySQL-, Oracle- oder PostgreSQL-Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance erstellen. Das Erstellen eines regionsübergreifenden Lesereplikats wird für SQL Server auf Amazon RDS nicht unterstützt.

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

  • Verbessern Ihrer Notfallwiederherstellungsfähigkeiten.

  • Skalieren von Leseoperationen in einer AWS-Region, die näher an Ihren Benutzern liegt.

  • Vereinfachen Sie die Migrationsvorgänge von einem Rechenzentrum in einer AWS-Region zu einem Rechenzentrum in einer anderen AWS-Region.

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

Für das Erstellen eines verschlüsselten Lesereplikats in einer anderen AWS-Region als der Region der Quell-DB-Instance muss die Quell-DB-Instance verschlüsselt sein.

Regionsübergreifende Read Replicas werden in den folgenden Opt-In-AWS-Regionen nicht unterstützt:

  • Afrika (Kapstadt)

  • Asien-Pazifik (Hongkong)

  • Europa (Mailand)

  • Naher Osten (Bahrain)

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

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

Erstellen eines Lesereplikats über mehrere AWS-Regionen hinweg mit der Konsole

  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 MariaDB-, MySQL-, Oracle- oder PostgreSQL-DB-Instance aus, die Sie als Quelle für ein Lesereplikat verwenden möchten. Wählen Sie unter Aktionen Create read replica (Read Replica erstellen) aus. 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.

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

  5. Wählen Sie die anderen Einstellungen aus, die Sie verwenden möchten:

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

    • Wählen Sie im Abschnitt Network & Security (Netzwerk und Sicherheit) einen Wert für Designation region (Kennzeichnung Region) und Designation DB subnet group (Kennzeichnung DB-Subnetzgruppe) aus.

    • Wählen Sie Enable Encryption (Verschlüsselung aktivieren) und anschließend Master key (Hauptschlüssel) aus, um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region zu erstellen. Wählen Sie für den Masterschlüssel die AWS Key Management Service (AWS KMS)-Schlüsselkennung des Kundenmasterschlüssels (CMK) der AWS-Zielregion aus.

    • Wählen Sie weitere Einstellungen aus, die Sie verwenden möchten.

  6. Wählen Sie Read Replica erstellen aus.

Sie können den Befehl create-db-instance-read-replica verwenden, um ein Lesereplikat aus einer MySQL-, MariaDB-, Oracle- oder PostgreSQL-Quell-DB-Instance in einer anderen AWS-Region zu erstellen. In diesem Fall verwenden Sie create-db-instance-read-replica aus der AWS-Region, in der Sie Ihr Lesereplikat 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 USA Ost (Nord-Virginia) befindet, sieht der ARN ähnlich wie in diesem Beispiel aus:

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

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

Sie können den AWS CLI-Befehl create-db-instance-read-replica aus der AWS-Zielregion verwenden, um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region als der Quell-DB-Instance zu erstellen. Die folgenden Parameter werden verwendet, um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region zu erstellen:

  • --source-region: die AWS-Region, in der das verschlüsselte Lesereplikat erstellt wird. Wenn source-region nicht festgelegt ist, müssen Sie einen pre-signed-url-Wert festlegen. Eine pre-signed-url ist eine URL, die eine mit der Signaturversion 4 signierte Anforderung für die CreateDBInstanceReadReplica-Operation beinhaltet, die in der AWS-Quellregion aufgerufen wird, aus der das Lesereplikat erstellt wurde. Weitere Informationen zur pre-signed-url finden Sie unter CreateDBInstanceReadReplica.

  • --source-db-instance-identifier: die DB-Instance-Kennung für das verschlüsselte Lesereplikat, das erstellt wurde. Diese Kennung muss im ARN-Format der AWS-Quellregion angegeben werden. Die in source-db-instance-identifier angegebene AWS-Region muss mit der als source-region festgelegten AWS-Region übereinstimmen.

  • --db-instance-identifier: die Kennung für das verschlüsselte Lesereplikat in der AWS-Zielregion.

  • --kms-key-id — Die AWS KMS-Schlüsselkennung für den Kundenmasterschlüssel (CMK), der für das Verschlüsseln des Read Replica in der AWS-Zielregion zu verwenden ist.

Der folgende Code erstellt ein Lesereplikat in der Region us-west-2.

Beispiel

Für Linux, macOS oder Unix:

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

Für Windows:

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

Der folgende Code erstellt ein Lesereplikat in einer anderen AWS-Region als die der Quell-DB-Instance. Die AWS-Region, in der Sie den create-db-instance-read-replica-Befehl aufrufen, ist die AWS-Zielregion für das verschlüsselte Lesereplikat.

Beispiel

Für Linux, macOS oder Unix:

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

Für Windows:

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

Sie können die Amazon RDS-API-Funktion CreateDBInstanceReadReplica aufrufen, um ein Lesereplikat aus einer MySQL, -MariaDB-, Oracle- oder -PostgreSQL-Quell-DB-Instance in einer anderen AWS-Region zu erstellen. In diesem Fall rufen Sie CreateDBInstanceReadReplica aus der AWS-Region auf, in der Sie das Lesereplikat 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.

Sie können die Amazon RDS-API-Operation CreateDBInstanceReadReplica aus der Ziel-AWS-Region verwenden, um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region als die der Quell-DB-Instance zu erstellen. Sie müssen für PreSignedURL einen Wert festlegen, um ein verschlüsseltes Lesereplikat in einer anderen AWS-Region zu erstellen. PreSignedURL sollte eine Anfrage für die Operation CreateDBInstanceReadReplica enthalten, um den Aufruf in der AWS-Region auszuführen, in der das Lesereplikat erstellt wurde. Weitere Informationen über PreSignedUrl finden Sie unter CreateDBInstanceReadReplica.

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

arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance

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%253D CreateDBInstanceReadReplica %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%1234567890 12%25253Adb%25253Amy-mysql-instance %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4%2526SourceDBInstanceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Ainstance%25253Amysql-instance1-instance-20161115 %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=arn:aws:rds:us-east-1:123456789012:db:my-mysql-instance &Version=2012-01-15 &SignatureVersion=2 &SignatureMethod=HmacSHA256 &Timestamp=2012-01-20T22%3A06%3A23.624Z &AWSAccessKeyId=<AWS Access Key ID> &Signature=<Signature>

Überlegungen zur regionsübergreifenden Replikation

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

  • Das Replizieren zwischen AWS-Regionen ist nur bei Verwendung der folgenden Amazon RDS-DB-Instances möglich:

    • MariaDB (alle Versionen).

    • MySQL (Version 5.6 und höher).

    • Oracle Enterprise Edition (EE) Engine Version 12.1.0.2.v10 und höhere 12.1-Versionen, alle Versionen von 12.2 und alle Versionen von 18.0.

      Sie müssen über eine aktive Data Guard-Lizenz verfügen. Informationen zu den Einschränkungen für regionsübergreifende Oracle-Lesereplikate finden Sie unter Replikatanforderungen für Oracle.

    • PostgreSQL (alle Versionen).

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

  • Sie können ein regionsübergreifendes Amazon RDS-Lesereplikat aus einer Amazon RDS-Quell-DB-Instance erstellen, die kein Lesereplikat einer anderen Amazon RDS-DB-Instance ist.

  • Sie können keinen Replikationskanal in die Region AWS GovCloud (US-West) oder aus dieser heraus einrichten.

  • Bei einem Lesereplikat, das sich in einer anderen AWS-Region als die Quell-Instance befindet, ist eine größere zeitliche Verzögerung zu erwarten. Die zeitliche Verzögerung lässt sich auf längere Netzwerkkanäle zwischen regionalen Rechenzentren zurückführen.

  • Innerhalb einer AWS-Region müssen sich alle regionsübergreifenden Lesereplikate, die aus derselben Quell-DB-Instance erstellt wurden, entweder in derselben VPC oder außerhalb einer VPC befinden. 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.

  • Sie können ein regionsübergreifendes Lesereplikat, das sich in einer VPC befindet, aus einer Quell-DB-Instance erstellen, die sich in einer VPC in einer anderen AWS-Region befindet. Sie können auch ein regionsübergreifendes Lesereplikat in einer VPC aus einer Quell-DB-Instance erstellen, die sich nicht in einer VPC befindet. Sie können auch ein regionsübergreifendes Lesereplikat, das sich nicht in einer VPC befindet, aus einer Quell-DB-Instance erstellen, die sich in einer VPC befindet.

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

  • Das Lesereplikat verwendet die Standard-DB-Parametergruppe für die angegebene DB-Engine.

  • Das Lesereplikat verwendet die Standardsicherheitsgruppe.

  • Wenn bei MariaDB-, MySQL- und Oracle-DB-Instances die Quelle 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 Quelle für ein regionsübergreifendes Lesereplikat gelöscht wird. Das Lesereplikat wird nicht hochgestuft.

Kosten für regionsübergreifende Replikationen

Für Daten, die für regionsübergreifende Replikation übermittelt werden, fallen Amazon RDS-Datenübertragungskosten an. Diese regionsübergreifenden Replikationsaktionen generieren Kosten für die übermittelten Daten aus der AWS-Quellregion:

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

  • Für jede in den Quelldatenbanken durchgeführte Datenänderung übermittelt Amazon RDS Daten aus der AWS-Quellregion an die 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. Nehmen wir beispielsweise an, Sie haben eine Quell-DB-Instance in einer AWS-Region und Sie möchten drei Lesereplikate in einer anderen AWS-Region haben. 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 über source-instance-1 in einer AWS-Region verfügen, können Sie Folgendes tun:

  • Erstellen Sie read-replica-1 in der neuen AWS-Region und legen Sie source-instance-1 als Quelle fest.

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

Wie Amazon RDS regionsübergreifende Replikationen durchführt

Amazon RDS verwendet den folgenden Vorgang, um ein regionsübergreifendes Lesereplikat zu erstellen. In Abhängigkeit von den beteiligten AWS-Regionen und der Menge der Daten 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 dem Einrichten des angegebenen Lesereplikats in der AWS-Zielregion und setzt den Status auf creating (wird erstellt).

  3. Amazon RDS erstellt einen automatisierten DB-Snapshot der Quell-DB-Instance in der AWS-Quellregion. 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 ein automatischer Snapshot in der AWS-Zielregion mit dem Status Wird erstellt … gelistet. 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.

Beispiele für regionsübergreifende Replikationen

Beispiel Erstellen eines regionsübergreifenden Lesereplikats außerhalb jeglicher VPC

Im folgenden Beispiel wird ein Lesereplikat in der Region "us-west-2" aus einer Quell-DB-Instance in der Region "us-east-1" erstellt. Das Lesereplikat wird außerhalb einer VPC erstellt:

Für Linux, macOS oder Unix:

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

Für Windows:

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

Beispiel Erstellen eines regionsübergreifenden Lesereplikats in einer VPC

In diesem Beispiel wird ein Lesereplikat in Region "us-west-2" aus einer DB-Instance in Region "us-east-1" erstellt. Das Lesereplikat wird in einer VPC erstellt, der eine spezifische DB-Subnetzgruppe zugewiesen ist:

Für Linux, macOS oder Unix:

aws rds create-db-instance-read-replica \ --db-instance-identifier SimCoProd01Replica01 \ --region us-west-2 --db-subnet-group-name my-us-west-2-subnet --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01

Für Windows:

aws rds create-db-instance-read-replica ^ --db-instance-identifier SimCoProd01Replica01 ^ --region us-west-2 --db-subnet-group-name my-us-west-2-subnet --source-db-instance-identifier arn:aws:rds:us-east-1:123456789012:db:SimcoProd01

Überwachen der Lesereplikation

Es gibt mehrere Arten, den Status eines Lesereplikats zu überwachen. Die Amazon RDS-Konsole zeigt den Status eines Lesereplikats im Bereich Availability and durability (Verfügbarkeit und Beständigkeit) der Lesereplikatdetails an. Um die Details für ein Lesereplikat anzuzeigen, klicken Sie in der Liste der 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 ergreift diese Maßnahme, um erhöhten Speicheranforderungen in der Quell-DB-Instance oder langen Failover-Zeiten vorzubeugen.

    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.

Überwachen einer Replikationsverzögerung

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

Für MySQL und MariaDB meldet die Metrik ReplicaLag den Wert des Seconds_Behind_Master-Feldes von Befehl SHOW SLAVE STATUS. 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.

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 ag.name name, MAX(hdrs.secondary_lag_seconds) max_lag from sys.dm_hadr_database_replica_state

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 slave_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 Überwachung mit Amazon CloudWatch.