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.
# 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 |
+--------------------------+
```