Arbeiten mit MariaDB Read Replicas

Im Folgenden finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten in Amazon RDS for MariaDB. Allgemeine Informationen zu Lesereplikaten und Anleitungen zu ihrer Verwendung finden Sie in Arbeiten mit DB-Instance-Lesereplikaten.

Konfigurieren von Lesereplikaten mit MariaDB

Bevor eine MariaDB-DB-Instance als Replikationsquelle eingesetzt werden kann, müssen Sie automatische Backups für die Quell-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.

Sie können bis zu 15 Lesereplikate von einer DB-Instance innerhalb derselben Region erstellen. Damit die Replikation effektiv durchgeführt werden kann, sollte jedes Lesereplikat über dieselbe Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance verfügen. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.

RDS für MariaDB unterstützt kaskadierende Lesereplikate. Informationen zum Konfigurieren von kaskadierenden Lesereplikaten finden Sie unter Verwendung von kaskadierenden Lesereplikaten mit RDS für MariaDB.

Sie können mehrere Erstellungs- und Löschaktionen für Lesereplikate gleichzeitig ausführen, die auf die gleiche Quell-DB-Instance verweisen. Halten Sie sich bei der Ausführung dieser Aktionen an die Grenze von 15 Lesereplikaten für jede Quell-Instance.

Konfigurieren von Replikationsfiltern mit MariaDB

Sie können Replikationsfilter verwenden, um anzugeben, welche Datenbanken und Tabellen mit einem Lesereplikat repliziert werden. Replikationsfilter können Datenbanken und Tabellen in die Replikation einbeziehen oder sie von der Replikation ausschließen.

Im Folgenden finden Sie einige Anwendungsfälle für Replikationsfilter:

Einstellen der Parameter der Replikationsfilter bei RDS for MariaDB

Um Replikationsfilter zu konfigurieren, legen Sie die folgenden Filterparameter für die Replikation fest:

Die Parameter werden in der angegebenen Reihenfolge ausgewertet. Weitere Informationen darüber, wie diese Parameter funktionieren, finden Sie in der Dokumentation für MariaDB.

Standardmäßig hat jeder dieser Parameter einen leeren Wert. Sie können diese Parameter auf jedem Lesereplikat verwenden, um Replikationsfilter festzulegen, zu ändern und zu löschen. Wenn Sie einen dieser Parameter festlegen, trennen Sie die einzelnen Filter durch ein Komma voneinander.

Sie können die Platzhalterzeichen % und _ in den Parametern replicate-wild-do-table und replicate-wild-ignore-table verwenden. Der Platzhalter % entspricht einer beliebigen Anzahl von Zeichen, und der Platzhalter _ entspricht nur einem Zeichen.

Das binäre Protokollierungsformat der Quell-DB-Instance ist wichtig für die Replikation, da es den Datensatz der Datenänderungen bestimmt. Die Einstellung des Parameters binlog_format bestimmt, ob die Replikation zeilenbasiert oder anweisungsbasiert ist. Weitere Informationen finden Sie unter Binäres Protokollformat.

Einschränkungen der Replikationsfilter bei RDS for MariaDB

Folgende Einschränkungen gelten für Replikationsfilter bei RDS for MariaDB:

Beispiele für Replikationsfilter bei RDS for MariaDB

Um die Replikationsfilter für ein Lesereplikat zu konfigurieren, ändern Sie die Parameter der Replikationsfilter in der Parametergruppe, die dem Lesereplikat zugeordnet ist.

Sie können Parameter in einer Parametergruppe mithilfe von AWS Management Console, AWS CLI oder der RDS-API festlegen. Weitere Informationen zum Festlegen von Parametern finden Sie unter Ändern von Parametern in einer DB-Parametergruppe in Amazon RDS. Wenn Sie Parameter in einer Parametergruppe festlegen, verwenden alle DB-Instances, die der Parametergruppe zugeordnet sind, diese Parametereinstellungen. Wenn Sie Parameter der Replikationsfilter in einer Parametergruppe festlegen, stellen Sie sicher, dass die Parametergruppe nur Lesereplikaten zugeordnet ist. Lassen Sie die Parameter der Replikationsfilter für Quell-DB-Instances leer.

In den folgenden Beispielen werden die Parameter mithilfe von festgeleg AWS CLI. Diese Beispiele legen ApplyMethod auf immediate fest, sodass die Parameteränderungen unmittelbar nach Abschluss des CLI-Befehls erfolgen. Wenn Sie möchten, dass eine ausstehende Änderung nach dem Neustart des Lesereplikats angewendet wird, legen Sie ApplyMethod auf pending-reboot fest.

In den folgenden Beispielen werden Replikationsfilter festgelegt:

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-do-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-do-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-wild-do-table", "ParameterValue": "my\_table%", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-ignore-db", "ParameterValue": "mydb1,mydb2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-ignore-table", "ParameterValue": "mydb1.table1,mydb1.table2", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group \
  --db-parameter-group-name myparametergroup \
  --parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

aws rds modify-db-parameter-group ^
  --db-parameter-group-name myparametergroup ^
  --parameters "[{"ParameterName": "replicate-wild-ignore-table", "ParameterValue": "mydb.orders%,mydb.returns%", "ApplyMethod":"immediate"}]"

Anzeigen der Replikationsfilter für ein Lesereplikat

Sie können die Replikationsfilter für ein Lesereplikat wie folgt anzeigen:

Konfigurieren der verzögerten Replikation mit MariaDB

Sie können die verzögerte Replikation als Strategie für die Notfallwiederherstellung einsetzen. Für die verzögerte Replikation geben Sie die Mindestanzahl von Sekunden an, um welche die Replikation von der Quelle in das Lesereplikat verzögert werden soll. Wenn es zu einem Notfall kommt, weil beispielsweise eine Tabelle versehentlich gelöscht wurde, können Sie das Problem mit den folgenden Schritten schnell beheben:

Konfigurieren der verzögerten Replikation während der Erstellung von Read Replicas

Um die verzögerte Replikation für zukünftig aus einer DB-Instance erstellte Lesereplikate zu konfigurieren, führen Sie die gespeicherte Prozedur mysql.rds_set_configuration mit dem Parameter target delay aus.

Ändern der verzögerten Replikation einer vorhandenen Read Replica

Führen Sie die gespeicherte Prozedur mysql.rds_set_source_delay aus, um die verzögerte Replikation eines vorhandenen Lesereplikats zu ändern.

Hochstufen eines Lesereplikats

Nachdem die Replikation gestoppt wurde, können Sie in einem Szenario der Notfallwiederherstellung ein Lesereplikat zur neuen Quell-DB-Instance hochstufen. Weitere Informationen zum Hochstufen eines Lesereplikats finden Sie unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance.

Löschen von Lesereplikaten bei MariaDB

Lesereplikate wurden zur Unterstützung von Leseabfragen entwickelt. Jedoch könnten gelegentliche Updates notwendig sein. Sie könnten beispielsweise einen Index hinzufügen, um die spezifischen Abfragetypen beim Zugriff auf das Replica zu beschleunigen. Sie können Updates aktivieren, indem Sie den Parameter read_only in der DB-Parametergruppe für das Lesereplikat auf 0 setzen.

Arbeiten mit Bereitstellungen von Multi-AZ-Lesereplikaten mit MariaDB

Sie können ein Lesereplikat aus Single-AZ- oder Multi-AZ-DB-Instance-Bereitstellungen erstellen. Sie können Multi-AZ-Bereitstellungen verwenden, um die Haltbarkeit und Verfügbarkeit kritischer Daten zu verbessern, aber Sie können Multi-AZ nicht zweitranging noch für schreibgeschützte Abfragen verwenden. Stattdessen können Sie Lesereplikate aus Multi-AZ-DB-Instances mit hohem Datenverkehr erstellen, um schreibgeschützte Abfragen auslagern zu können. Wenn die Quell-Instance einer Multi-AZ-Bereitstellung ein Failover zur sekundären Instance durchführt, werden alle zugehörigen Lesereplikate automatisch auf die Verwendung der sekundären (jetzt primären) Instance als Replikationsquelle umgeschaltet. Weitere Informationen finden Sie unter Konfiguration und Verwaltung einer Multi-AZ-Bereitstellung.

Sie können ein Lesereplikat als Multi-AZ-DB-Instance erstellen. Amazon RDS erstellt eine Standby-Version des Replikats in einer anderen Availability Zone, um ein Failover für das Replikat zu unterstützen. Das Erstellen Ihres Lesereplikats als Multi-AZ-DB-Instance ist unabhängig davon, ob die Quelldatenbank eine Multi-AZ-DB-Instance ist.

Verwendung von kaskadierenden Lesereplikaten mit RDS für MariaDB

RDS für MariaDB unterstützt kaskadierende Lesereplikate. Mit kaskadierenden Lesereplikaten können Sie Lesevorgänge skalieren, ohne dass Sie zusätzlichen Overhead für Ihre Quell-DB-Instance von RDS für MariaDB verursachen.

Bei kaskadierenden Lesereplikaten sendet Ihre DB-Instance von RDS für MariaDB Daten an das erste Lesereplikat in der Kette. Dieses Lesereplikat sendet dann Daten an das zweite Replikat in der Kette usw. Das Endergebnis ist, dass alle Lesereplikate in der Kette die Änderungen von der DB-Instance von RDS für MariaDB aufweisen, jedoch ohne Overhead ausschließlich auf der Quell-DB-Instance zu verursachen.

Sie können eine Reihe von bis zu drei Lesereplikaten in einer Kette von einer Quell-DB-Instance von RDS für MariaDB erstellen. Angenommen, Sie haben eine DB-Instance von RDS für MariaDB, mariadb-main. Sie haben die folgenden Möglichkeiten:

Sie können kein weiteres Lesereplikat über dieses dritte kaskadierende Lesereplikat hinaus in der Reihe für mariadb-main erstellen. Eine vollständige Reihe von Instances aus einer Quell-DB-Instance von RDS für MariaDB bis zum Ende einer Reihe kaskadierender Lesereplikate kann aus höchstens vier DB-Instances bestehen.

Damit die Kaskadierung von Lesereplikaten funktioniert, müssen automatische Backups für jede Quell-DB-Instance von RDS für MariaDB aktiviert sein. Erstellen Sie zuerst das Lesereplikat und ändern Sie es dann, um automatische Backups für das Lesereplikat für zu aktivieren. Weitere Informationen finden Sie unter Erstellen eines Lesereplikats.

Wie bei jedem Lesereplikat können Sie ein Lesereplikat, das Teil einer Kaskade ist, hochstufen. Wenn Sie ein Lesereplikat aus einer Kette von Lesereplikaten hochstufen, wird dieses Replikat aus der Kette entfernt. Angenommen, Sie möchten einen Teil der Workload von Ihrer mariadb-main-DB-Instance zu einer neuen Instance verschieben, die nur von der Buchhaltung verwendet wird. Ausgehend von der Kette von drei Lesereplikaten aus dem Beispiel entscheiden Sie sich, read-replica-2 hochzustufen. Die Kette ist wie folgt betroffen:

Weitere Informationen über das Hochstufen von Lesereplikaten finden Sie unter Hochstufen eines Lesereplikats zur eigenständigen DB-Instance.

Überwachung von MariaDB Read Replicas

Für MariaDB-Lesereplikate können Sie die Replikationsverzögerung in Amazon überwachen, CloudWatch indem Sie die Amazon-RDS-ReplicaLagMetrik anzeigen. Die Kennzahl ReplicaLag meldet den Wert des Feldes Seconds_Behind_Master des Befehls SHOW REPLICA STATUS.

Häufige Ursachen für Replikationsverzögerung in MariaDB:

Wenn die Metrik ReplicaLag 0 erreicht, hat das Replica den Stand der Quell-DB-Instance erreicht. Wenn die Metrik ReplicaLag -1 zurückgibt, ist die Replikation aktuell nicht aktiv. ReplicaLag = -1 ist gleich Seconds_Behind_Master = NULL.

Starten und Stoppen der Replikation mit MariaDB Read Replicas

Sie können den Replikationsvorgang für eine Amazon RDS-DB-Instance anhalten oder neustarten, indem Sie die gespeicherten Systemprozeduren mysql.rds_stop_replication und mysql.rds_start_replication aufrufen. Dies können Sie tun, wenn Sie eine Replikation zwischen Amazon RDS-Instances für langandauernde Operationen, wie dem Erstellen von großen Indexen, durchführen. Sie müssen Replikation auch anhalten und starten, wenn Sie Datenbanken importieren oder exportieren. Weitere Informationen erhalten Sie unter Importieren von Daten in eine Amazon-RDS-MariaDB- oder MySQL-Datenbank mit reduzierter Ausfallzeit und Exportieren von Daten aus einer MySQL DB-Instance mithilfe der Replikation.

Wenn eine Replikation für mehr als 30 aufeinanderfolgende Tage manuell oder aufgrund eines Replikationsfehlers gestoppt wird, beendet Amazon RDS die Replikation zwischen der Quell-DB-Instance und allen Lesereplikaten. um erhöhten Speicheranforderungen in der Quell-DB-Instance vorzubeugen und lange Failover-Zeiten zu vermeiden. Die Lesereplikat-DB-Instance ist weiterhin verfügbar. Die Replikation kann jedoch nicht fortgesetzt werden, da die vom Lesereplikat benötigten Binärprotokolle aus der Quell-DB-Instance nach Beendigung der Replikation gelöscht wurden. Sie können ein neues Lesereplikat für die Quell-DB-Instance erstellen, um die Replikation erneut aufzunehmen.

Fehlerbehebung bei Problemen mit einer MariaDB Read Replica

Die Replikationstechnologien für MariaDB arbeiten asynchron. Da sie asynchron sind, steigt gelegentlich BinLogDiskUsage in der Quell-DB-Instance an und ReplicaLag ist im Lesereplikat zu erwarten. Beispielsweise kann auf der Quell-DB-Instance eine große Anzahl von Schreibvorgängen gleichzeitig ausgeführt werden. Dagegen werden Schreibvorgänge zum Lesereplikat über einen einzigen I/O-Thread seriell abgearbeitet. Dies kann zu einer Verzögerung zwischen der Quell-DB-Instance und dem Lesereplikat führen. Weitere Informationen über schreibgeschützte Replikate in der MariaDB-Dokumentation finden Sie unter Replikation - Übersicht.

Sie können folgende Dinge tun, um die Verzögerungszeit zwischen Aktualisierungen einer Quell-DB-Instance und der nachfolgenden Aktualisierung des Lesereplikats zu reduzieren:

Amazon RDS überwacht den Replikationsstatus Ihrer Lesereplikate und setzt den Replication State der Lesereplikat-Instance auf Error, wenn die Replikation aus irgendeinem Grund beendet wird. Ein Beispiel wären auf Ihrem Lesereplikat ausgeführte DML-Abfragen, die mit den Aktualisierungen auf der Quell-DB-Instance in Konflikt treten.

Sie können die Details des von der MariaDB-Engine zurückgegebenen Fehlers im Feld Replication Error überprüfen. Ereignisse, die den Status des Lesereplikats angeben, werden ebenfalls generiert, einschließlich RDS-EVENT-0045, RDS-EVENT-0046 und RDS-EVENT-0047. Weitere Informationen über Ereignisse und Abonnements zu Ereignissen finden Sie unter Mit RDS Amazon-Event-Benachrichtigungen arbeiten. Wenn eine MariaDB-Fehlermeldung zurückgegeben wird, überprüfen Sie den Fehler in der MariaDB error message documentation.

Ein häufiges Problem, das Replikationsfehler verursachen kann, besteht, wenn der Wert für den max_allowed_packet-Parameter eines Lesereplikats niedriger ist als der Wert für den max_allowed_packet-Parameter der Quell-DB-Instance. Der max_allowed_packet-Parameter ist ein benutzerdefinierter Parameter, den Sie in einer DB-Parametergruppe festlegen können, mit der die maximale Größe des auf der Datenbank ausführbaren DML-Codes angegeben wird. In einigen Fällen ist der Parameterwert max_allowed_packet in der mit einer Quell-DB-Instance verknüpften DB-Parametergruppe kleiner als der Parameterwert max_allowed_packet in der mit dem Lesereplikat der Quelle verknüpften DB-Parametergruppe. In diesen Fällen kann der Replikationsvorgang einen Fehler zurückgeben (Paket größer als "max_allowed_packet" Bytes) und die Replikation anhalten. Sie können den Fehler beheben, indem Sie die DB-Parametergruppe der Quelle und des Lesereplikats mit denselben Parameterwerten für max_allowed_packet verwenden.

Weitere Situationen, bei denen Replikationsfehler auftreten können, sind die Folgenden:

Wenn Sie entscheiden, dass Sie einen Fehler problemlos überspringen können, folgen Sie den Schritten in Überspringen von Fehlern für die aktuelle Replikation. Andernfalls können Sie das Lesereplikat löschen und eine Instance mit derselben DB-Instance-Kennung erstellen, sodass der Endpunkt mit dem alten Lesereplikat übereinstimmt. Wird ein Replikationsfehler behoben, ändert sich das Feld Replication State zu Replicating.

Bei MariaDB-DB-Instances kann in manchen Fällen nicht auf sekundäre Lesereplikate umgestellt werden, wenn während des Fehlers nicht alle Binärprotokollereignisse (binlog) bereinigt wurden. In diesen Fällen müssen Sie die Lesereplikate manuell löschen und neu erstellen. Sie können das Risiko minimieren, indem Sie die folgenden Parameterwerte einstellen: sync_binlog=1 und innodb_flush_log_at_trx_commit=1. Diese Einstellungen könnten die Leistung reduzieren, daher ist es ratsam, sie vor der Implementierung in einer Produktionsumgebung ausgiebig zu testen.