Mem-boot ulang klaster DB Amazon Aurora atau instans DB Amazon Aurora

Anda mungkin perlu mem-boot ulang klaster DB atau beberapa instans dalam klaster Anda, biasanya karena alasan pemeliharaan. Sebagai contoh, misalkan Anda mengubah parameter dalam grup parameter atau menghubungkan grup parameter lainnya dengan klaster Anda. Dalam kasus ini, Anda harus mem-boot ulang klaster agar perubahan diterapkan. Sama halnya, Anda mungkin mem-boot ulang satu atau beberapa instans DB pembaca dalam klaster. Anda dapat mengatur operasi boot ulang untuk setiap instans guna meminimalkan waktu henti untuk seluruh klaster.

Waktu yang diperlukan untuk mem-boot ulang setiap instans DB dalam klaster Anda bergantung pada aktivitas basis data pada saat boot ulang. Hal ini juga bergantung pada proses pemulihan mesin DB khusus Anda. Jika memungkinkan, kurangi aktivitas basis data pada instans tertentu sebelum memulai proses boot ulang. Opsi ini dapat mengurangi waktu yang diperlukan untuk memulai ulang basis data.

Anda hanya dapat mem-boot ulang setiap instans DB dalam klaster Anda jika status instans tersebut tersedia. Instans DB mungkin tidak tersedia karena beberapa alasan. Alasan ini meliputi klaster dalam status dihentikan, modifikasi sedang diterapkan pada instans, dan tindakan periode pemeliharaan seperti peningkatan versi.

Boot ulang instans DB akan memulai ulang proses mesin basis data. Mem-boot ulang instans DB akan menyebabkan pemadaman sementara, dan selama pemadaman sementara, status instans DB diatur ke mem-boot ulang.

Mem-boot ulang instans DB dalam klaster Aurora

Prosedur ini adalah operasi terpenting yang Anda lakukan saat mem-boot ulang dengan Aurora. Banyak prosedur pemeliharaan yang mewajibkan Anda mem-boot ulang satu atau beberapa instans DB Aurora dalam urutan tertentu.

aws rds reboot-db-instance \
    --db-instance-identifier mydbinstance

aws rds reboot-db-instance ^
    --db-instance-identifier mydbinstance

Mem-boot ulang klaster Aurora dengan ketersediaan baca

Dengan fitur ketersediaan baca, Anda dapat me-reboot instance penulis cluster Aurora Anda tanpa me-reboot instance pembaca di cluster DB primer atau sekunder. Tindakan ini dapat membantu menjaga ketersediaan tinggi klaster untuk operasi baca saat Anda mem-boot ulang instans penulis. Anda dapat mem-boot ulang instans pembaca di lain waktu pada jadwal yang dikehendaki. Misalnya, dalam cluster produksi Anda dapat me-reboot instance pembaca satu per satu, dimulai hanya setelah reboot instance utama selesai. Untuk setiap instans DB yang di-boot ulang, ikuti prosedur di Mem-boot ulang instans DB dalam klaster Aurora.

Fitur ketersediaan baca untuk cluster DB primer tersedia di Aurora MySQL versi 2.10 dan lebih tinggi. Ketersediaan baca untuk cluster DB sekunder tersedia di Aurora MySQL versi 3.06 dan lebih tinggi.

Untuk Aurora PostgreSQL, fitur ini tersedia secara default dalam versi berikut:

Untuk informasi selengkapnya tentang fitur ketersediaan baca di Aurora PostgreSQL, lihat Meningkatkan ketersediaan baca Aurora Replica.

Sebelum fitur ini, me-reboot instance utama menyebabkan reboot untuk setiap instance pembaca secara bersamaan. Jika klaster Aurora Anda menjalankan versi yang lebih lama, gunakan prosedur boot ulang di Mem-boot ulang klaster Aurora tanpa ketersediaan baca.

Anda sering mem-boot ulang klaster setelah menerapkan perubahan pada grup parameter klaster. Anda menerapkan perubahan parameter dengan mengikuti prosedur di Menggunakan grup parameter. Misalkan Anda mem-boot ulang instans penulis DB dalam klaster Aurora untuk menerapkan perubahan pada parameter klaster. Beberapa atau semua instans DB pembaca dapat terus menggunakan pengaturan parameter lama. Namun, pengaturan parameter yang berbeda tidak memengaruhi integritas data klaster. Setiap parameter klaster yang memengaruhi susunan file data hanya digunakan oleh instans DB penulis.

Sebagai contoh, dalam klaster Aurora MySQL, Anda dapat memperbarui parameter klaster seperti binlog_format dan innodb_purge_threads pada instans penulis sebelum instans pembaca. Hanya instans penulis yang menulis log biner dan membersihkan data undo. Untuk parameter yang mengubah cara kueri menafsirkan pernyataan SQL atau output kueri, Anda mungkin perlu segera mem-boot ulang instans pembaca. Dengan demikian, Anda dapat menghindari perilaku aplikasi tak terduga selama kueri. Sebagai contoh, misalkan Anda mengubah parameter lower_case_table_names dan mem-boot ulang instans penulis. Dalam kasus ini, instans pembaca mungkin tidak dapat mengakses tabel yang baru dibuat hingga semua instans di-boot ulang.

Untuk daftar semua parameter klaster Aurora MySQL, lihat Parameter tingkat klaster.

Untuk daftar semua parameter klaster Aurora PostgreSQL, lihat Parameter tingkat klaster Aurora PostgreSQL.

Mem-boot ulang klaster Aurora tanpa ketersediaan baca

Dengan fitur ketersediaan baca, Anda dapat mem-boot ulang seluruh klaster DB Aurora dengan mem-boot ulang instans DB dalam klaster tersebut. Untuk melakukannya, ikuti prosedurnya di Mem-boot ulang instans DB dalam klaster Aurora.

Mem-boot ulang instans DB penulis juga akan memulai boot ulang untuk setiap instans DB pembaca dalam klaster. Dengan begitu, setiap perubahan parameter tingkat klaster diterapkan ke semua instans DB secara bersamaan. Namun, jika semua instans DB di-boot ulang, klaster tersebut akan mengalami pemadaman singkat. Instans DB pembaca tetap tidak tersedia hingga instans DB penulis menyelesaikan boot ulang dan menjadi tersedia.

Perilaku boot ulang ini berlaku untuk semua klaster DB yang dibuat di Aurora MySQL versi 2.09 dan yang lebih rendah.

Untuk Aurora PostgreSQL, perilaku ini berlaku untuk versi berikut:

Dalam konsol RDS, instans DB penulis memiliki nilai Penulis di bawah kolom Peran pada halaman Basis Data. Dalam RDS CLI, output perintah describe-db-clusters mencakup bagian DBClusterMembers. Elemen DBClusterMembers yang mewakili instans DB penulis memiliki nilai true untuk kolom IsClusterWriter.

Memeriksa waktu aktif untuk klaster dan instans Aurora

Anda dapat memeriksa dan memantau jangka waktu sejak boot ulang terakhir untuk setiap instans DB di klaster Aurora Anda. CloudWatch Metrik Amazon EngineUptime melaporkan jumlah detik sejak terakhir kali instans DB dimulai. Anda dapat memeriksa metrik ini pada titik waktu tertentu guna mengetahui waktu aktif instans DB. Anda juga dapat memantau metrik ini dari waktu ke waktu untuk mendeteksi kapan instans di-boot ulang.

Anda juga dapat memeriksa metrik EngineUptime pada tingkat klaster. Dimensi Minimum dan Maximum melaporkan nilai waktu aktif terkecil dan terbesar untuk semua instans DB dalam klaster. Untuk memeriksa waktu terbaru saat setiap instans pembaca dalam klaster di-boot ulang, atau dimulai ulang karena alasan lain, pantau metrik tingkat klaster menggunakan dimensi Minimum. Untuk memeriksa instans dalam klaster telah berjalan paling lama tanpa boot ulang, pantau metrik tingkat klaster menggunakan dimensi Maximum. Sebagai contoh, sebaiknya Anda mengonfirmasi bahwa semua instans DB dalam klaster di-boot ulang setelah perubahan konfigurasi.

Contoh CLI berikut menunjukkan cara memeriksa metrik EngineUptime untuk instans penulis dan pembaca dalam klaster. Contoh tersebut menggunakan sebuah klaster bernama tpch100g. Klaster ini memiliki instans DB penulis instance-1234. Klaster ini juga memiliki dua instans DB pembaca, instance-7448 dan instance-6305.

Pertama, perintah reboot-db-instance mem-boot ulang salah satu instans pembaca. Perintah wait menunggu hingga instans selesai di-boot ulang.

$ 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

CloudWatch get-metric-statisticsPerintah memeriksa EngineUptime metrik selama lima menit terakhir dengan interval satu menit. Waktu aktif untuk instans instance-6305 diatur ulang ke nol dan mulai menghitung ke atas lagi. AWS CLI Contoh untuk Linux ini menggunakan substitusi $() variabel untuk memasukkan stempel waktu yang sesuai ke dalam perintah CLI. Contoh ini juga menggunakan perintah sort Linux untuk mengurutkan output pada saat metrik dikumpulkan. Nilai stempel waktu tersebut adalah kolom ketiga di setiap baris output.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	231.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	291.0	2021-03-16T18:20:00+00:00	Seconds
DATAPOINTS	351.0	2021-03-16T18:21:00+00:00	Seconds
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds

Waktu aktif minimum untuk klaster diatur ulang ke nol karena salah satu instans dalam klaster di-boot ulang. Waktu aktif maksimum untuk klaster tidak diatur ulang karena setidaknya salah satu instans DB dalam klaster tetap tersedia.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Minimum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63099.0	2021-03-16T18:12:00+00:00	Seconds
DATAPOINTS	63159.0	2021-03-16T18:13:00+00:00	Seconds
DATAPOINTS	63219.0	2021-03-16T18:14:00+00:00	Seconds
DATAPOINTS	63279.0	2021-03-16T18:15:00+00:00	Seconds
DATAPOINTS	51.0	2021-03-16T18:16:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63389.0	2021-03-16T18:16:00+00:00	Seconds
DATAPOINTS	63449.0	2021-03-16T18:17:00+00:00	Seconds
DATAPOINTS	63509.0	2021-03-16T18:18:00+00:00	Seconds
DATAPOINTS	63569.0	2021-03-16T18:19:00+00:00	Seconds
DATAPOINTS	63629.0	2021-03-16T18:20:00+00:00	Seconds

Kemudian, perintah reboot-db-instance lainnya mem-boot ulang instans penulis pada klaster. Perintah wait lainnya dijeda hingga instans penulis selesai di-boot ulang.

$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
  "DBInstanceIdentifier": "instance-1234",
  "DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234

Saat ini, metrik EngineUptime untuk instans penulis menunjukkan bahwa instans instance-1234 baru-baru ini di-boot ulang. Instans pembaca instance-6305 juga di-boot ulang secara otomatis bersama dengan instans penulis. Klaster ini menjalankan Aurora MySQL 2.09, yang tidak menjaga instans pembaca tetap berjalan saat instans penulis di-boot ulang.

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	63749.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	63809.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	63869.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	41.0	2021-03-16T18:25:00+00:00	Seconds
DATAPOINTS	101.0	2021-03-16T18:26:00+00:00	Seconds

$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
  --start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
  --period 60 --namespace "AWS/RDS" --statistics Maximum \
  --dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
  | sort -k 3
EngineUptime
DATAPOINTS	411.0	2021-03-16T18:22:00+00:00	Seconds
DATAPOINTS	471.0	2021-03-16T18:23:00+00:00	Seconds
DATAPOINTS	531.0	2021-03-16T18:24:00+00:00	Seconds
DATAPOINTS	49.0	2021-03-16T18:26:00+00:00	Seconds

Contoh operasi boot ulang Aurora

Contoh Aurora MySQL berikut menunjukkan beberapa kombinasi operasi boot ulang untuk instans DB pembaca dan penulis dalam klaster DB Aurora. Setelah setiap boot ulang, kueri SQL menunjukkan waktu aktif untuk instans dalam klaster.

Menemukan instans penulis dan pembaca untuk klaster Aurora

Dalam klaster Aurora MySQL dengan beberapa instans DB, Anda harus mengetahui instans mana yang merupakan instans penulis dan mana yang merupakan instans 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. Kueri SQL dalam contoh ini menunjukkan cara khusus MySQL dalam 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. Klaster ini menjalankan Aurora MySQL versi 2.09. Karena versi Aurora MySQL lebih rendah dari 2.10, mem-boot ulang instans penulis juga akan mem-boot ulang setiap instans pembaca dalam klaster.

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 klaster Aurora PostgreSQL dan Aurora MySQL 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-contoh berikut menunjukkan klaster yang menjalankan Aurora MySQL versi 2.10. Dalam Aurora MySQL versi ini dan yang lebih tinggi, Anda dapat mem-boot ulang instans penulis tanpa menyebabkan boot ulang untuk semua instans 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 sebuah klaster bernama cluster-2393, yang menjalankan Aurora MySQL versi 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 MySQL 2.10, nilai-nilai uptime untuk semua pembaca akan diatur ulang pada waktu 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 klaster ke klaster Aurora MySQL versi 2.10

Contoh berikut menunjukkan cara menerapkan perubahan parameter untuk semua instans DB dalam klaster Aurora MySQL 2.10 Anda. Dengan Aurora MySQL versi ini, Anda mem-boot ulang instans penulis dan semua instans pembaca secara independen.

Contoh ini menggunakan parameter konfigurasi MySQL lower_case_table_names sebagai 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. Baik huruf besar, huruf kecil, maupun gabungan huruf kecil dan besar pada name tabel dalam kueri, pernyataan SQL mengakses tabel yang namanya memiliki huruf kecil semua.

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