Aurora 重新啟動操作的範例 - Amazon Aurora
尋找 Aurora 叢集的寫入器和讀取器執行個體重新啟動單一讀取器執行個體重新啟動寫入器執行個體單獨重新啟動寫入器和讀取器將叢集參數變更套用至 Aurora 我的SQL版本 2.10 叢集

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Aurora 重新啟動操作的範例

下列 Aurora 我的SQL範例顯示 Aurora 資料庫叢集中讀取器和寫入器資料庫執行個體的不同重新啟動作業組合。每次重新開機後，SQL查詢都會示範叢集中執行個體的正常執行時間。

尋找 Aurora 叢集的寫入器和讀取器執行個體

在具有多個資料庫執行個體的 Aurora My SQL 叢集中，請務必知道哪一個是寫入器，哪些是讀取器。寫入器和讀取器執行個體也可以在發生容錯移轉操作時切換角色。因此，在執行任何需要寫入器或讀取器執行個體的操作之前，最好執行如下所示的檢查。在這種情況下，False 的 IsClusterWriter 值識別讀取器執行個體 (instance-6305 和 instance-7448)。True 值識別寫入器執行個體 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

在開始重新啟動的範例之前，寫入器執行個體擁有大約一週的執行時間。此示例中的SQL查詢顯示了我的SQL特定方法來檢查正常運行時間。您可以在資料庫應用程式中使用這種技術。如需使用 AWS CLI 和適用於兩個 Aurora 引擎的其他技術，請參閱檢查 Aurora 叢集和執行個體的執行時間。

$ 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|
+----------------------------+---------+

重新啟動單一讀取器執行個體

此範例會重新啟動一個讀取器資料庫執行個體。這個執行個體或許因一個巨大的查詢或許多並行連線而過載。其也可能因為網絡問題而落後於寫入器執行個體。開始重新啟動操作之後，範例會使用 wait 命令暫停，直到執行個體變成可用為止。此時，執行個體的執行時間為幾分鐘。

$ 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 |
+----------------------------+---------+

重新啟動讀取器執行個體並不會影響寫入器執行個體的執行時間。它仍然有大約一個星期的執行時間。

$ 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 |
+----------------------------+----------+

重新啟動寫入器執行個體

此範例會重新啟動寫入器執行個體。此集群正在運行 Aurora 我的SQL版本 2.09。由於 Aurora My SQL 版本低於 2.10，因此重新啟動寫入器執行個體也會重新啟動叢集中的所有讀取器執行個體。

wait 命令會暫停，直到重新啟動完成為止。現在該執行個體的執行時間會重設為零。對於寫入器和讀取器資料庫執行個體，重新啟動操作所用的時間可能大不相同。寫入器和讀取器資料庫執行個體會根據其角色執行不同種類的清理操作。

$ 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 |
+----------------------------+---------+

在寫入器資料庫執行個體重新啟動之後，兩個讀取器資料庫執行個體也會重設其執行時間。重新啟動寫入器執行個體也會導致讀取器執行個體重新啟動。此行為適用於版本 2.10 之前的「Aurora」SQL 叢集和「我的 Aurora」SQL 叢集。

$ 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 |
+----------------------------+---------+

單獨重新啟動寫入器和讀取器

下列範例顯示執行 Aurora 我的SQL版本 2.10 的叢集。在此 Aurora My SQL 版本及更高版本中，您可以重新啟動寫入器執行個體，而不會導致所有讀取器執行個體重新啟動。如此一來，當您重新啟動寫入器執行個體時，查詢密集型應用程式就不會遇到任何中斷。您可以稍後重新啟動讀取器執行個體。您可以在查詢流量較低時執行這些重新啟動。您也可以一次重新啟動一個讀取器執行個體。如此，至少一個讀取器執行個體永遠可用於您的應用程式的查詢流量。

下列範例使用名為cluster-2393執行 Aurora 我的SQL版本的叢集5.7.mysql_aurora.2.10.0。這個叢集有一個名為 instance-9404 的寫入器執行個體，以及三個名為 instance-6772、instance-2470 和 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

使用 uptime 命令檢查每個資料庫執行個體的 mysql 值，會發現每個資料庫執行個體的執行時間大致相同。例如，這裡是 instance-5138 的執行時間。

mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 3866  |
+---------------+-------+

通過使用 CloudWatch，我們可以獲得相應的正常運行時間信息，而無需實際登錄實例。如此一來，管理員就可以監控資料庫，但無法檢視或變更任何資料表資料。在這種情況下，我們指定跨越五分鐘的時間間隔，並每分鐘檢查執行時間值。不斷增加的執行時間值表明，該期間內未重新啟動執行個體。

$ 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

現在，我們重新啟動其中一個讀取器執行個體 instance-5138。我們會等待執行個體在重新啟動後再次變成可用。現在，監控五分鐘間隔的執行時間顯示，執行時間在這段時間內重設為零。最近的執行時間值是在重新啟動完成後的五秒鐘測量。

$ 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

接下來，我們為寫入器執行個體 instance-9404 執行重新啟動。我們會比較寫入器執行個體和其中一個讀取器執行個體的執行時間值。如此，我們可以看到重新啟寫入器並未導致讀取器重新啟動。在 Aurora My SQL 2.10 之前的版本中，所有讀取器的正常運行時間值將與寫入器同時重置。

$ 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

若要確定所有的讀取器執行個體具有與寫入器執行個體相同的組態參數變更，請在寫入器之後重新啟動所有讀取器執行個體。這個範例會重新啟動所有讀取器，然後等到所有讀取器都可以使用後再繼續。

$ 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

現在我們可以看到，寫入器資料庫執行個體具有最高的執行時間。此執行個體的執行時間值在整個監控期間穩定增加。讀取器資料庫執行個體都在讀取器之後重新啟動。我們可以看到監控期間內重新啟動每個讀取器以及將其執行時間重設為零的時間點。

$ 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

將叢集參數變更套用至 Aurora 我的SQL版本 2.10 叢集

下列範例示範如何將參數變更套用至 Aurora My SQL 2.10 叢集中的所有資料庫執行個體。使用此 Aurora My SQL 版本，您可以獨立重新啟動寫入器執行個體和所有讀取器執行個體。

此範例使用 My SQL 組態參數lower_case_table_names進行說明。當寫入器和讀取器資料庫執行個體之間的這個參數設定不一致時，查詢可能無法存取以大寫或大小寫混合名稱宣告的資料表。或者，如果兩個資料表名稱僅在大寫和小寫字母方面不同，則查詢可能會存取錯誤的資料表。

此範例會展示如何透過檢查每個執行個體的 IsClusterWriter 屬性來判定叢集中的寫入器和讀取器執行個體。叢集已命名為 cluster-2393。叢集具有名為 instance-9404 的寫入器執行個體。叢集中的讀取器執行個體名為 instance-5138 和 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

為了展示改變 lower_case_table_names 參數的影響，我們設定了兩個資料庫叢集參數群組。lower-case-table-names-0 參數群組將此參數設定為 0。lower-case-table-names-1 參數群組將此參數群組設定為 1。

$ 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"
}

lower_case_table_names 的預設值為 0。使用此參數設定時，資料表 foo 與表格 FOO 不同。此範例會驗證參數是否仍處於其預設設定。然後，此範例會建立三個資料表，它們的名稱僅存在大小寫差異。

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 |
+--------------------------+

接下來，我們將資料庫參數群組與叢集建立關聯，以將 lower_case_table_names 參數設定為 1。此變更只會在重新啟動每個資料庫執行個體後生效。

$ 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"
}

我們首先為寫入器資料庫執行個體執行重新啟動。然後，我們等待執行個體再次變成可用。此時，我們會連線到寫入器端點，並確認寫入器執行個體具有變更的參數值。SHOW TABLES 命令確認資料庫包含三個不同的資料表。不過，參考名為 foo Foo、或 FOO 資料表的查詢皆存取名稱為全小寫的資料表 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

現在，使用叢集端點的查詢會顯示參數變更的影響。無論查詢中的資料表名稱是大寫、小寫還是大小寫混合，SQL陳述式都會存取名稱全為小寫的資料表。

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 |
+--------------------------+

下一個範例顯示與前一個查詢相同的查詢。在此情況下，查詢會使用讀取器端點，並在其中一個讀取器資料庫執行個體上執行。這些執行個體尚未重新啟動。因此，它們仍然具有 lower_case_table_names 參數的原始設定。這表示查詢可以存取每個 foo、Foo 和 FOO 資料表。

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 |
+--------------------------+

接下來，我們重新啟動其中一個讀取器執行個體，並等待它再次變成可用。

$ 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

連線到 instance-2470 的執行個體端點時，查詢會顯示新參數有效。

mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
|                        1 |
+--------------------------+

此時，叢集中的兩個讀取器執行個體會以不同的 lower_case_table_names 設定執行。因此，叢集的讀取器端點的任何連線都會使用這個無法預期的設定值。請務必立即重新啟動其他讀取器執行個體，以便兩者都具有一致的設定。

$ 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

下列範例會確認所有讀取器執行個體具有相同的 lower_case_table_names 參數設定。這些命令會檢查每個讀取器執行個體上的 lower_case_table_names 設定值。然後，使用讀取器端點的相同命令會展示每個與讀取器端點的連線都會使用其中一個讀取器執行個體，但哪一個是無法預測的。

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

隨著參數變更套用至所有位置，我們可以看到設定 lower_case_table_names=1 的效果。無論該資料表被稱為 foo、Foo 或 FOO，查詢都會將名稱轉換為 foo，並在每種情況下存取相同的資料表。

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 |
+--------------------------+