Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Arbeiten mit DB-Instance-Lesereplikaten
Ein Lesereplikat ist eine schreibgeschützte Kopie einer DB-Instance. Sie können die Arbeitslast Ihrer primären DB-Instance reduzieren, indem Sie Abfragen aus Ihren Anwendungen an das Lesereplikat weiterleiten. Dies ermöglicht eine elastische Aufskalierung über die Kapazitätseinschränkungen einer einzelnen DB-Instance für leseintensive Datenbank-Workloads hinaus.
Amazon RDS nutzt die integrierten Replikationsfunktionen der DB-Engine, um ein Lesereplikat aus einer Quell-DB-Instance zu erstellen. Weitere Informationen zur Verwendung dieser Lesereplikate mit einer bestimmten Engine finden Sie in den folgenden Abschnitten:
Nachdem Sie ein Lesereplikat aus einer Quell-DB-Instance erstellt haben, wird die Quelle zur primären DB-Instance. Wenn Sie Updates an der primären DB-Instance vornehmen, kopiert Amazon RDS sie asynchron in das Lesereplikat. Das folgende Diagramm zeigt eine Quell-DB-Instance, die auf ein Lesereplikat in einer anderen Availability Zone (AZ) repliziert. Clients haben Lese-/Schreibzugriff auf die primäre DB-Instance und Nur-Lese-Zugriff auf das Replikat.
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
Übersicht über Amazon RDS-Lesereplikate
In den folgenden Abschnitten werden DB-Instance-Lesereplikate behandelt. Informationen zu Lesereplikaten von Multi-AZ-DB-Clustern finden Sie unter Arbeiten mit Multi-AZ-DB-Cluster-Read Replicas für Amazon RDS.
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 eine Read Replica erstellen, geben Sie eine vorhandene DB-Instance als Quelle an. Dann erstellt Amazon RDS einen Snapshot von der Quell-Instance und erstellt eine schreibgeschützte Instance aus diesem Snapshot. Dann verwendet Amazon RDS die asynchrone Replikationsmethode für die DB-Engine, um das Lesereplikat bei jeder Änderung an der primären DB-Instance zu aktualisieren.
Das Lesereplikat wird als eine DB-Instance ausgeführt, die nur schreibgeschützte Verbindungen zulässt. Eine Ausnahme bildet die DB-Engine von RDS für Oracle, die Replikat-Datenbanken im gemounteten Modus unterstützt. Ein aufgespieltes Replikat akzeptiert keine Benutzerverbindungen und kann daher keinen schreibgeschützten Workload bereitstellen. Bereitgestellte Replikate in RDS for Oracle werden hauptsächlich für die regionsübergreifende Notfallwiederherstellung verwendet. Weitere Informationen finden Sie unter Arbeiten mit Lese-Replikaten für Amazon RDS für Oracle.
Anwendungen verbinden sich mit dem Lesereplikat so wie mit einer DB-Instance. Amazon RDS repliziert alle Datenbanken in der Quell-DB-Instance.
Sie müssen Read Replicas manuell erstellen. RDS unterstützt keine automatische Skalierung von Read Replicas, d. h. das automatische Hinzufügen oder Entfernen von Read Replicas, wenn sich der Lesebedarf ändert.
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 AWS-Region als ihrer primären DB-Instance. In diesen Fällen richtet Amazon RDS einen sicheren Kommunikationskanal zwischen der primären DB-Instance und dem Lesereplikat ein. Amazon RDS richtet alle AWS Sicherheitskonfigurationen ein, die 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 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 |
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 die Festplattensubsysteme im primären Replikat sind, wird das Transaktionsprotokoll so lange gespeichert, VLFs bis das langsamste Replikat es gehärtet hat. |
|
Kann ein Replica beschreibbar gemacht werden? |
Ja. Sie können die MySQL- oder MariaDB-Lesereplikate aktivieren, um sie beschreibbar zu machen. |
Nein. Ein Oracle-Lesereplikat ist eine physische Kopie und Oracle erlaubt keine Schreibvorgänge in ein Lesereplikat. Sie können das Lesereplikat hochstufen, um es beschreibbar zu machen. Das hochgestufte Lesereplikat weist die replizierten Daten bis zu dem Punkt auf, an dem die Anforderung zum Hochstufen ausgegeben wurde. |
Nein. Ein PostgreSQL-Lesereplikat ist eine physische Kopie und PostgreSQL lässt nicht zu, dass ein Lesereplikat beschreibbar gemacht wird. |
Nein. Ein SQL Server-Lesereplikat ist eine physische Kopie und erlaubt auch keine Schreibvorgänge. Sie können das Lesereplikat hochstufen, um es beschreibbar zu machen. Das hochgestufte Lesereplikat weist die replizierten Daten bis zu dem Punkt auf, an dem die Anforderung zum Hochstufen ausgegeben wurde. |
|
Können Backups von Replica erstellt werden? |
Ja. Automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für MySQL oder RDS für MariaDB unterstützt. |
Ja. Automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für Oracle unterstützt. |
Ja, Sie können einen manuellen Snapshot von Lesereplikaten von RDS für PostgreSQL erstellen. Automatisierte Backups für Lesereplikate werden nur für RDS for PostgreSQL 14.1 und höhere Versionen unterstützt. Sie können keine automatisierten Backups für PostgreSQL-Lesereplikate für RDS for PostgreSQL Versionen vor 14.1 aktivieren. Erstellen Sie für RDS for PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen. |
Nein, automatische Backups und manuelle Snapshots werden auf Read Replicas von RDS für SQL Server nicht unterstützt. |
|
Kann ich parallele Replikation anwenden? |
Ja. Alle unterstützten MariaDB- und MySQL-Versionen lassen parallele Replikations-Threads zu. |
Ja. Wiederholungsprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt. |
Nein. PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation. |
Ja. Wiederholungsprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt. |
|
Können Sie ein Replikat in einem aufgespielten und nicht in einem schreibgeschützten Zustand pflegen? |
Nein. |
Ja. Die primäre Verwendung für aufgespielte Replikate ist die überregionale Notfallwiederherstellung. Für aufgespielte Replikate ist keine Active Data Guard-Lizenz erforderlich. Weitere Informationen finden Sie unter Arbeiten mit Lese-Replikaten für Amazon RDS für Oracle. |
Nein. |
Nein. |
Lesereplikat-Speichertypen
Ein Lesereplikat wird standardmäßig mit dem selben Speichertyp erstellt wie die Quell-DB-Instance. Jedoch können Sie ein Lesereplikat erstellen, das einen anderen Speicherchip aufweist als die Quell-DB-Instance, basierend auf den in der folgenden Tabelle gelisteten Optionen.
| Quell-DB-Instance-Speichertyp | Quell-DB-Instance-Speicherzuteilung | Optionen für den Lesereplikat-Speichertyp |
|---|---|---|
| Bereitgestellte IOPS | 100 GiB–64 TiB | Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch |
| Allgemeine Zwecke | 100 GiB–64 TiB | Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch |
| Allgemeine Zwecke | <100 GiB | Allgemeine Zwecke, magnetisch |
| Magnetic | 100 GiB–6 TiB | Bereitgestellte IOPS, Allgemeine Zwecke, magnetisch |
| Magnetic | <100 GiB | Allgemeine Zwecke, magnetisch |
Anmerkung
Wenn Sie den zugewiesenen Speicher eines Lesereplikats erhöhen, muss er um mindestens 10 Prozent erhöht werden. Wenn Sie versuchen, den Wert um weniger als 10 Prozent zu erhöhen, erhalten Sie einen Fehler.
Einschränkungen beim Erstellen eines Replikats aus einem Replikat
Amazon RDS unterstützt keine zirkulierende Replikation. Sie können eine DB-Instance nicht so konfigurieren, dass Sie als Replikationsquelle für eine vorhandene DB-Instance dient. Sie können ein neues Lesereplikat nur aus einer vorhandenen DB-Instance erstellen. Wenn beispielsweise MySourceDBInstance in ReadReplica1 repliziert wird, können Sie ReadReplica1 nicht für eine Rückreplikation auf MySourceDBInstance konfigurieren.
Bei RDS für MariaDB und RDS für MySQL und bei bestimmten Versionen von RDS für PostgreSQL ist es möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen. Sie können beispielsweise ein neues Lesereplikat ReadReplica2 aus einem vorhandenen Replikat ReadReplica1 erstellen. Bei RDS für Oracle und RDS für SQL Server ist es nicht möglich, ein Lesereplikat aus einem vorhandenen Lesereplikat zu erstellen.
Überlegungen zum Löschen von Replikaten
RDS unterstützt die automatische Skalierung von Read Replicas nicht. Daher erhöht RDS die Anzahl der Replikate nicht, wenn der Bedarf steigt, und erhöht oder verringert er die Anzahl der Replikate nicht, wenn der Bedarf sinkt. Wenn Sie Read Replicas nicht mehr benötigen, löschen Sie sie manuell. Verwenden Sie dabei dieselben Mechanismen wie beim Löschen einer DB-Instance. Wenn Sie eine Quell-DB-Instance löschen, ohne ihre Read Replicas in derselben zu löschen AWS-Region, wird jedes Replikat 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. Informationen zum Löschen der Quell-DB-Instance für eine regionsübergreifende Read Replica finden Sie unter. Überlegungen zur regionsübergreifenden Replikation
