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 eine DB-Instance nicht die neuesten Änderungen an ihrer zugehörigen DB-Parametergruppe verwendet, wird die DB-Parametergruppe mit dem Status „Ausstehender Neustart“ AWS Management Console angezeigt. 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 Arbeiten mit Parametergruppen.
Themen
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.
Neustarten einer DB-Instance
-
Melden Sie sich bei der Amazon RDS-Konsole an AWS Management Console und öffnen Sie sie unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Databases (Datenbanken) und dann die DB-Instance aus, die Sie neu starten möchten.
-
Wählen Sie unter Aktionen die Option Neustart aus.
Die Seite DB-Instance neu starten wird angezeigt.
-
Wählen Sie Neustart aus, um Ihrer DB-Instance neu zu starten.
Oder klicken Sie auf Abbrechen.
Um eine DB-Instance mithilfe von neu zu starten AWS CLI, rufen Sie den reboot-db-instanceBefehl auf.
Für LinuxmacOS, oderUnix:
aws rds reboot-db-instance \ --db-instance-identifiermydbinstance
Windows:
aws rds reboot-db-instance ^ --db-instance-identifiermydbinstance
Um eine DB-Instance mithilfe der Amazon RDS-API neu zu starten, rufen Sie den Vorgang RebootDBInstance auf.
Neustart eines Aurora-Clusters mit Leseverfügbarkeit
Mit der Leseverfügbarkeitsfunktion 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. In einem Produktionscluster können Sie beispielsweise die Reader-Instances nacheinander neu starten und erst beginnen, nachdem der Neustart der primären Instance abgeschlossen ist. Folgen Sie für jede DB-Instance, die Sie neu starten, dem Verfahren unter Neustarten einer DB-Instance in einem Aurora Cluster.
Die Leseverfügbarkeitsfunktion für primäre DB-Cluster ist in Aurora MySQL Version 2.10 und höher verfügbar. Die Leseverfügbarkeit für sekundäre DB-Cluster ist in Aurora MySQL Version 3.06 und höher verfügbar.
Diese Funktion steht standardmäßig für die folgenden Aurora-PostgreSQL-Versionen zur Verfügung:
15.2 und höhere 15-Versionen
14.7 und höhere 14-Versionen
13.10 und höhere 13-Versionen
12.14 und höhere 12-Versionen
Weitere Informationen zur Leseverfügbarkeitsfunktion in Aurora PostgreSQL finden Sie unter Verbesserung der Leseverfügbarkeit von Aurora Replicas.
Vor dieser Funktion führte der Neustart der primären Instance zu einem Neustart für jede Reader-Instance gleichzeitig. Wenn auf Ihrem Aurora-Cluster eine ältere Version ausgeführt wird, verwenden Sie stattdessen das Neustartverfahren in Neustart eines Aurora-Clusters ohne Leseverfügbarkeit.
Anmerkung
Die Änderung des Neustartverhaltens in Aurora-DB-Clustern mit Leseverfügbarkeit unterscheidet sich für globale Aurora-Datenbanken in Aurora MySQL-Versionen vor 3.06. 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 den 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 Arbeiten mit Parametergruppen. Angenommen, Sie starten die Writer-DB-Instance in einem Aurora-Cluster neu, um Änderungen an Cluster-Parametern anzuwenden. Einige oder alle Reader-DB-Instances verwenden möglicherweise weiterhin die alten Parametereinstellungen. Die verschiedenen Parametereinstellungen haben jedoch keinen Einfluss auf die Datenintegrität des Clusters. Alle Clusterparameter, die sich auf die Organisation von Datendateien auswirken, werden nur von der Writer-DB-Instance verwendet.
Beispielsweise können Sie in einem Aurora-MySQL-Cluster Cluster-Parameter wie binlog_format und innodb_purge_threads auf der Writer-Instance vor den Reader-Instances aktualisieren. Nur die Writer-Instance schreibt binäre Protokolle und löscht Datensätze für das Rückgängigmachen. Bei Parametern, die die Interpretation von SQL-Anweisungen oder Abfrageausgaben ändern, müssen Sie möglicherweise darauf achten, die Reader-Instances sofort neu zu starten. Sie tun dies, um unerwartetes Anwendungsverhalten bei Abfragen zu vermeiden. Angenommen, Sie ändern den lower_case_table_names Parameter und starten die Writer-Instance neu. In diesem Fall können die Reader-Instances möglicherweise erst auf eine neu erstellte Tabelle zugreifen, wenn sie alle neu gestartet wurden.
Eine Liste aller Aurora MySQL Clusterparameter finden Sie unter Parameter auf Cluster-Ebene.
Eine Liste aller Cluster-Parameter von Aurora PostgreSQL finden Sie unter Aurora-PostgreSQL-Parameter auf Cluster-Ebene.
Tipp
Aurora MySQL startet möglicherweise noch einige der Reader-Instances zusammen mit der Writer-Instance neu, wenn Ihr Cluster einen Workload mit hohem Durchsatz verarbeitet.
Die Verringerung der Anzahl der Neustarts gilt auch während des Failovervorgangs. Aurora MySQL startet nur die Writer-DB-Instance und das Failover-Ziel während eines Failovers neu. Andere Reader-DB-Instances im Cluster bleiben verfügbar, um Abfragen über Verbindungen zum Reader-Endpunkt fortzusetzen. So können Sie die Verfügbarkeit während eines Failovers verbessern, indem Sie mehr als eine Reader-DB-Instance in einem Cluster haben.
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.
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 Neustart eines Aurora-Clusters mit Leseverfügbarkeit.
Ü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.
Themen
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. 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 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 -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 PostgreSQL Cluster und Aurora MySQL 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
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 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 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 \ -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 | +--------------------------+
