Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Contoh operasi boot ulang Aurora
SQLContoh Aurora My berikut menunjukkan kombinasi operasi reboot yang berbeda untuk instance DB pembaca dan penulis dalam cluster Aurora DB. Setelah setiap reboot, SQL kueri mendemonstrasikan waktu aktif untuk instance di cluster.
**Topics**
+ [Menemukan instans penulis dan pembaca untuk klaster Aurora](#USER_Reboot.Examples.IsClusterWriter)
+ [Mem-boot ulang satu instans pembaca](#USER_Reboot.Examples.RebootReader)
+ [Mem-boot ulang instans penulis](#USER_Reboot.Examples.RebootWriter)
+ [Mem-boot ulang penulis dan pembaca secara independen](#USER_Reboot.Examples.RebootAsynch)
+ [Menerapkan perubahan parameter cluster ke cluster Aurora My SQL version 2.10](#USER_Reboot.Examples.ParamChangeNewStyle)
## Menemukan instans penulis dan pembaca untuk klaster Aurora
Dalam SQL cluster Aurora My dengan beberapa instance DB, penting untuk mengetahui mana yang menjadi penulis dan mana yang pembaca. Instans penulis dan pembaca juga dapat beralih peran ketika terjadi operasi failover. Maka, sangat disarankan untuk memeriksa hal berikut sebelum melakukan operasi apa pun yang membutuhkan instans penulis atau pembaca. Dalam kasus ini, nilai `False` untuk `IsClusterWriter` mengidentifikasi instans pembaca, `instance-6305` dan `instance-7448`. Nilai `True` mengidentifikasi instans penulis, `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
```
Sebelum kita memulai contoh boot ulang, instans penulis memiliki waktu aktif sekitar satu minggu. SQLKueri dalam contoh ini menunjukkan cara SQL spesifik Saya untuk memeriksa waktu aktif. Anda dapat menggunakan teknik ini dalam aplikasi basis data. Untuk teknik lain yang menggunakan AWS CLI dan bekerja untuk kedua mesin Aurora, lihat. [Memeriksa waktu aktif untuk klaster dan instans 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|
+----------------------------+---------+
```
## Mem-boot ulang satu instans pembaca
Contoh ini mem-boot ulang salah satu instans DB pembaca. Mungkin instans ini mengalami kelebihan beban oleh kueri besar atau banyak koneksi bersamaan. Atau mungkin tertinggal di belakang instans penulis karena masalah jaringan. Setelah memulai operasi boot ulang, contoh tersebut menggunakan perintah `wait` untuk menjeda hingga instans menjadi tersedia. Pada saat itu, instans memiliki waktu aktif beberapa menit.
```
$ 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 |
+----------------------------+---------+
```
Boot ulang instans pembaca tidak memengaruhi waktu aktif instans penulis. Instans ini tetap memiliki waktu aktif sekitar satu minggu.
```
$ 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 |
+----------------------------+----------+
```
## Mem-boot ulang instans penulis
Contoh ini mem-boot ulang instans penulis. Cluster ini menjalankan Aurora My SQL versi 2.09. Karena SQL versi Aurora My lebih rendah dari 2.10, me-reboot instance writer juga me-reboot instance pembaca apa pun di cluster.
Perintah `wait` dijeda hingga proses boot ulang selesai. Sekarang, waktu aktif untuk instans tersebut diatur ulang ke nol. Ada kemungkinan bahwa operasi boot ulang mungkin memakan waktu yang sangat berbeda untuk instans DB penulis dan pembaca. Instans DB penulis dan pembaca melakukan berbagai jenis operasi pembersihan bergantung pada perannya.
```
$ 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 |
+----------------------------+---------+
```
Setelah instans DB penulis di-boot ulang, waktu aktif kedua instans DB pembaca juga akan diatur ulang. Mem-boot ulang instans penulis juga menyebabkan instans pembaca di-boot ulang. Perilaku ini berlaku untuk cluster Aurora Postgre dan Aurora SQL My SQL cluster sebelum versi 2.10.
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+
```
## Mem-boot ulang penulis dan pembaca secara independen
Contoh berikutnya menunjukkan cluster yang menjalankan Aurora My SQL versi 2.10. Dalam SQL versi Aurora My ini dan yang lebih tinggi, Anda dapat me-reboot instance penulis tanpa menyebabkan reboot untuk semua instance pembaca. Dengan demikian, aplikasi padat kueri Anda tidak mengalami pemadaman saat Anda mem-boot ulang instans penulis. Anda dapat mem-boot ulang instans pembaca di lain waktu. Anda juga dapat melakukan beberapa boot ulang saat lalu lintas kueri rendah. Anda juga dapat mem-boot ulang beberapa instans pembaca satu per satu. Dengan demikian, setidaknya satu instans pembaca selalu tersedia untuk lalu lintas kueri aplikasi Anda.
Contoh berikut menggunakan cluster bernama`cluster-2393`, menjalankan Aurora versi SayaSQL. `5.7.mysql_aurora.2.10.0` Klaster ini memiliki instans penulis bernama `instance-9404` dan tiga instans pembaca bernama `instance-6772`, `instance-2470`, dan `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
```
Memeriksa nilai `uptime` dari setiap instans basis data melalui perintah `mysql` menunjukkan bahwa setiap instans memiliki waktu aktif yang kurang lebih sama. Contoh berikut adalah uptime untuk `instance-5138`.
```
mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 3866 |
+---------------+-------+
```
Dengan menggunakan CloudWatch, kita bisa mendapatkan informasi uptime yang sesuai tanpa benar-benar masuk ke instance. Dengan demikian, administrator dapat memantau basis data, tetapi tidak dapat melihat atau mengubah data tabel. Dalam hal ini, kita menentukan jangka waktu selama lima menit, dan memeriksa nilai waktu aktif setiap menit. Peningkatan nilai waktu aktif menunjukkan bahwa instans tidak dimulai ulang selama periode tersebut.
```
$ 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
```
Sekarang kita mem-boot ulang salah satu instans pembaca, `instance-5138`. Kita tunggu instans tersedia lagi setelah boot ulang. Sekarang, pemantauan waktu aktif selama jangka waktu lima menit menunjukkan bahwa waktu aktif diatur ulang ke nol selama waktu tersebut. Nilai waktu aktif terbaru diukur lima detik setelah boot ulang selesai.
```
$ 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
```
Selanjutnya, kita lakukan boot ulang untuk instans penulis, `instance-9404`. Kita bandingkan nilai waktu aktif untuk instans penulis dan salah satu instans pembaca. Dengan demikian, kita dapat melihat bahwa mem-boot ulang penulis tidak akan mem-boot ulang pembaca. Dalam versi sebelum Aurora My SQL 2.10, nilai uptime untuk semua pembaca akan diatur ulang pada saat yang sama dengan penulis.
```
$ 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
```
Untuk memastikan bahwa semua instans pembaca memiliki semua perubahan pada parameter konfigurasi yang sama dengan instans penulis, boot ulang seluruh instans pembaca setelah penulis. Contoh ini mem-boot ulang semua pembaca, lalu menunggu hingga semua pembaca tersedia sebelum melanjutkan.
```
$ 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
```
Sekarang kita dapat melihat bahwa instans DB penulis memiliki waktu aktif tertinggi. Nilai waktu aktif instans ini meningkat dengan stabil selama periode pemantauan. Semua instans DB pembaca di-boot ulang setelah pembaca. Kita dapat melihat titik dalam periode pemantauan saat setiap pembaca di-boot ulang dan waktu aktif-nya diatur ulang ke nol.
```
$ 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
```
## Menerapkan perubahan parameter cluster ke cluster Aurora My SQL version 2.10
Contoh berikut menunjukkan cara menerapkan perubahan parameter ke semua instance DB di cluster Aurora My 2.10 Anda. SQL Dengan SQL versi Aurora My ini, Anda me-reboot instance penulis dan semua instance pembaca secara independen.
Contoh menggunakan parameter SQL konfigurasi Saya `lower_case_table_names` untuk ilustrasi. Jika pengaturan parameter ini berbeda antara instans DB penulis dan pembaca, kueri mungkin tidak dapat mengakses tabel yang dinyatakan dengan nama dalam huruf besar atau campuran huruf besar dan kecil. Atau, jika dua nama tabel hanya berbeda dari segi huruf besar dan huruf kecil, kueri mungkin mengakses tabel yang salah.
Contoh ini menunjukkan cara menentukan instans penulis dan pembaca dalam klaster dengan memeriksa atribut `IsClusterWriter` pada setiap instans. Klaster ini bernama `cluster-2393`. Klaster ini memiliki satu instans penulis bernama `instance-9404`. Instans pembaca dalam klaster tersebut bernama `instance-5138` dan `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
```
Untuk menunjukkan efek dari perubahan parameter `lower_case_table_names`, kita mengatur dua grup parameter klaster DB. Parameter dari grup parameter `lower-case-table-names-0` ini diatur ke 0. Grup parameter dari grup parameter `lower-case-table-names-1` ini diatur ke 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"
}
```
Nilai default `lower_case_table_names` adalah 0. Dengan pengaturan parameter ini, tabel `foo` berbeda dengan tabel `FOO`. Contoh ini memverifikasi bahwa parameter tersebut masih memiliki pengaturan default. Kemudian, contoh tersebut membuat tiga tabel yang hanya berbeda dari segi huruf besar dan huruf kecil dalam namanya.
```
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 |
+--------------------------+
```
Selanjutnya, kita mengaitkan grup parameter DB dengan klaster untuk mengatur parameter `lower_case_table_names` ke 1. Perubahan ini hanya diterapkan setelah setiap instans DB di-boot ulang.
```
$ 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"
}
```
Boot ulang pertama yang kita lakukan adalah untuk instans DB penulis. Kemudian, kita tunggu hingga instans tersedia lagi. Pada saat itu, kita terhubung ke titik akhir penulis dan memverifikasi bahwa nilai parameter instans penulis berubah. Perintah `SHOW TABLES` menegaskan bahwa basis data berisi tiga tabel yang berbeda. Namun, semua kueri yang merujuk ke tabel bernama `foo`, `Foo`, atau `FOO` mengakses tabel yang namanya berisi huruf kecil semua, `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
```
Sekarang, kueri yang menggunakan titik akhir klaster menunjukkan efek dari perubahan parameter. Apakah nama tabel dalam kueri adalah huruf besar, huruf kecil, atau huruf campuran, SQL pernyataan mengakses tabel yang namanya semua huruf kecil.
```
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 |
+--------------------------+
```
Contoh berikutnya menunjukkan kueri yang sama seperti sebelumnya. Dalam hal ini, kueri menggunakan titik akhir pembaca dan berjalan di salah satu instans DB pembaca. Instans tersebut belum di-boot ulang. Dengan demikian, kueri tersebut masih memiliki pengaturan awal untuk parameter `lower_case_table_names`. Hal ini berarti bahwa kueri dapat mengakses setiap tabel `foo`, `Foo`, dan `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 |
+--------------------------+
```
Selanjutnya, kita mem-boot ulang salah satu instans pembaca dan menunggu hingga instans tersebut tersedia lagi.
```
$ 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
```
Selagi terhubung ke titik akhir instans untuk `instance-2470`, satu kueri menunjukkan bahwa parameter baru sedang diterapkan.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
```
Pada titik ini, dua instans pembaca dalam klaster sedang berjalan dengan pengaturan `lower_case_table_names` yang berbeda. Dengan demikian, setiap koneksi ke titik akhir pembaca dalam klaster menggunakan nilai untuk pengaturan yang tidak dapat diprediksi ini. Instans pembaca lain juga perlu segera di-boot ulang agar keduanya memiliki pengaturan yang konsisten.
```
$ 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
```
Contoh berikut menegaskan bahwa semua instans pembaca memiliki pengaturan yang sama untuk parameter `lower_case_table_names`. Perintah ini memeriksa nilai pengaturan `lower_case_table_names` pada setiap instans pembaca. Kemudian, perintah yang sama yang menggunakan titik akhir pembaca menunjukkan bahwa setiap koneksi ke titik akhir pembaca menggunakan salah satu instans pembaca, tetapi tidak dapat memprediksi instans yang mana.
```
# 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 |
+--------------------------+--------------------------+
```
Dengan perubahan parameter yang diterapkan di mana-mana, kita dapat melihat efek pengaturan `lower_case_table_names=1`. Baik tabel ini disebut sebagai `foo`, `Foo`, maupun `FOO`, kueri akan mengonversi nama menjadi `foo` dan mengakses tabel yang sama dalam setiap kasus.
```
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 |
+--------------------------+
```