Unterschiede zwischen Lesereplikaten für DB-Engines - Amazon Relational Database Service

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.

Unterschiede zwischen Lesereplikaten für DB-Engines

Da DB-Engines von Amazon RDS die Replikation jeweils unterschiedlich implementieren, gibt es einige wichtige Unterschiede, die Sie kennen sollten, wie in der folgenden Tabelle aufgezeigt.

Db2

Replikate für RDS für Db2 weisen die folgenden Features und Verhaltensweisen auf:

  • Replikationsmethode – Physische Replikation.

  • Löschen von Transaktionsprotokollen – RDS für Db2 löscht die Protokolle aus der primären DB-Instance, wenn die folgenden Bedingungen erfüllt sind:

    • Die Protokolle sind mindestens zwei Stunden alt.

    • Die Archiveinstellung für die Aufbewahrungszeit des Protokolls ist abgelaufen.

    • RDS für Db2 hat die Protokolle erfolgreich auf alle Replikat-DB-Instances repliziert.

    Dies gilt sowohl für dieselben AWS-Region DB-Instances als auch für regionsübergreifende DB-Instances. Weitere Informationen zum Festlegen von Aufbewahrungszeiten für Archivprotokolle finden Sie unter rdsadmin.set_archive_log_retention.

  • Beschreibbare Replikate – Ein Db2-Replikat ist eine physische Kopie und Db2 erlaubt keine Schreibvorgänge in ein Replikat. Sie können das Replikat hochstufen, um es beschreibbar zu machen. Das hochgestufte Replikat weist die replizierten Daten bis zu dem Punkt auf, an dem die Anforderung zum Hochstufen ausgegeben wurde.

  • Backups – Automatische Backups und manuelle Snapshots werden auf Lesereplikaten von RDS für Db2 unterstützt.

  • Parallele Replikation – Archivprotokolldaten werden immer parallel aus der primären Datenbank an alle ihre Replikate übermittelt.

  • Standby-Status – Die primäre Verwendung für Standby-Replikate ist die regionsübergreifende Notfallwiederherstellung. Weitere Informationen finden Sie unter Arbeiten mit Replikaten für Amazon RDS für Db2.

MariaDB und MySQL

Lesereplikate für RDS für MariaDB und RDS für MySQL weisen die folgenden Features und Verhaltensweisen auf:

  • Replikationsmethode – Logische Replikation.

  • Löschen von Transaktionsprotokollen – RDS für MariaDB und RDS für MySQL behalten alle Binärprotokolle bei, die nicht angewendet wurden.

  • Beschreibbare Replikate – Sie können die MariaDB- oder MySQL-Lesereplikate beschreibbar machen.

  • Backups – Automatische Backups und manuelle Snapshots werden auf Lesereplikaten von RDS für MariaDB oder RDS für MySQL unterstützt.

  • Parallele Replikation – Alle unterstützten MariaDB- und MySQL-Versionen lassen parallele Replikations-Threads zu.

  • Aufgespielter Zustand – Nicht unterstützt.

Oracle

Lesereplikate für RDS für Oracle weisen die folgenden Features und Verhaltensweisen auf:

  • Replikationsmethode – Physische Replikation.

  • Löschen von Transaktionsprotokollen – Wenn eine primäre DB-Instance keine regionsübergreifenden Lesereplikate hat, behält Amazon RDS für Oracle Transaktionsprotokolle 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 für 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.

  • Beschreibbare Replikate – 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.

  • Backups – Automatische Backups und manuelle Snapshots werden auf Lesereplikaten von RDS für Oracle unterstützt.

  • Parallele Replikation – Redo-Protokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt.

  • Aufgespielter Zustand – Die primäre Verwendung für aufgespielte Replikate ist die regionsübergreifende 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.

PostgreSQL

Lesereplikate für RDS für PostgreSQL weisen die folgenden Features und Verhaltensweisen auf:

  • Replikationsmethode – Physische Replikation.

  • Löschen von Transaktionsprotokollen – PostgreSQL verfügt über den Parameter wal_keep_segments, der vorgibt, wie viele Write-Ahead-Protokolldateien (WAL) für die Bereitstellung von Daten an die Lesereplikate beibehalten werden. Der Parameterwert gibt die Anzahl an beizubehaltenden Protokollen an.

  • Beschreibbare Replikate – Ein PostgreSQL-Lesereplikat ist eine physische Kopie und PostgreSQL lässt nicht zu, dass ein Lesereplikat beschreibbar gemacht wird.

  • Backups – Manuelle Snapshots werden für Lesereplikate von RDS für PostgreSQL unterstützt. Automatisierte Backups für Lesereplikate werden nur für RDS für PostgreSQL 14.1 und höhere Versionen unterstützt. Sie können keine automatisierten Backups für PostgreSQL-Lesereplikate für RDS für PostgreSQL Versionen vor 14.1 aktivieren. Erstellen Sie für RDS für PostgreSQL 13 und frühere Versionen einen Snapshot aus einem Lesereplikat, wenn Sie eine Sicherungskopie davon wünschen.

  • Parallele Replikation – PostgreSQL verfügt über einen Einzelvorgang für die Handhabung von Replikation.

  • Aufgespielter Zustand – Nicht unterstützt.

SQL Server

Lesereplikate für RDS für SQL Server weisen die folgenden Features und Verhaltensweisen auf:

  • Replikationsmethode – Physische Replikation.

  • Löschen von Transaktionsprotokollen – 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, speichert das Transaktionsprotokoll das so lange, VLFs bis das langsamste Replikat es gehärtet hat.

  • Beschreibbare Replikate – 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.

  • Backups – Automatische Backups und manuelle Snapshots werden auf Lesereplikaten von RDS für SQL Server nicht unterstützt.

  • Parallele Replikation – Redo-Protokolldaten werden immer parallel aus der primären Datenbank an alle ihre Lesereplikate übermittelt.

  • Aufgespielter Zustand – Nicht unterstützt.