# Aurora 再起動オペレーションの例
<a name="USER_Reboot.Examples"></a>

 次の Aurora MySQL の例は、Aurora DB クラスター内のリーダーとライター DB インスタンスの再起動オペレーションのさまざまな組み合わせを示しています。再起動するたびに、SQL クエリはクラスター内のインスタンスの稼働時間を示します。

**Topics**
+ [Aurora クラスターのライターインスタンスとリーダーインスタンスの検索](#USER_Reboot.Examples.IsClusterWriter)
+ [1 つのリーダーインスタンスの再起動](#USER_Reboot.Examples.RebootReader)
+ [ライターインスタンスの再起動](#USER_Reboot.Examples.RebootWriter)
+ [ライターとリーダーの独立した再起動](#USER_Reboot.Examples.RebootAsynch)
+ [Aurora MySQL バージョン 2.10 クラスターへのクラスターパラメータの変更の適用](#USER_Reboot.Examples.ParamChangeNewStyle)

## Aurora クラスターのライターインスタンスとリーダーインスタンスの検索
<a name="USER_Reboot.Examples.IsClusterWriter"></a>

 複数の DB インスタンスを持つ Aurora MySQL クラスターでは、どれがライターで、どれがリーダーであるかを知ることが重要です。ライターインスタンスとリーダーインスタンスは、フェイルオーバーオペレーションが発生したときにロールを切り替えることができます。したがって、ライターまたはリーダーのインスタンスを必要とするオペレーションを実行する前に、次のようなチェックを実行することをお勧めします。この場合、`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
```

 再起動の例を開始する前に、ライターインスタンスの稼働時間は約 1 週間です。この例の SQL クエリは、MySQL 固有の稼働時間をチェックする方法を示しています。この手法は、データベースアプリケーションで使用する場合があります。AWS CLI を使用し、両方の Aurora エンジン用に機能する別のテクニックについては、[Aurora クラスターとインスタンスの稼働時間のチェック](USER_Reboot.Uptime.md) を参照してください。

```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
    -> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
    -> from performance_schema.global_status
    -> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup               | Uptime  |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+
```

## 1 つのリーダーインスタンスの再起動
<a name="USER_Reboot.Examples.RebootReader"></a>

 この例では、リーダーの DB インスタンスの 1 つを再起動します。おそらく、このインスタンスは、大きなクエリまたは多数の同時実行接続によってオーバーロードされた可能性があります。あるいは、ネットワークの問題が原因で、ライターインスタンスに遅れた可能性があります。再起動オペレーションを開始した後、例では、インスタンスが使用可能になるまで一時停止する `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 |
+----------------------------+---------+
```

 リーダーインスタンスを再起動しても、ライターインスタンスの稼働時間には影響しませんでした。まだ約 1 週間の稼働時間があります。

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

## ライターインスタンスの再起動
<a name="USER_Reboot.Examples.RebootWriter"></a>

 この例では、ライターインスタンスを再起動します。このクラスターは Aurora MySQL バージョン 2.09 を実行しています。Aurora MySQL バージョンが 2.10 より低いため、ライターインスタンスを再起動すると、クラスター内のリーダーインスタンスも再起動されます。

 `wait` コマンドは再起動が完了するまで一時停止します。これで、そのインスタンスの稼働時間はゼロにリセットされます。ライター DB インスタンスとリーダー DB インスタンスでは、再起動オペレーションにかかる時間が大幅に異なる場合があります。ライターおよびリーダー DB インスタンスは、ロールに応じて異なる種類のクリーンアップオペレーションを実行します。

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

 ライター DB インスタンスの再起動後、両方のリーダー DB インスタンスの稼働時間がリセットされます。ライターインスタンスを再起動すると、リーダーインスタンスも再起動しました。この動作は、Aurora PostgreSQL クラスターおよびバージョン 2.10 より前の Aurora MySQL クラスターに適用されます。

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

## ライターとリーダーの独立した再起動
<a name="USER_Reboot.Examples.RebootAsynch"></a>

 次の例は、Aurora MySQL バージョン 2.10 を実行するクラスターを示しています。この Aurora MySQL バージョン以降では、すべてのリーダーインスタンスの再起動を行わずにライターインスタンスを再起動できます。これにより、ライターインスタンスを再起動しても、クエリを大量に消費するアプリケーションが停止することはありません。リーダーインスタンスは後で再起動できます。これらの再起動は、クエリトラフィックが少ない時に実行できます。リーダーインスタンスを一度に 1 つずつ再起動することもできます。これにより、アプリケーションのクエリアントラフィックのために、少なくとも 1 つのリーダーインスタンスが常に利用可能になります。

 次の例では、Aurora MySQL バージョン `cluster-2393` を実行している `5.7.mysql_aurora.2.10.0` という名前のクラスターを使用しています。このクラスターには、`instance-9404` という名前のライターインスタンスと、`instance-6772`、`instance-2470`、`instance-5138` という名前の 3 つのリーダーインスタンスがあります。

```
$ 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 を使用すると、実際にインスタンスにログインしなくても、対応する稼働時間の情報を取得できます。これにより、管理者はデータベースをモニタリングできますが、テーブルデータを表示または変更することはできません。この場合、5 分間の期間を指定し、毎分稼働時間の値をチェックします。稼働時間の値の増加は、その期間中にインスタンスが再起動されなかったことを示しています。

```
$ 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` のいずれかを再起動します。再起動後、インスタンスが再び利用可能になるまで待機します。5 分間の稼働時間をモニタリングすると、その間に稼働時間がゼロにリセットされたことがわかります。最新の稼働時間の値は、再起動が完了してから 5 秒後に測定されました。

```
$ 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` の再起動を実行します。ライターインスタンスとリーダーインスタンスの 1 つの稼働時間の値を比較します。これにより、ライターを再起動してもリーダーは再起動されないことがわかります。Aurora MySQL 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
```

 これで、ライター DB インスタンスの稼働時間が最も長いことがわかります。このインスタンスの稼働時間の値は、モニタリング期間を通じて着実に増加しました。リーダー DB インスタンスはすべて、リーダーの後に再起動されました。各リーダーが再起動され、その稼働時間がゼロにリセットされたモニタリング期間内の時点を確認できます。

```
$ 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 MySQL バージョン 2.10 クラスターへのクラスターパラメータの変更の適用
<a name="USER_Reboot.Examples.ParamChangeNewStyle"></a>

 次の例では、Aurora MySQL 2.10 クラスター内のすべての DB インスタンスにパラメータの変更を適用する方法を示します。この Aurora MySQL バージョンでは、ライターインスタンスとすべてのリーダーインスタンスを個別に再起動します。

 この例では、説明のために MySQL 設定パラメータ `lower_case_table_names` を使用します。このパラメータ設定がライターとリーダーの DB インスタンス間で異なる場合、大文字、または大文字と小文字が混在した名前で宣言されたテーブルにクエリがアクセスできないことがあります。または、2 つのテーブル名で異なるのが大文字と小文字のみである場合、クエリが間違ったテーブルにアクセスする可能性があります。

 この例では、各インスタンスの `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` パラメータの変更の影響を示すために、2 つの DB クラスターパラメータグループを設定します。`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` とは区別されます。この例では、パラメータが引き続きデフォルト設定になっていることを確認します。その後、名前の大文字と小文字だけが異なる 3 つのテーブルを作成します。

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

 次に、DB パラメータグループをクラスターに関連付けて、`lower_case_table_names` パラメータを 1 に設定します。この変更は、各 DB インスタンスが再起動された後にのみ有効になります。

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

 実行する最初の再起動は、ライター DB インスタンスのためのものです。その後、インスタンスが再び利用可能になるのを待ちます。その時点で、ライターエンドポイントに接続し、ライターインスタンスに変更されたパラメータ値があることを確認します。`SHOW TABLES` コマンドは、データベースに 3 つの異なるテーブルが含まれていることを確認します。ただし、`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 |
+--------------------------+
```

 次の例は、前のクエリと同じクエリを示しています。この場合、クエリはリーダーエンドポイントを使用し、リーダー DB インスタンスの 1 つで実行されます。それらのインスタンスはまだ再起動されていません。したがって、`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 |
+--------------------------+
```

 次に、リーダーインスタンスの 1 つを再起動し、それが再び利用可能になるまで待機します。

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

 この時点で、クラスター内の 2 つのリーダーインスタンスが異なる `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` 設定値をチェックします。その後、リーダーエンドポイントを使用する同じコマンドで、リーダーエンドポイントへの各接続でリーダーインスタンスの 1 つが使用されることが示されますが、どれを使用するのかは予測できません。

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