Neustarten eines Aurora-Clusters mit Leseverfügbarkeit
Mit der Funktion zur Leseverfügbarkeit können Sie die Writer-Instance Ihres Aurora-Clusters neu starten, ohne die Reader-Instances im primären oder sekundären DB-Cluster neu starten zu müssen. Dies kann dazu beitragen, die hohe Verfügbarkeit des Clusters für Lesevorgänge aufrechtzuerhalten, während Sie die Writer-Instance neu starten. Sie können die Reader-Instances später nach einem für Sie geeigneten Zeitplan neu starten. Beispielsweise können Sie für einen Produktions-Cluster die Reader-Instances nacheinander neu starten und erst beginnen, nachdem der Neustart der primären Instance abgeschlossen ist. Folgen Sie für jede DB-Instance, die Sie neu starten, dem Verfahren unter Neustarten einer DB-Instance in einem Aurora Cluster.
Die Funktion der Leseverfügbarkeit für primäre DB-Cluster ist in Aurora MySQL 2.10 und höher verfügbar. Die Leseverfügbarkeit für sekundäre DB-Cluster ist in Aurora-MySQL-Version 3.06 und höher verfügbar.
Diese Funktion steht standardmäßig für die folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
15.2 und höhere 15-Versionen
14.7 und höhere 14-Versionen
13.10 und höhere 13-Versionen
12.14 und höhere 12-Versionen
Weitere Informationen zur Leseverfügbarkeitsfunktion in Aurora PostgreSQL finden Sie unter Verbesserung der Leseverfügbarkeit von Aurora Replicas.
Vor der Einführung dieser Funktion verursachte der Neustart der primären Instance gleichzeitig einen Neustart für jede Reader-Instance. Wenn auf Ihrem Aurora-Cluster eine ältere Version ausgeführt wird, verwenden Sie stattdessen das Neustartverfahren in Neustart eines Aurora-Clusters ohne Leseverfügbarkeit.
Anmerkung
Die Änderung des Neustartverhaltens in Aurora-DB-Cluster mit Leseverfügbarkeit ist bei globalen Aurora-Datenbanken in Aurora-MySQL-Versionen niedriger als 3.06 anders. Wenn Sie die Writer-Instance für den primären Cluster in einer globalen Aurora-Datenbank neu starten, bleiben die Reader-Instances im primären Cluster verfügbar. Die DB-Instances in sekundären Clustern werden jedoch gleichzeitig neu gestartet.
Eine eingeschränkte Version der verbesserten Leseverfügbarkeitsfunktion wird von globalen Aurora-Datenbanken für die Aurora-PostgreSQL-Versionen 12.16, 13.12, 14.9, 15.4 und höher unterstützt.
Sie starten den Cluster häufig neu, nachdem Sie Änderungen an Clusterparametergruppen vorgenommen haben. Sie nehmen Parameteränderungen vor, indem Sie die Verfahren in befolge Parametergruppen für Amazon Aurora. Angenommen, Sie starten die Writer-DB-Instance in einem Aurora-Cluster neu, um Änderungen an Cluster-Parametern anzuwenden. Einige oder alle Reader-DB-Instances verwenden möglicherweise weiterhin die alten Parametereinstellungen. Die verschiedenen Parametereinstellungen haben jedoch keinen Einfluss auf die Datenintegrität des Clusters. Alle Clusterparameter, die sich auf die Organisation von Datendateien auswirken, werden nur von der Writer-DB-Instance verwendet.
Beispielsweise können Sie in einem Aurora-MySQL-Cluster Cluster-Parameter wie binlog_format und innodb_purge_threads auf der Writer-Instance vor den Reader-Instances aktualisieren. Nur die Writer-Instance schreibt binäre Protokolle und löscht Datensätze für das Rückgängigmachen. Bei Parametern, die die Interpretation von SQL-Anweisungen oder Abfrageausgaben ändern, müssen Sie möglicherweise darauf achten, die Reader-Instances sofort neu zu starten. Sie tun dies, um unerwartetes Anwendungsverhalten bei Abfragen zu vermeiden. Angenommen, Sie ändern den lower_case_table_names Parameter und starten die Writer-Instance neu. In diesem Fall können die Reader-Instances möglicherweise erst auf eine neu erstellte Tabelle zugreifen, wenn sie alle neu gestartet wurden.
Eine Liste aller Aurora MySQL Clusterparameter finden Sie unter Parameter auf Cluster-Ebene.
Eine Liste aller Cluster-Parameter von Aurora PostgreSQL finden Sie unter Aurora-PostgreSQL-Parameter auf Cluster-Ebene.
Tipp
Aurora MySQL startet möglicherweise noch einige der Reader-Instances zusammen mit der Writer-Instance neu, wenn Ihr Cluster einen Workload mit hohem Durchsatz verarbeitet.
Die Verringerung der Anzahl der Neustarts gilt auch während des Failovervorgangs. Aurora MySQL startet nur die Writer-DB-Instance und das Failover-Ziel während eines Failovers neu. Andere Reader-DB-Instances im Cluster bleiben verfügbar, um Abfragen über Verbindungen zum Reader-Endpunkt fortzusetzen. So können Sie die Verfügbarkeit während eines Failovers verbessern, indem Sie mehr als eine Reader-DB-Instance in einem Cluster haben.
