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.

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

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