Amazon DocumentDB — Hochverfügbarkeit und Replikation

Sie können in Amazon DocumentDB (mit MongoDB-Kompatibilität) eine hohe Verfügbarkeit und Leseskalierung erreichen, indem Sie Replikat-Instances verwenden. Ein einzelner Amazon DocumentDB-Cluster unterstützt eine einzelne primäre Instance und bis zu 15 Replica-Instances. Diese Instances können über mehrere Availability Zones innerhalb der Cluster-Region verteilt werden. Die primäre Instance akzeptiert Lese- und Schreibverkehr, und Replikat-Instances akzeptieren nur Leseanforderungen.

Das Cluster-Volume besteht aus mehreren Kopien der Daten für den Cluster. Die Daten im Cluster-Volume werden jedoch als ein einziges, logisches Volume für die primäre Instance und die Amazon DocumentDB-Repliken im Cluster dargestellt. Replikat-Instances sind „Eventually Consistent“. Sie geben Abfrageergebnisse mit minimaler Replikatverzögerung zurück – im Normalfall beträgt die Verzögerung weniger als 100 Millisekunden, nachdem die primäre Instance eine Aktualisierung geschrieben hat. Die Replica-Verzögerung variiert in Abhängigkeit vom Veränderungsgrad in der Datenbank. Das heißt, in Zeiten, in denen eine große Anzahl von Schreiboperationen für die Datenbank durchgeführt wird, kann es zu einer Erhöhung der Replikationsverzögerung kommen.

Skalierung von Lesevorgängen

Amazon DocumentDB-Replikate eignen sich gut für die Skalierung von Lesevorgängen, da sie vollständig für Lesevorgänge auf Ihrem Cluster-Volume vorgesehen sind. Schreibvorgänge werden von der primären Instance verwaltet. Das Cluster-Volume wird von allen Instances in Ihrem Cluster gemeinsam genutzt. Daher müssen Sie nicht für jedes Amazon DocumentDB-Replikat eine Kopie der Daten replizieren und verwalten.

Hohe Verfügbarkeit

Wenn Sie einen Amazon DocumentDB-Cluster erstellen, stellt Amazon DocumentDB je nach Anzahl der Availability Zones in der Subnetzgruppe (es müssen mindestens zwei sein) Instances über die Availability Zones hinweg bereit. Wenn Sie Instances im Cluster erstellen, verteilt Amazon DocumentDB die Instances automatisch auf die Availability Zones in einer Subnetzgruppe, um den Cluster auszugleichen. Diese Vorgehensweise verhindert auch, dass sich alle Instances in derselben Availability Zone befinden.

Beispiel

Zur Veranschaulichung nehmen wir ein Beispiel, in dem ein Cluster erstellt wird, das eine Subnetzgruppe mit drei Availability Zones hat AZ1, AZ2 und AZ3.

Wenn die erste Instance im Cluster erstellt wird, ist diese die primäre Instance und befindet sich in einer der Availability Zones. In diesem Beispiel handelt es sich um AZ1. Die zweite erstellte Instance ist eine Replikat-Instance und befindet sich in einer der beiden anderen Availability Zones, z.B. AZ2. Die dritte Instance, die erstellt wird, ist eine Replikat-Instance und befindet sich in der verbleibenden Availability ZoneAZ3. Wenn Sie mehrere Instances erstellen, werden diese über die Availability Zones verteilt, sodass der Cluster ausbalanciert ist.

Tritt in der primären Instance (AZ1) ein Fehler auf, wird ein Failover ausgelöst und eine der bestehenden Replikat-Instances wird zur primären Instance heraufgestuft. Wenn die alten primäre Instance wiederhergestellt wurde, wird sie zu einem Replikat in der gleichen Availability Zone, in der sie bereitgestellt wurde (AZ1). Wenn Sie einen Cluster mit drei Instanzen bereitstellen, behält Amazon DocumentDB diesen Cluster mit drei Instanzen weiterhin bei. Amazon DocumentDB kümmert sich automatisch um die Erkennung, den Failover und die Wiederherstellung von Instance-Ausfällen, ohne dass ein manuelles Eingreifen erforderlich ist.

Wenn Amazon DocumentDB einen Failover durchführt und eine Instance wiederherstellt, verbleibt die wiederhergestellte Instance in der Availability Zone, in der sie ursprünglich bereitgestellt wurde. Die Rolle der Instance ändert sich möglicherweise von der primären Instance zum Replikat. Dadurch wird ein Szenario verhindert, in dem eine Reihe von Failovers in allen Instances auftreten könnten, die sich in derselben Availability Zone befinden.

Sie können Amazon DocumentDB-Repliken als Failover-Ziele angeben. Das heißt, wenn die primäre Instance ausfällt, wird das angegebene Amazon DocumentDB-Replikat oder das Replikat einer Stufe zur primären Instance hochgestuft. Es gibt dann eine kurze Unterbrechung, während der Lese- und Schreibanfragen an die primäre Instance mit einer Ausnahme fehlschlagen. Wenn Ihr Amazon DocumentDB-Cluster keine Amazon DocumentDB-Replikate enthält, wird die primäre Instance neu erstellt, wenn sie ausfällt. Das Heraufstufen einer Amazon DocumentDB-Replica ist viel schneller als die Neuerstellung der primären Instance.

Für eine hohe Verfügbarkeit erstellen Sie eine oder mehrere Amazon DocumentDB-Repliken derselben Instance-Klasse wie die primäre Instance in verschiedenen Availability Zones.

Weitere Informationen finden Sie hier:

• Grundlegendes zur Amazon DocumentDB-Cluster-Fehlertoleranz

• Amazon DocumentDB-Failover

  • Steuerung des Failover-Ziels

In den Amazon DocumentDB-Versionen 5.0 und 8.0 werden Replikat-Instances nicht neu gestartet, wenn die primäre Instance neu gestartet wird. Sie bearbeiten weiterhin Leseanforderungen bei Neustarts der primären Instance und sorgen so für eine verbesserte Verfügbarkeit.

Hohe Verfügbarkeit mit globalen Clustern

Für eine hohe Verfügbarkeit über mehrere AWS-Regionen hinweg können Sie globale Amazon DocumentDB-Cluster einrichten. Jeder globale Cluster erstreckt sich über mehrere Regionen und ermöglicht so globale Lesevorgänge mit niedriger Latenz und die Notfallwiederherstellung nach Ausfällen in verschiedenen Regionen. Amazon DocumentDB übernimmt automatisch die Replikation aller Daten und Aktualisierungen von der primären Region in jede der sekundären Regionen.

Hinzufügen von -Replicas

Die erste dem Cluster hinzugefügte Instance ist die primäre Instance. Jede Instance, die nach der ersten Instance hinzugefügt wird, ist eine Replikat-Instance. Ein Cluster kann zusätzlich zur primären Instanz über bis zu 15 Replikat-Instances verfügen.

Wenn Sie einen Cluster mithilfe von erstellen AWS-Managementkonsole, wird gleichzeitig automatisch eine primäre Instanz erstellt. Um ein Replikat gleichzeitig mit der Erstellung des Clusters und der primären Instance zu erstellen, wählen Sie Create replica in different zone (Replikat in unterschiedlicher Zone erstellen) aus. Weitere Informationen finden Sie in Schritt 4.d unter Erstellen eines Amazon DocumentDB-Clusters. Informationen zum Hinzufügen weiterer Replikate zu einem Amazon DocumentDB-Cluster finden Sie unter. Hinzufügen einer Amazon DocumentDB DocumentDB-Instance zu einem Cluster

Wenn Sie den verwenden AWS CLI , um Ihren Cluster zu erstellen, müssen Sie Ihre Primär- und Replikat-Instances explizit erstellen. Weitere Informationen finden Sie im Abschnitt „Verwenden des AWS CLI“ in den folgenden Themen:

• Erstellen eines Amazon DocumentDB-Clusters

• Hinzufügen einer Amazon DocumentDB DocumentDB-Instance zu einem Cluster

Replikationsverzögerung

Die Replikationsverzögerung beträgt in der Regel 50 ms oder weniger. Die häufigsten Gründe für eine erhöhte Replikatverzögerung sind:

• Eine hohe Schreibrate auf der Primärseite, die dazu führt, dass die Lesereplikate hinter die Primärreplikate zurückfallen.

• Konflikt bei den Lesereplikaten zwischen lang andauernden Abfragen (z. B. große sequentielle Scans, Aggregationsabfragen) und eingehenden Schreibreplikationen.

• Sehr große Anzahl gleichzeitiger Abfragen auf den Lesereplikaten.

Probieren Sie die folgenden Techniken zur Problembehandlung aus, um die Verzögerung bei der Replikation zu minimieren:

• Wenn Sie eine hohe Schreibrate oder eine hohe CPU-Auslastung haben, skalieren Sie die Instances in Ihrem Cluster.

• Wenn lange Abfragen auf Ihren Lesereplikaten laufen und die abgefragten Dokumente sehr häufig aktualisiert werden, sollten Sie erwägen, Ihre Abfragen mit langer Laufzeit zu ändern oder sie für das Replikat auszuführen, um Konflikte bei den primary/write Read Replicas zu vermeiden.

• Wenn es eine sehr große Anzahl gleichzeitiger Abfragen oder eine hohe CPU-Auslastung nur für die Read Replicas gibt, besteht eine andere Möglichkeit darin, die Anzahl der Read Replicas zu skalieren, um die Arbeitslast zu verteilen.

• Da Replikationsverzögerungen auf einen hohen Schreibdurchsatz und lang andauernde Abfragen zurückzuführen sind, sollten Sie die Replikationsverzögerung mithilfe der DBClusterReplicaLagMaximum CloudWatch Metrik in Kombination mit dem langsamen Abfrage-Logger und den /-Metriken beheben. WriteThroughput WriteIOPS

Stellen Sie sicher, dass alle Ihre Replikate vom gleichen Instance-Typ sind, damit ein Cluster-Failover nicht zu Leistungseinbußen führt.

Wenn Sie zwischen Hochskalierung und Out-Skalierung wählen (z. B. sechs kleinere Instances gegenüber drei größeren Instances), empfehlen wir generell, vor dem Scale-Out zuerst eine Hochskalierung durchzuführen (größere Instances), da Sie so einen größeren Puffer-Cache pro DB-Instance erhalten.

Proaktiv sollten Sie einen Alarm für Replikationsverzögerungen einrichten und dessen Schwellenwert auf einen Wert setzen, der Ihrer Meinung nach die Obergrenze dafür ist, wie weit Ihre Daten auf Replikat-Instances zurückliegen (oder „veraltet“) sein können, bevor die Funktionalität Ihrer Anwendung beeinträchtigt wird. Im Allgemeinen empfehlen wir, den Schwellenwert für die Replikationsverzögerung aufgrund vorübergehender Arbeitslasten für mehrere Datenpunkte zu überschreiten, bevor ein Alarm ausgelöst wird.

Anmerkung

Stellen Sie einen weiteren Alarm für Replikationsverzögerungen ein, die 10 Sekunden überschreiten. Wenn Sie diesen Schwellenwert für mehrere Datenpunkte überschreiten, skalieren Sie Ihre Instances oder reduzieren Sie Ihren Schreibdurchsatz auf der primären Instance.