Lesereplikat - Überblick
Lesereplikate sind schreibgeschützte Kopien der primären MySQL-Instanz des DB-Systems innerhalb derselben Region. Sie bieten Skalierbarkeit und höhere Performance für leseintensive Workloads. Sie skalieren Lesevorgänge, d.h. reduzieren die Abfragelatenz.
Lesereplikat wird in einem DB-System vom Typ "Immer kostenlos" nicht unterstützt.
Lesereplikate werden beim Starten eines DB-Systems gestartet, beim Stoppen des DB-Systems gestoppt und beim Löschen des DB-Systems gelöscht. Jedes Lesereplikat wird automatisch mithilfe der asynchronen Replikation aktualisiert. Sie können Lesereplikate auf einem Standalone- oder High Availability-DB-System erstellen. Lesereplikate werden auf Ausprägungen mit weniger als 8 ECPUs oder weniger als 4 OCPUs nicht unterstützt.
In einem DB-System können Sie maximal 18 Lesereplikate erstellen. Jedes Lesereplikat hat einen eigenen Endpunkt. Beispiel: Wenn Sie fünf Lesereplikate haben, haben Sie fünf Endpunkte, einen Endpunkt für jedes Lesereplikat. Wenn Sie eine Teilmenge von Abfragen für die primäre Instanz ausführen und auf den Lesereplikaten basieren möchten, müssen Sie die Anwendung so konfigurieren, dass sie die entsprechenden Endpunkte verwendet.
Sie können eine Verbindung zu einem Lesereplikat auf ähnliche Weise herstellen wie eine Verbindung zu einem DB-System - mit einer Compute-Instanz, Bastion-Session oder einem VPN. Siehe Verbindung zu einem DB-System herstellen.
Die Lesereplikate können hinter der primären Instanz zurückbleiben. Dieser wird mit der read replica lag-Metrik gemessen. Je nach Workload der einzelnen Lesereplikate können die Lesereplikate eine andere Verzögerung aufweisen. Auch wenn die Arbeitslast identisch ist, können Lesereplikate je nach Ressourcen wie CPU und Arbeitsspeicher eine andere Verzögerung bei Lesereplikaten aufweisen. Sie können Alarme erstellen, um die Metrik zu überwachen und Sie zu benachrichtigen, wenn Metriken Alarm-spezifische Trigger erfüllen. Siehe Alarme mit Metriken erstellen.
MySQL HeatWave Service führt ein automatisches Recovery für alle ausgefallenen Lesereplikate durch. Während des Recoverys wird das Lesereplikat auf den Status Updating gesetzt, und es kann keine Clientverbindungen akzeptieren. Nachdem das Recovery erfolgreich war, wird das Lesereplikat auf den Status Active gesetzt und wird betriebsbereit. Wenn ein Lesereplikat nach dem Recovery nicht erfolgreich war und nicht mehr aus dem DB-System repliziert werden kann, wird das Lesereplikat auf den Status Needs Attention gesetzt. In diesem Fall müssen Sie das Lesereplikat löschen und ein neues erstellen.
Wenn Sie die Accountdefinitionen und ihre Berechtigungen (wie das Kennwort) im verknüpften DB-System ändern, werden die Änderungen an die Lesereplikate propagiert. Sie müssen das Kennwort nicht bei jedem Lesereplikat ändern.
Sie können ein Lesereplikat nicht als Quellserver einer ausgehenden Replikation konfigurieren. Sie können nur ein DB-System als Quellserver konfigurieren.
Ein Lesereplikat erbt das Sicherheitszertifikat des verknüpften DB-Systems. Sie können das Sicherheitszertifikat des Lesereplikats nicht aktualisieren.
Übernehmen und überschreiben
Standardmäßig erbt ein Lesereplikat die Ausprägung, Konfiguration und Version aus dem DB-System. Sie können diese Eigenschaften in einem Lesereplikat außer Kraft setzen, um ein Lesereplikat mit einer anderen Ausprägung, Konfiguration oder Version als im DB-System zu erstellen. Wenn ein Lesereplikat eine Eigenschaft vom DB-System erbt, ändert die Änderung der Eigenschaft im DB-System auch die Eigenschaft im Lesereplikat in denselben Wert. Wenn ein Lesereplikat eine Eigenschaft aus dem DB-System außer Kraft setzt, wirkt sich das Ändern der Eigenschaft im DB-System nicht auf die Eigenschaft des Lesereplikats aus.
Read Replica Load Balancer
Wenn Sie das erste Lesereplikat eines DB-Systems erstellen, wird automatisch ein Load Balancer für Lesereplikate erstellt, der den Lesetraffic auf die Lesereplikate verteilt. Alle Lesereplikate desselben DB-Systems werden dem Load Balancer als Backend hinzugefügt. Wenn die Erstellung des Lesereplikat-Load-Balancers aus irgendeinem Grund nicht erfolgreich verläuft, wird das Lesereplikat nicht erstellt. Ein Read Replica Load Balancer wird nur gelöscht, wenn Sie das zugehörige DB-System löschen.
- Replica Load Balancer Policy lesen: Die Load Balancing Distribution Policy des Load Balancers basiert auf einem 5-Tupel-Hash der Quell- und Ziel-IP-Adresse, des Ports und der IP-Protokollinformationen. Diese 5-Tupel-Hash-Policy stellt die Session-Affinität innerhalb einer bestimmten TCP- oder UDP-Session bereit, bei der Pakete in derselben Session an denselben Backend-Server hinter dem Network Load Balancer geleitet werden.
Der Load Balancer des Lesereplikats verteilt Verbindungen auf alle aktiven Lesereplikate. Verschiedene Verbindungen können an verschiedene Lesereplikate verteilt werden, aber alle von derselben Verbindung ausgegebenen Abfragen werden immer an dasselbe Lesereplikat weitergeleitet.
- Timeout bei Inaktivität von Verbindungen: Der Load Balancer verfolgt den Status aller TCP-Datenflüsse, die ihn passieren. Eine Kombination aus IP-Protokoll und Quell- und Ziel-IP-Adressen und -ports definiert einen Datenfluss. Der Datenfluss kann entfernt werden, wenn weder der Client noch der Server für einen längeren Zeitraum als der Inaktivitätstimeout Traffic empfängt. Alle TCP-Pakete, die nach dem Inaktivitätstimeout empfangen werden, werden gelöscht. Die Dauer des Inaktivitätstimeouts für TCP-Abläufe beträgt acht Stunden. Sie können die Dauer des Inaktivitätstimeouts nicht ändern. Wenn die Verbindung derzeit nicht verwendet wird und Sie die Verbindung am Leben erhalten möchten, setzen Sie TCP keep-alive auf dem Client, der die TCP keep-alive-Pakete sendet, um die Verbindung am Leben zu erhalten.
Hinweis
Alle Read Replica Load Balancer, die vor dem 10. Oktober 2023 erstellt wurden, weisen einen standardmäßigen Inaktivitätstimeout von sechs Minuten auf. Wenn Sie den Leerlaufzeit-Timeout auf acht Stunden erhöhen möchten, wenden Sie sich an Oracle Support.
- Status "Nicht erfolgreich" oder "Aktion erforderlich": Wenn das Lesereplikat den Status "Nicht erfolgreich" oder "Aktion erforderlich" aufweist, entfernt der Load Balancer das Lesereplikat aus dem Backend.
- Inaktiver Status: Wenn das Lesereplikat inaktiv ist, leitet der Load Balancer keinen Traffic daran weiter.
- Aktiver Status: Wenn sich das Lesereplikat im aktiven Status befindet, leitet der Load Balancer Traffic an dieses weiter.
IP-Adressanforderungen
- Einer für den DB-Systemendpunkt. Verbindungen, die mit diesem Endpunkt hergestellt werden, können sowohl Lese- als auch Schreibvorgänge ausführen. Die Lesevorgänge geben immer aktuelle Daten zurück.
- 18 für die 18 Read Replica Endpunkte. Verbindungen, die mit einem dieser Endpunkte hergestellt werden, können schreibgeschützte Vorgänge ausführen. Die Lesevorgänge können je nach Replikationsverzögerung etwas veraltete Daten zurückgeben.
- Eine für den Lesereplikat-Load-Balancer-Endpunkt. An diesem Endpunkt hergestellte Verbindungen werden über aktive Lesereplikate verteilt.
Verwandte Themen