Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Arbeiten mit DB-Instance-Lesereplikaten
Ein Lesereplikat ist eine schreibgeschützte Kopie einer DB-Instance. Sie können die Arbeitslast Ihrer primären DB-Instance reduzieren, indem Sie Abfragen aus Ihren Anwendungen an das Lesereplikat weiterleiten. Dies ermöglicht eine elastische Aufskalierung über die Kapazitätseinschränkungen einer einzelnen DB-Instance für leseintensive Datenbank-Workloads hinaus.
Um eine Read Replica aus einer Quell-DB-Instance zu erstellen, RDS verwendet Amazon die integrierten Replikationsfunktionen der DB-Engine. Weitere Informationen zur Verwendung dieser Lesereplikate mit einer bestimmten Engine finden Sie in den folgenden Abschnitten:
Nachdem Sie ein Lesereplikat aus einer Quell-DB-Instance erstellt haben, wird die Quelle zur primären DB-Instance. Wenn Sie Aktualisierungen an der primären DB-Instance vornehmen, RDS kopiert Amazon diese asynchron in die Read Replica. 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 Lesezugriff auf die Replik.
Read Replicas werden als Standard-DB-Instances zu den gleichen Tarifen abgerechnet wie die DB-Instance-Klasse, die für das Replikat verwendet wird. Die Datenübertragung, die bei der Replikation von Daten zwischen der Quell-DB-Instance und einer Read Replica innerhalb derselben entsteht, wird Ihnen nicht in Rechnung gestellt. AWS-Region Weitere Informationen erhalten Sie unter Kosten für regionsübergreifende Replikationen und DB-Instance-Abrechnung für Amazon RDS.
Themen
Überblick über Amazon RDS Read Replicas
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-Read Replicas für Amazon RDS.
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 der Quell-Instance und erstellt aus dem Snapshot eine schreibgeschützte Instance. Amazon verwendet RDS dann die asynchrone Replikationsmethode für die DB-Engine, um die Read Replica 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 RDS für Oracle, die Replikatdatenbanken im Mount-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 aus 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 für Amazon RDS.
Regionsübergreifende Lesereplikate
In einigen Fällen befindet sich eine Read Replica in einer anderen als der primären AWS-Region DB-Instance. In diesen Fällen RDS richtet Amazon einen sicheren Kommunikationskanal zwischen der primären DB-Instance und der Read Replica 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 einer Read Replica in einem 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 die Einrichtung der Replikation mit einer Instance, die auf einer EC2 Amazon-Instance läuft oder lokal ist.
Unterschiede zwischen Lesereplikaten für DB-Engines
Da Amazon RDS DB-Engines die Replikation unterschiedlich implementieren, gibt es mehrere signifikante Unterschiede, die Sie kennen sollten, wie in der folgenden Tabelle dargestellt.
| Funktion oder Verhalten | My SQL und MariaDB | Oracle | Postger SQL | SQLServer |
|---|---|---|---|---|
|
Was ist die Replikationsmethode? |
Logische Replikation. |
Physikalische Replikation. |
Physikalische Replikation. |
Physikalische Replikation. |
|
Wie werden Transaktionsprotokolle bereinigt? |
RDSfür My SQL und RDS für MariaDB behalten Sie alle Binärprotokolle bei, die nicht angewendet wurden. |
Wenn eine primäre DB-Instance keine regionsübergreifenden Read Replicas hat, speichert Amazon RDS for Oracle mindestens zwei Stunden an Transaktionsprotokollen auf der Quell-DB-Instance. 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. Falls ja, behält Amazon RDS for Oracle die Transaktionsprotokolle in der Quell-DB-Instance, bis sie übertragen und auf alle regionsübergreifenden Read Replicas angewendet wurden. Weitere Informationen zum Festlegen von Aufbewahrungszeiten für Archivprotokolle finden Sie unter Beibehaltung von archivierten Redo-Log-Dateien. |
Postgre SQL hat den Parameter |
Die virtuelle Protokolldatei (VLF) der Transaktionslogdatei auf dem primären Replikat kann gekürzt werden, wenn sie für die sekundären Replikate nicht mehr benötigt wird. VLFSie können nur dann als inaktiv markiert werden, wenn die Protokolldatensätze in den Replikaten gehärtet wurden. Unabhängig davon, wie schnell die Festplattensubsysteme im primären Replikat sind, wird das Transaktionsprotokoll so lange aufbewahrt, VLFs bis das langsamste Replikat es gehärtet hat. |
|
Kann ein Replica beschreibbar gemacht werden? |
Ja. Sie können die My SQL - oder MariaDB-Read Replica so einrichten, dass sie beschreibbar ist. |
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. Eine SQL Postgre-Read Replica ist eine physische Kopie, und Postgre erlaubt es SQL nicht, eine Read Replica schreibbar zu machen. |
Nein. Eine SQL Server-Lesereplik 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 RDS Replicas für My SQL oder RDS für MariaDB unterstützt. |
Ja. Automatische Backups und manuelle Snapshots werden auf RDS Oracle Read Replicas unterstützt. |
Ja, Sie können einen manuellen Snapshot von RDS für Postgre-Read Replicas erstellen. SQL Automatisierte Backups für Read Replicas werden nur RDS für Postgre SQL 14.1 und höhere Versionen unterstützt. Sie können automatische Backups für SQL Postgre-Read Replicas nicht für Postgre-Versionen vor RDS 14.1 aktivieren. SQL Erstellen Sie RDS für Postgre SQL 13 und frühere Versionen einen Snapshot aus einer Read Replica, wenn Sie eine Sicherungskopie davon erstellen möchten. |
Nein. Automatische Backups und manuelle Snapshots werden bei Read Replicas RDS auf SQL Servern nicht unterstützt. |
|
Kann ich parallele Replikation anwenden? |
Ja. Alle unterstützten SQL Versionen von MariaDB und My ermöglichen parallel Replikations-Threads. |
Ja. Wiederholungsprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt. |
Nein. Postgre SQL hat einen einzigen Prozess, der die Replikation abwickelt. |
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 |
|---|---|---|
| Bereitgestellt IOPS | 100 GiB–64 TiB | Bereitgestellt, für allgemeine ZweckeIOPS, magnetisch |
| Allgemeine Zwecke | 100 GiB–64 TiB | Bereitgestellt, für allgemeine ZweckeIOPS, magnetisch |
| Allgemeine Zwecke | <100 GiB | Allgemeine Zwecke, magnetisch |
| Magnetic | 100 GiB–6 TiB | Bereitgestellt, für allgemeine ZweckeIOPS, 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 unterstützt RDS keine zirkuläre 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.
RDSFür MariaDB und RDS für My SQL sowie für bestimmte Versionen von RDS für Postgre SQL können Sie eine Read Replica aus einer vorhandenen Read Replica erstellen. Sie können beispielsweise ein neues Lesereplikat ReadReplica2 aus einem vorhandenen Replikat ReadReplica1 erstellen. Für Oracle und RDS RDS für SQL Server können Sie keine Read Replica aus einer vorhandenen Read Replica 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.
