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.
# Neustart eines Amazon Aurora DB-Clusters oder einer Amazon Aurora DB-Instance
Möglicherweise müssen Sie Ihren DB-Cluster oder einige Instances innerhalb des Clusters neu starten, normalerweise aus Wartungsgründen. Angenommen, Sie ändern die Parameter innerhalb einer Parametergruppe oder ordnen Ihrem Cluster eine andere Parametergruppe zu. In diesen Fällen müssen Sie den Cluster neu starten, damit die Änderungen wirksam werden. In ähnlicher Weise können Sie eine oder mehrere Reader-DB-Instances innerhalb des Clusters neu starten. Sie können die Neustartvorgänge für einzelne Instances anordnen, um Ausfallzeiten für den gesamten Cluster zu minimieren.
Die für den Neustart der einzelnen DB-Instances in Ihrem Cluster erforderliche Zeit hängt von der Datenbankaktivität zum Zeitpunkt des Neustarts ab. Dies hängt auch vom Wiederherstellungsprozess Ihrer spezifischen DB-Engine ab. Wenn dies praktisch ist, reduzieren Sie die Datenbankaktivität auf dieser bestimmten Instance, bevor Sie den Neustartvorgang starten. Dadurch kann die zum Neustart der Datenbank erforderliche Zeit verkürzt werden.
Sie können jede DB-Instance in Ihrem Cluster nur neu starten, wenn sie sich im verfügbaren Status befindet. Eine DB-Instance kann aus mehreren Gründen nicht verfügbar sein. Dazu gehören der Status der gestoppten Cluster, eine Änderung, die auf die Instance angewendet wird und eine Wartungsfensteraktion, sowie ein Versionsupgrade.
Beim Neustart einer DB-Instance wird der Datenbank-Engine-Prozess neu gestartet. Das Neustarten einer DB-Instance bewirkt einen vorübergehenden Nutzungsausfall, wobei der Status für diese Instance währenddessen auf *Wird neu gestartet …* gesetzt wird.
**Anmerkung**
Wenn auf der DB-Instance noch nicht die neuesten Änderungen der zugeordneten DB-Parametergruppe übernommen wurden, gibt die AWS-Managementkonsole für diese DB-Parametergruppe den Status **pending-reboot (Neustart ausstehend)** an. Die Parametergruppe **pending-reboot** führt während des nächsten Wartungsfensters nicht zu einem automatischen Neustart. Damit die neuesten Parameteränderungen für diese DB-Instance übernommen werden, starten Sie die DB-Instance manuell neu. Weitere Informationen zu Parametergruppen finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
**Topics**
+ [Neustarten einer DB-Instance in einem Aurora Cluster](aurora-reboot-db-instance.md)
+ [Neustarten eines Aurora-Clusters mit Leseverfügbarkeit](aurora-mysql-survivable-replicas.md)
+ [Neustart eines Aurora-Clusters ohne Leseverfügbarkeit](aurora-reboot-cluster.md)
+ [Überprüfung der Betriebszeit für Aurora Cluster und Instances](USER_Reboot.Uptime.md)
+ [Beispiele für Aurora Neustartvorgänge](USER_Reboot.Examples.md)
# Neustarten einer DB-Instance in einem Aurora Cluster
Dieses Verfahren ist der wichtigste Vorgang, den Sie beim Durchführen von Neustarts mit Aurora ausführen. Viele der Wartungsverfahren beinhalten das Neustarten einer oder mehrerer Aurora DB-Instances in einer bestimmten Reihenfolge.
## Konsole
**Neustarten einer DB-Instance**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** und dann die DB-Instance aus, die Sie neu starten möchten.
1. Wählen Sie unter **Aktionen** die Option **Neustart** aus.
Die Seite **DB-Instance neu starten** wird angezeigt.
1. Wählen Sie **Neustart** aus, um Ihrer DB-Instance neu zu starten.
Oder klicken Sie auf **Abbrechen**.
## AWS CLI
Um eine DB-Instance mithilfe von AWS CLI neu zu starten, rufen Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html) auf.
**Example**
Linux, macOS oder Unix:
```
aws rds reboot-db-instance \
--db-instance-identifier mydbinstance
```
Für Windows:
```
aws rds reboot-db-instance ^
--db-instance-identifier mydbinstance
```
## RDS-API
Um eine DB-Instance mithilfe der Amazon-RDS-API neu zu starten, rufen Sie den Vorgang [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) auf.
# 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](aurora-reboot-db-instance.md).
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](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Replicas.SRO).
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](aurora-reboot-cluster.md).
**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](USER_WorkingWithParamGroups.md). 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](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster).
Eine Liste aller Cluster-Parameter von Aurora PostgreSQL finden Sie unter [Aurora-PostgreSQL-Parameter auf Cluster-Ebene](AuroraPostgreSQL.Reference.ParameterGroups.md#AuroraPostgreSQL.Reference.Parameters.Cluster).
**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.
# Neustart eines Aurora-Clusters ohne Leseverfügbarkeit
Ohne die Funktion zur Leseverfügbarkeit starten Sie einen ganzen Aurora-DB-Cluster neu, indem Sie die Writer-DB-Instance dieses Clusters neu starten. Eine Schritt-für-Schritt-Anleitung hierzu finden Sie unter [Neustarten einer DB-Instance in einem Aurora Cluster](aurora-reboot-db-instance.md).
Ein Neustart der Writer-DB-Instance initiiert auch einen Neustart für jede Reader-DB-Instance im Cluster. Auf diese Weise werden alle clusterweiten Parameteränderungen gleichzeitig auf alle DB-Instances angewendet. Der Neustart aller DB-Instances führt jedoch zu einem kurzen Ausfall für den Cluster. Die Reader DB-Instances bleiben nicht verfügbar, bis die Writer DB-Instance den Neustart beendet hat und verfügbar wird.
Dieses Neustartverhalten gilt für alle DB-Cluster, die in Aurora MySQL Version 2.09 und niedriger erstellt wurden.
Für Aurora PostgreSQL gilt dieses Verhalten für die folgenden Versionen:
+ 14.6 und niedrigere 14-Versionen
+ 13.9 und niedrigere 13-Versionen
+ 12.13 und niedrigere 12-Versionen
+ Alle PostgreSQL-11-Versionen
In der RDS-Konsole hat die Writer-DB-Instance den Wert** Writer** in der Spalte** Rolle** auf der Seite **Datenbanken**. In der RDS CLI enthält die Ausgabe des `describe-db-clusters`-Befehls einen Abschnitt `DBClusterMembers`. Das `DBClusterMembers`-Element, das die Writer-DB-Instance repräsentiert, hat einen Wert von `true` für das `IsClusterWriter` Feld.
**Wichtig**
Mit der Funktion zur Leseverfügbarkeit ist das Neustartverhalten in Aurora MySQL anders als in Aurora PostgreSQL: Die Reader-DB-Instances bleiben normalerweise verfügbar, während Sie die Writer-Instance neu starten. Dann können Sie die Reader-Instances zu einem geeigneten Zeitpunkt neu starten. Sie können die Reader-Instances nach einem gestaffelten Zeitplan neu starten, wenn einige Reader-Instances immer verfügbar sein sollen. Weitere Informationen finden Sie unter [Neustarten eines Aurora-Clusters mit Leseverfügbarkeit](aurora-mysql-survivable-replicas.md).
# Überprüfung der Betriebszeit für Aurora Cluster und Instances
Sie können die Dauer seit dem letzten Neustart für jede DB-Instance in Ihrem Aurora Cluster überprüfen und überwachen. Die CloudWatch `EngineUptime` Amazon-Metrik gibt die Anzahl der Sekunden seit dem letzten Start einer DB-Instance an. Sie können diese Metrik zu einem bestimmten Zeitpunkt untersuchen, um die Verfügbarkeit der DB-Instance zu ermitteln. Sie können diese Metrik auch im Laufe der Zeit überwachen, um zu erkennen, wann die Instance neu gestartet wird.
Sie können die `EngineUptime` Metrik auch auf Clusterebene untersuchen. Die `Minimum`- und `Maximum`- Dimensionen geben die kleinsten und größten Verfügbarkeitswerte für alle DB-Instances im Cluster an. Um zu überprüfen, wann eine Reader-Instance in einem Cluster zuletzt neu gestartet oder aus einem anderen Grund neu gestartet wurde, überwachen Sie die Metrik auf Clusterebene mithilfe der `Minimum`-Dimension. Um zu überprüfen, welche Instance im Cluster am längsten ohne Neustart gelaufen ist, überwachen Sie die Metrik auf Clusterebene mithilfe der `Maximum`-Dimension. Sie möchten beispielsweise bestätigen, dass alle DB-Instances im Cluster nach einer Konfigurationsänderung neu gestartet wurden.
**Tipp**
Für eine langfristige Überwachung empfehlen wir, die `EngineUptime`-Metrik für einzelne Instances statt auf Clusterebene zu überwachen. Die `EngineUptime`-Metrik auf Clusterebene wird auf Null gesetzt, wenn dem Cluster eine neue DB-Instance hinzugefügt wird. Solche Clusteränderungen können im Rahmen von Wartungs- und Skalierungsvorgängen auftreten, wie sie von Auto Scaling durchgeführt werden.
Die folgenden CLI-Beispiele zeigen, wie die `EngineUptime`-Metrik für die Writer- und Reader-Instances in einem Cluster untersucht wird. Die Beispiele verwenden einen Cluster namens `tpch100g`. Dieser Cluster hat eine Writer-DB-Instance `instance-1234`. Er hat auch zwei Reader-DB-Instances, `instance-7448` und `instance-6305`.
Zuerst startet der `reboot-db-instance`-Befehl eine der Reader-Instances neu. Der `wait`-Befehl wartet, bis die Instance mit dem Neustart abgeschlossen ist.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
"DBInstance": {
"DBInstanceIdentifier": "instance-6305",
"DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-6305
```
Der CloudWatch `get-metric-statistics` Befehl untersucht die `EngineUptime` Metrik in den letzten fünf Minuten in Intervallen von einer Minute. Die Betriebszeit für die `instance-6305` Instance wird auf Null zurückgesetzt und beginnt wieder nach oben zu zählen. In diesem AWS CLI Beispiel für Linux wird die `$()` Variablenersetzung verwendet, um die entsprechenden Zeitstempel in die CLI-Befehle einzufügen. Es verwendet auch den `sort` Linux-Befehl, um die Ausgabe bis zum Zeitpunkt der Erfassung der Metrik zu ordnen. Dieser Zeitstempelwert ist das dritte Feld in jeder Ausgabezeile.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds
DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds
DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds
DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
```
Die minimale Betriebszeit für den Cluster wird auf Null zurückgesetzt, da eine der Instances im Cluster neu gestartet wurde. Die maximale Betriebszeit für den Cluster wird nicht zurückgesetzt, da mindestens eine der DB-Instances im Cluster verfügbar blieb.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Minimum \
--dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds
DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds
DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds
DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds
DATAPOINTS 51.0 2021-03-16T18:16:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds
DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds
DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds
DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds
DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds
```
Dann startet ein anderer `reboot-db-instance` Befehl die Writer-Instance des Clusters neu. Ein anderer `wait` Befehl wird pausiert, bis die Writer-Instance mit dem Neustart abgeschlossen ist.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
"DBInstanceIdentifier": "instance-1234",
"DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234
```
Jetzt zeigt die `EngineUptime` Metrik für die Writer-Instance, dass die Instance `instance-1234` kürzlich neu gestartet wurde. Die Reader-Instance `instance-6305` wurde zusammen mit der Writer-Instance ebenfalls automatisch neu gestartet. Auf diesem Cluster wird Aurora MySQL 2.09 ausgeführt, wodurch die Reader-Instances nicht weiter ausgeführt werden, wenn die Writer-Instance neu gestartet wird.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds
DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds
DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds
DATAPOINTS 101.0 2021-03-16T18:26:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds
DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds
```
# Beispiele für Aurora Neustartvorgänge
Die folgenden Aurora MySQL Beispiele zeigen verschiedene Kombinationen von Neustartvorgängen für Reader- und Writer-DB-Instances in einem Aurora DB-Cluster. Nach jedem Neustart demonstrieren SQL-Abfragen die Verfügbarkeit der Instances im Cluster.
**Topics**
+ [Finden der Writer- und Reader-Instances für einen Aurora-Cluster](#USER_Reboot.Examples.IsClusterWriter)
+ [Neustart einer einzelnen Reader-Instance](#USER_Reboot.Examples.RebootReader)
+ [Neustart der Writer-Instance](#USER_Reboot.Examples.RebootWriter)
+ [Den Writer und die Reader unabhängig neu starten](#USER_Reboot.Examples.RebootAsynch)
+ [Anwenden einer Clusterparameteränderung auf einen Cluster der Aurora MySQL Version 2.10](#USER_Reboot.Examples.ParamChangeNewStyle)
## Finden der Writer- und Reader-Instances für einen Aurora-Cluster
In einem Aurora MySQL Cluster mit mehreren DB-Instances ist es wichtig zu wissen, welche der Writer und welche die Reader sind. Die Writer- und Reader-Instances können auch Rollen wechseln, wenn ein Failover-Vorgang stattfindet. Daher ist es am besten, eine Überprüfung wie die folgende durchzuführen, bevor Sie eine Operation ausführen, die eine Writer- oder Reader-Instance erfordert. In diesem Fall identifizieren die `False`-Werte für `IsClusterWriter` die Reader-Instances, `instance-6305` und `instance-7448`. Der `True` Wert identifiziert die Writer-Instance `instance-1234`.
```
$ aws rds describe-db-clusters --db-cluster-id tpch100g \
--query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
--output text
Cluster: tpch100g
Instance: instance-6305 False
Instance: instance-7448 False
Instance: instance-1234 True
```
Bevor wir mit den Beispielen für den Neustart beginnen, hat die Writer-Instance eine Betriebszeit von ungefähr einer Woche. Die SQL-Abfrage in diesem Beispiel zeigt eine MySQL-spezifische Möglichkeit, die Betriebszeit zu überprüfen. Sie können diese Technik in einer Datenbankanwendung verwenden. Für eine andere Technik, die AWS CLI verwendet und für beide Aurora-Engines funktioniert, siehe [Überprüfung der Betriebszeit für Aurora Cluster und Instances](USER_Reboot.Uptime.md).
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status
-> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+
```
## Neustart einer einzelnen Reader-Instance
In diesem Beispiel wird eine der Reader-DB-Instances neu gestartet. Vielleicht wurde diese Instance von einer riesigen Abfrage oder vielen gleichzeitigen Verbindungen überlastet. Oder vielleicht fiel sie wegen eines Netzwerkproblems hinter die Writer-Instance zurück. Nach dem Start des Neustartvorgangs verwendet das Beispiel einen `wait` Befehl, um anzuhalten, bis die Instance verfügbar ist. Zu diesem Zeitpunkt hat die Instance eine Betriebszeit von einigen Minuten.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
"DBInstance": {
"DBInstanceIdentifier": "instance-6305",
"DBInstanceStatus": "rebooting",
...
}
}
$ aws rds wait db-instance-available --db-instance-id instance-6305
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status
-> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:35:02.000000 | 00h 03m |
+----------------------------+---------+
```
Der Neustart der Reader-Instance hatte keinen Einfluss auf die Verfügbarkeit der Writer-Instance. Sie hat immer noch eine Betriebszeit von etwa einer Woche.
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+----------+
| Last Startup | Uptime |
+----------------------------+----------+
| 2021-03-08 17:49:06.000000 | 174h 49m |
+----------------------------+----------+
```
## Neustart der Writer-Instance
In diesem Beispiel wird die Writer-Instance neu gestartet. Auf diesem Cluster wird Aurora MySQL Version 2.09 ausgeführt. Da die Aurora MySQL Version niedriger als 2.10 ist, werden beim Neustart der Writer-Instance auch alle Reader-Instances im Cluster neu gestartet.
Ein `wait` Befehl wird angehalten, bis der Neustart abgeschlossen ist. Jetzt wird die Betriebszeit für diese Instance auf Null zurückgesetzt. Es ist möglich, dass ein Neustartvorgang für Writer- und Reader-DB-Instances erheblich unterschiedliche Zeiten in Anspruch nehmen kann. Die Writer- und Reader-DB-Instances führen je nach ihren Rollen verschiedene Arten von Bereinigungsvorgängen aus.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
"DBInstance": {
"DBInstanceIdentifier": "instance-1234",
"DBInstanceStatus": "rebooting",
...
}
}
$ aws rds wait db-instance-available --db-instance-id instance-1234
$ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:27.000000 | 00h 00m |
+----------------------------+---------+
```
Nach dem Neustart für die Writer-DB-Instance haben beide Reader-DB-Instances auch ihre Betriebszeit zurückgesetzt. Durch den Neustart der Writer-Instance wurden die Reader-Instances ebenfalls neu gestartet. Dieses Verhalten gilt für Aurora PostgreSQL Cluster und Aurora MySQL Cluster vor Version 2.10.
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+
```
## Den Writer und die Reader unabhängig neu starten
Diese nächsten Beispiele zeigen einen Cluster, der Aurora MySQL Version 2.10 ausführt. In dieser Aurora MySQL Version und höher können Sie die Writer-Instance neu starten, ohne Neustarts für alle Reader-Instances zu verursachen. Auf diese Weise kommt es bei Ihren abfrachintensiven Anwendungen zu keinem Ausfall, wenn Sie die Writer-Instance neu starten. Sie können die Reader-Instances später neu starten. Sie können diese Neustarts zu einem Zeitpunkt mit geringem Abfrageverkehr durchführen. Sie können die Reader-Instances auch nacheinander neu starten. Auf diese Weise steht immer mindestens eine Reader-Instance für den Abfrageverkehr Ihrer Anwendung zur Verfügung.
Im folgenden Beispiel wird ein Cluster namens `cluster-2393` verwendet, auf dem Aurora MySQL Version `5.7.mysql_aurora.2.10.0` ausgeführt wird. Dieser Cluster hat eine Writer-Instance namens `instance-9404` und drei Reader-Instances namens `instance-6772`, `instance-2470` und `instance-5138`.
```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
--query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
--output text
Cluster: cluster-2393
Instance: instance-5138 False
Instance: instance-2470 False
Instance: instance-6772 False
Instance: instance-9404 True
```
Die Überprüfung des `uptime` Werts jeder Datenbankinstance mit dem Befehl `mysql` zeigt, dass jede ungefähr die gleiche Betriebszeit hat. Hier ist zum Beispiel die Betriebszeit für `instance-5138`.
```
mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 3866 |
+---------------+-------+
```
Durch die Verwendung von CloudWatch können wir die entsprechenden Betriebszeitinformationen abrufen, ohne sich tatsächlich bei den Instances anzumelden. Auf diese Weise kann ein Administrator die Datenbank überwachen, aber keine Tabellendaten anzeigen oder ändern. In diesem Fall geben wir einen Zeitraum von fünf Minuten an und überprüfen den Betriebszeitwert jede Minute. Die zunehmenden Betriebszeitwerte zeigen, dass die Instances in diesem Zeitraum nicht neu gestartet wurden.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4648.0 2021-03-17T23:42:00+00:00 Seconds
DATAPOINTS 4708.0 2021-03-17T23:43:00+00:00 Seconds
DATAPOINTS 4768.0 2021-03-17T23:44:00+00:00 Seconds
DATAPOINTS 4828.0 2021-03-17T23:45:00+00:00 Seconds
DATAPOINTS 4888.0 2021-03-17T23:46:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4315.0 2021-03-17T23:42:00+00:00 Seconds
DATAPOINTS 4375.0 2021-03-17T23:43:00+00:00 Seconds
DATAPOINTS 4435.0 2021-03-17T23:44:00+00:00 Seconds
DATAPOINTS 4495.0 2021-03-17T23:45:00+00:00 Seconds
DATAPOINTS 4555.0 2021-03-17T23:46:00+00:00 Seconds
```
Jetzt starten wir eine der Reader-Instances neu, `instance-5138`. Wir warten darauf, dass die Instance nach dem Neustart wieder verfügbar ist. Die Überwachung der Betriebszeit über einen Zeitraum von fünf Minuten zeigt, dass die Betriebszeit während dieser Zeit auf Null zurückgesetzt wurde. Der letzte Betriebszeitwert wurde fünf Sekunden nach Abschluss des Neustarts gemessen.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4500.0 2021-03-17T23:46:00+00:00 Seconds
DATAPOINTS 4560.0 2021-03-17T23:47:00+00:00 Seconds
DATAPOINTS 4620.0 2021-03-17T23:48:00+00:00 Seconds
DATAPOINTS 4680.0 2021-03-17T23:49:00+00:00 Seconds
DATAPOINTS 5.0 2021-03-17T23:50:00+00:00 Seconds
```
Als Nächstes führen wir einen Neustart für die Writer-Instance durch, `instance-9404`. Wir vergleichen die Betriebszeit-Werte für die Writer-Instance und eine der Reader-Instances. Auf diese Weise können wir sehen, dass der Neustart des Writers für die Reader keinen Neustart verursacht hat. In Versionen vor Aurora MySQL 2.10 würden die Verfügbarkeitswerte für alle Reader gleichzeitig mit dem Writer zurückgesetzt.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
{
"DBInstanceIdentifier": "instance-9404",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-9404
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 371.0 2021-03-17T23:57:00+00:00 Seconds
DATAPOINTS 431.0 2021-03-17T23:58:00+00:00 Seconds
DATAPOINTS 491.0 2021-03-17T23:59:00+00:00 Seconds
DATAPOINTS 551.0 2021-03-18T00:00:00+00:00 Seconds
DATAPOINTS 37.0 2021-03-18T00:01:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 5215.0 2021-03-17T23:57:00+00:00 Seconds
DATAPOINTS 5275.0 2021-03-17T23:58:00+00:00 Seconds
DATAPOINTS 5335.0 2021-03-17T23:59:00+00:00 Seconds
DATAPOINTS 5395.0 2021-03-18T00:00:00+00:00 Seconds
DATAPOINTS 5455.0 2021-03-18T00:01:00+00:00 Seconds
```
Um sicherzustellen, dass alle Reader-Instances dieselben Änderungen an den Konfigurationsparametern haben wie die Writer-Instance, starten Sie alle Reader-Instances nach dem Writer neu. Dieses Beispiel startet alle Reader neu und wartet dann, bis alle verfügbar sind, bevor Sie fortfahren.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6772
{
"DBInstanceIdentifier": "instance-6772",
"DBInstanceStatus": "rebooting"
}
$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
"DBInstanceIdentifier": "instance-2470",
"DBInstanceStatus": "rebooting"
}
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-6772
$ aws rds wait db-instance-available --db-instance-id instance-2470
$ aws rds wait db-instance-available --db-instance-id instance-5138
```
Jetzt können wir sehen, dass die Writer-DB-Instance die höchste Betriebszeit hat. Der Betriebszeitwert dieser Instance stieg während des gesamten Überwachungszeitraums stetig an. Die Reader DB-Instances wurden alle nach dem Reader neu gestartet. Wir können den Punkt innerhalb des Überwachungszeitraums sehen, an dem jeder Reader neu gestartet wurde und seine Betriebszeit auf Null zurückgesetzt wurde.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 457.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 517.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 577.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 637.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 697.0 2021-03-18T00:12:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 5819.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 35.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 95.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 155.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 215.0 2021-03-18T00:12:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 1085.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 1145.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 1205.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 49.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 109.0 2021-03-18T00:12:00+00:00 Seconds
```
## Anwenden einer Clusterparameteränderung auf einen Cluster der Aurora MySQL Version 2.10
Das folgende Beispiel veranschaulicht, wie Sie eine Parameteränderung auf alle DB-Instances in Ihrem Aurora MySQL 2.10-Cluster anwenden. Mit dieser Aurora MySQL Version starten Sie die Writer-Instance und alle Reader-Instances unabhängig neu.
Das Beispiel verwendet den MySQL-Konfigurationsparameter `lower_case_table_names` zur Veranschaulichung. Wenn sich diese Parametereinstellung zwischen den Writer- und Reader-DB-Instances unterscheidet, kann eine Abfrage möglicherweise nicht auf eine Tabelle zugreifen, die mit einem Namen in Großbuchstaben oder gemischten Buchstaben deklariert wurde. Oder wenn sich zwei Tabellennamen nur in Groß- und Kleinbuchstaben unterscheiden, kann eine Abfrage auf die falsche Tabelle zugreifen.
Dieses Beispiel zeigt, wie Sie die Writer- und Reader-Instances im Cluster ermitteln können, indem Sie das `IsClusterWriter` Attribut jeder Instance untersuchen. Der Cluster heißt `cluster-2393`. Der Cluster hat eine Writer-Instance namens `instance-9404`. Die Reader-Instances im Cluster heißen `instance-5138` und `instance-2470`.
```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
--query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
--output text
cluster-2393
instance-5138 False
instance-2470 False
instance-9404 True
```
Um die Auswirkungen der Änderung des `lower_case_table_names` Parameters zu demonstrieren, richten wir zwei DB-Cluster-Parametergruppen ein. Für die `lower-case-table-names-0` Parametergruppe ist dieser Parameter auf 0 festgelegt. Die `lower-case-table-names-1` Parametergruppe hat diese Parametergruppe auf 1 festgelegt.
```
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \
--db-parameter-group-family aurora-mysql5.7 \
--db-cluster-parameter-group-name lower-case-table-names-0
{
"DBClusterParameterGroup": {
"DBClusterParameterGroupName": "lower-case-table-names-0",
"DBParameterGroupFamily": "aurora-mysql5.7",
"Description": "lower-case-table-names-0"
}
}
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \
--db-parameter-group-family aurora-mysql5.7 \
--db-cluster-parameter-group-name lower-case-table-names-1
{
"DBClusterParameterGroup": {
"DBClusterParameterGroupName": "lower-case-table-names-1",
"DBParameterGroupFamily": "aurora-mysql5.7",
"Description": "lower-case-table-names-1"
}
}
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lower-case-table-names-0 \
--parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lower-case-table-names-0"
}
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lower-case-table-names-1 \
--parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lower-case-table-names-1"
}
```
Der Standardwert von `lower_case_table_names` ist 0. Bei dieser Parametereinstellung unterscheidet sich die Tabelle `foo` von der Tabelle `FOO`. In diesem Beispiel wird überprüft, dass der Parameter immer noch seine Standardeinstellung hat. Dann erstellt das Beispiel drei Tabellen, die sich nur in Groß- und Kleinbuchstaben in ihren Namen unterscheiden.
```
mysql> create database lctn;
Query OK, 1 row affected (0.07 sec)
mysql> use lctn;
Database changed
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 0 |
+--------------------------+
mysql> create table foo (s varchar(128));
mysql> insert into foo values ('Lowercase table name foo');
mysql> create table Foo (s varchar(128));
mysql> insert into Foo values ('Mixed-case table name Foo');
mysql> create table FOO (s varchar(128));
mysql> insert into FOO values ('Uppercase table name FOO');
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+---------------------------+
| s |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```
Als Nächstes verknüpfen wir die DB-Parametergruppe mit dem Cluster, um den `lower_case_table_names` Parameter auf 1 festzulegen. Diese Änderung wird erst wirksam, nachdem jede DB-Instance neu gestartet wurde.
```
$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \
--db-cluster-parameter-group-name lower-case-table-names-1
{
"DBClusterIdentifier": "cluster-2393",
"DBClusterParameterGroup": "lower-case-table-names-1",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.0"
}
```
Der erste Neustart, den wir machen, ist für die Writer-DB-Instance. Dann warten wir, bis die Instance wieder verfügbar wird. An diesem Punkt stellen wir eine Verbindung zum Writer-Endpunkt her und stellen sicher, dass die Writer-Instance den geänderten Parameterwert hat. Der `SHOW TABLES` Befehl bestätigt, dass die Datenbank die drei verschiedenen Tabellen enthält. Abfragen, die sich auf Tabellen mit den Namen `foo`, `Foo` oder `FOO` beziehen, greifen jedoch alle auf die Tabelle zu, deren Name nur aus Kleinbuchstaben besteht, `foo` .
```
# Rebooting the writer instance
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
$ aws rds wait db-instance-available --db-instance-id instance-9404
```
Abfragen, die den Cluster-Endpunkt verwenden, zeigen nun die Auswirkungen der Parameteränderung. Unabhängig davon, ob der Tabellenname in der Abfrage aus Groß-, Kleinbuchstaben- oder gemischten Buchstaben besteht, greift die SQL-Anweisung auf die Tabelle zu, deren Name ganz aus Kleinbuchstaben besteht.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
mysql> use lctn;
mysql> show tables;
+----------------+
| Tables_in_lctn |
+----------------+
| FOO |
| Foo |
| foo |
+----------------+
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```
Das nächste Beispiel zeigt die gleichen Abfragen wie das vorherige. In diesem Fall verwenden die Abfragen den Reader-Endpunkt und werden auf einer der Reader DB-Instances ausgeführt. Diese Instances wurden noch nicht neu gestartet. Somit haben sie immer noch die ursprüngliche Einstellung für den `lower_case_table_names` Parameter. Das bedeutet, dass Abfragen auf jede der `foo`-, `Foo`- und `FOO`-Tabellen zugreifen können.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 0 |
+--------------------------+
mysql> use lctn;
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+---------------------------+
| s |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```
Als Nächstes starten wir eine der Reader-Instances neu und warten darauf, dass sie wieder verfügbar ist.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
"DBInstanceIdentifier": "instance-2470",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-2470
```
Während eine Abfrage mit dem Instance-Endpunkt für `instance-2470` verbunden ist, zeigt eine Abfrage, dass der neue Parameter in Kraft ist.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
```
Zu diesem Zeitpunkt werden die beiden Reader-Instances im Cluster mit unterschiedlichen `lower_case_table_names` Einstellungen ausgeführt. Daher verwendet jede Verbindung zum Reader-Endpunkt des Clusters einen Wert für diese Einstellung, der unvorhersehbar ist. Es ist wichtig, die andere Reader-Instance sofort neu zu starten, damit beide konsistente Einstellungen haben.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138
```
Das folgende Beispiel bestätigt, dass alle Reader-Instances dieselbe Einstellung für den `lower_case_table_names` Parameter haben. Die Befehle überprüfen den `lower_case_table_names` Einstellungswert für jede Reader-Instance. Dann zeigt derselbe Befehl, der den Reader-Endpunkt verwendet, dass jede Verbindung zum Reader-Endpunkt eine der Reader-Instances verwendet, welche jedoch nicht vorhersehbar ist.
```
# Check lower_case_table_names setting on each reader instance.
$ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138 | 1 |
+--------------------------+--------------------------+
$ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-2470 | 1 |
+--------------------------+--------------------------+
# Check lower_case_table_names setting on the reader endpoint of the cluster.
$ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138 | 1 |
+--------------------------+--------------------------+
# Run query on writer instance
$ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-9404 | 1 |
+--------------------------+--------------------------+
```
Wenn die Parameteränderung überall angewendet wird, können wir die Auswirkungen der Einstellung von sehe `lower_case_table_names=1`. Unabhängig davon, ob die Tabelle als `foo` , `Foo` oder `FOO` bezeichnet wird, wandelt die Abfrage den Namen in `foo` um und greift jeweils auf dieselbe Tabelle zu.
```
mysql> use lctn;
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```