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 SQL My-Beispiele zeigen verschiedene Kombinationen von Neustartvorgängen für Reader- und Writer-DB-Instances in einem Aurora-DB-Cluster. Nach jedem Neustart zeigen SQL Abfragen die Verfügbarkeit der Instances im Cluster.
Themen
Finden der Writer- und Reader-Instances für einen Aurora-Cluster
In einem Aurora SQL My-Cluster mit mehreren DB-Instances ist es wichtig zu wissen, welche der Writer und welche die Leser 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 My SQL -spezifische Methode zur Überprüfung der Verfügbarkeit. Sie können diese Technik in einer Datenbankanwendung verwenden. Eine weitere Technik, bei der das AWS CLI und für beide Aurora-Engines verwendet wird, finden Sie unterÜberprüfung der Betriebszeit für Aurora Cluster und Instances.
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -umy-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 -umy-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 -umy-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 My SQL Version 2.09 ausgeführt. Da die Aurora SQL My-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 -umy-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 SQL Postgre-Cluster und für Aurora SQL My-Cluster vor Version 2.10.
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -umy-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 -umy-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
Die nächsten Beispiele zeigen einen Cluster, auf dem Aurora My SQL Version 2.10 ausgeführt wird. In dieser Aurora SQL My-Version und höher können Sie die Writer-Instance neu starten, ohne dass alle Reader-Instanzen neu gestartet werden. 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 mit dem Namencluster-2393, auf dem Aurora My SQL Version ausgeführt wird, verwendet5.7.mysql_aurora.2.10.0. 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 können wir die entsprechenden Verfügbarkeitsinformationen abrufen CloudWatch, ohne uns tatsächlich bei den Instances anmelden zu müssen. 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 My SQL 2.10 wurden die Verfügbarkeitswerte für alle Lesegeräte 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 Cluster-Parameteränderung auf einen Aurora My SQL Version 2.10-Cluster
Das folgende Beispiel zeigt, wie Sie eine Parameteränderung auf alle DB-Instances in Ihrem Aurora My SQL 2.10-Cluster anwenden. Mit dieser Aurora SQL My-Version starten Sie die Writer-Instanz und alle Reader-Instanzen unabhängig voneinander neu.
Das Beispiel verwendet zur Veranschaulichung den SQL lower_case_table_names Konfigurationsparameter My. 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 in Groß- oder Kleinbuchstaben geschrieben ist, greift die SQL Anweisung auf die Tabelle zu, deren Name ausschließlich 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 \ -umy-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 \ -umy-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 \ -umy-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 \ -umy-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 | +--------------------------+
