Deployment klaster basis data Multi-AZ

Penerapan klaster DB multi-AZ adalah mode penyebaran Amazon RDS semisinkron dan ketersediaan tinggi dengan dua instans replika DB yang dapat dibaca. Klaster basis data Multi-AZ memiliki instans basis data penulis dan dua instans basis data pembaca di tiga Zona Ketersediaan terpisah dengan Wilayah AWS yang sama. Klaster basis data Multi-AZ menyediakan ketersediaan tinggi, kapasitas yang meningkat untuk beban kerja baca, dan latensi tulis yang lebih rendah jika dibandingkan dengan deployment instans basis data Multi-AZ.

Anda dapat mengimpor data dari basis data on-premise ke klaster basis data Multi-AZ dengan mengikuti petunjuk di Mengimpor data ke basis data Amazon RDS MariaDB atau MySQL dengan lebih sedikit waktu henti.

Anda dapat membeli instans basis data cadangan untuk klaster basis data Multi-AZ. Untuk informasi selengkapnya, lihat Instans DB terpesan untuk klaster DB Multi-AZ.

Ketersediaan dan dukungan fitur bervariasi di seluruh versi spesifik dari setiap mesin basis data, dan di seluruh Wilayah AWS. Lihat informasi yang lebih lengkap tentang versi dan ketersediaan Wilayah Amazon RDS dengan klaster basis data Multi-AZ di Daerah yang Didukung dan engine DB untuk cluster DB multi-AZ di Amazon RDS.

Ketersediaan kelas instans untuk cluster DB multi-AZ

Penerapan cluster DB multi-AZ didukung untuk kelas instans DB berikut:db.m5d,db.m6gd,db.m6id,,db.m6idn, db.r5ddb.r6gd, dan db.x2iedndb.r6id, dandb.r6idn. db.c6gd

Lihat informasi lebih lanjut tentang kelas instans basis data di Kelas instans DB .

Ikhtisar klaster basis data Multi-AZ

Dengan klaster basis data Multi-AZ, Amazon RDS mereplikasi data dari instans basis data penulis ke kedua instans basis data pembaca dengan menggunakan kemampuan replikasi asli mesin basis data. Ketika perubahan dibuat pada instans basis data penulis, perubahan itu dikirim ke setiap instans basis data pembaca.

Deployment klaster basis data Multi-AZ menggunakan replikasi semisinkron, yang memerlukan pengakuan dari setidaknya satu instans basis data pembaca agar perubahan dapat di-commit. Deployment tidak memerlukan pengakuan bahwa peristiwa telah dieksekusi dan di-commit sepenuhnya pada semua replika.

Instans basis data pembaca bertindak sebagai target failover otomatis dan juga melayani lalu lintas baca untuk meningkatkan throughput baca aplikasi. Jika pemadaman terjadi pada instans basis data penulis, RDS mengelola failover ke salah satu instans basis data pembaca. RDS melakukan pemindahan berdasarkan instans basis data pembaca yang memiliki catatan perubahan terbaru.

Diagram berikut menunjukkan sebuah klaster basis data Multi-AZ.

Klaster basis data Multi-AZ biasanya memiliki latensi penulisan yang lebih rendah jika dibandingkan dengan deployment instans basis data Multi-AZ. Klaster itu juga memungkinkan beban kerja hanya baca berjalan pada instans basis data pembaca. Konsol RDS menunjukkan Zona Ketersediaan instans basis data penulis dan Zona Ketersediaan instans basis data pembaca. Anda juga dapat menggunakan perintah CLI describe-db-clusters atau operasi API DescribeDBClusters untuk menemukan informasi ini.

Mengelola cluster DB Multi-AZ dengan AWS Management Console

Anda dapat mengelola klaster basis data Multi-AZ dengan konsol.

Gambar berikut menunjukkan klaster basis data Multi-AZ di konsol.

Tindakan-tindakan yang tersedia di menu Tindakan bergantung pada apakah yang dipilih klaster basis data Multi-AZ atau instans basis data di klaster itu.

Pilih klaster basis data Multi-AZ untuk melihat detail klaster dan melakukan tindakan di tingkat klaster.

Pilih instans basis data di klaster basis data Multi-AZ untuk melihat detail instans basis data dan melakukan tindakan pada tingkat instans basis data.

Bekerja dengan grup parameter untuk klaster basis data Multi-AZ

Di klaster basis data Multi-AZ, sebuah grup parameter klaster basis data bertindak sebagai kontainer untuk nilai-nilai konfigurasi mesin yang diterapkan pada setiap instans basis data di klaster basis data Multi-AZ.

Di klaster basis data Multi-AZ, grup parameter basis data diatur ke grup parameter basis data default untuk mesin basis data dan versi mesin basis datanya. Setelan dalam grup parameter klaster basis data digunakan untuk semua instans basis data di klaster.

Lihat informasi tentang grup parameter di Menggunakan grup parameter klaster DB untuk klaster DB Multi-AZ.

Memutakhirkan versi mesin klaster basis data Multi-AZ

Amazon RDS menyediakan versi-versi baru untuk setiap mesin basis data yang didukung sehingga Anda dapat selalu memperbarui klaster basis data Multi-AZ Anda. Ketika Amazon RDS mendukung versi baru mesin basis data, Anda dapat memilih cara dan waktu harus memutakhirkan klaster basis data Multi-AZ Anda.

Ada dua jenis pemutakhiran yang dapat Anda lakukan:

Saat ini, Amazon RDS mendukung pemutakhiran versi utama hanya untuk klaster basis data Multi-AZ RDS for PostgreSQL. Amazon RDS mendukung peningkatan versi kecil untuk semua mesin basis data yang mendukung klaster basis data Multi-AZ.

Amazon RDS tidak memutakhirkan secara otomatis replika baca klaster basis data Multi-AZ. Untuk pemutakhiran versi kecil, Anda harus memutakhirkan dahulu semua replika baca secara manual, lalu memutakhirkan klaster. Jika tidak, pemutakhiran diblokir. Saat Anda melakukan pemutakhiran versi utama sebuah klaster, keadaan replikasi semua replika baca berubah ke dihentikan. Anda harus menghapus dan membuat ulang replika baca setelah pemutakhiran selesai. Untuk informasi selengkapnya, lihat Memantau replikasi baca.

Proses untuk memutakhirkan versi mesin klaster basis data Multi-AZ sama dengan proses untuk memutakhirkan versi mesin instans basis data. Untuk petunjuk, lihat Meningkatkan versi mesin instans DB. Satu-satunya perbedaan adalah bahwa ketika menggunakan AWS Command Line Interface (AWS CLI), Anda menggunakan perintah modify-db-cluster dan menentukan --db-cluster-identifier parameter (bersama dengan parameter). --allow-major-version-upgrade

Lihat informasi yang lebih lengkap tentang pemutakhiran versi utama dan kecil dalam dokumentasi berikut untuk mesin basis data Anda:

Menggunakan Proksi RDS dengan klaster basis data Multi-AZ

Anda dapat menggunakan Proksi Amazon RDS untuk membuat proksi bagi klaster basis data Multi-AZ. Dengan menggunakan Proksi RDS, aplikasi Anda dapat mengumpulkan dan berbagi koneksi basis data untuk meningkatkan kemampuan menskalakan. Setiap proksi melakukan pembentukan multipleks koneksi, yang juga disebut dengan penggunaan ulang koneksi. Dengan multipleks, Proksi RDS melakukan semua operasi untuk sebuah transaksi dengan menggunakan satu koneksi basis data yang mendasari. Proksi RDS juga dapat mengurangi waktu henti untuk pemutakhiran versi kecil suatu klaster basis data Multi-AZ ke satu detik atau kurang. Lihat informasi yang lebih lengkap tentang manfaat-manfaat Proksi RDS di Menggunakan Proksi Amazon RDS.

Untuk menyiapkan proksi bagi klaster basis data Multi-AZ, pilih Buat Proksi RDS saat membuat klaster. Untuk petunjuk membuat dan mengelola titik akhir Proksi RDS, lihat Bekerja dengan titik akhir Proksi Amazon RDS.

Kelambatan replika dan klaster basis data Multi-AZ

Kelambatan replika adalah selisih waktu antara transaksi terbaru pada instans basis data penulis dan transaksi terbaru yang diterapkan pada instans basis data pembaca. CloudWatch Metrik Amazon ReplicaLag mewakili perbedaan waktu ini. Untuk informasi selengkapnya tentang CloudWatch metrik, lihatMemantau metrik Amazon RDS dengan Amazon CloudWatch.

Meskipun klaster basis data Multi-AZ memungkinkan performa tulis yang tinggi, kelambatan replika masih dapat terjadi karena sifat replikasi berbasis mesin. Karena setiap failover harus menyelesaikan dahulu kelambatan replika sebelum mempromosikan instans basis data penulis baru, memantau dan mengelola kelambatan replika ini menjadi sebuah pertimbangan.

Untuk klaster basis data Multi-AZ RDS for MySQL, waktu failover bergantung pada kelambatan replika kedua instans basis data pembaca yang tersisa. Kedua instans basis data pembaca harus menerapkan transaksi yang belum diterapkan sebelum salah satunya dipromosikan menjadi instans basis data penulis baru.

Untuk klaster basis data Multi-AZ RDS for PostgreSQL, waktu failover bergantung pada kelambatan replika terendah dari dua instans basis data pembaca yang tersisa. Instans basis data pembaca dengan kelambatan replika terendah harus menerapkan transaksi yang belum diterapkan sebelum dipromosikan menjadi instans basis data penulis baru.

Untuk tutorial yang menunjukkan cara membuat CloudWatch alarm saat lag replika melebihi jumlah waktu yang ditentukan, lihatTutorial: Membuat alarm Amazon CloudWatch untuk kelambatan replika klaster basis data Multi-AZ.

Penyebab umum kelambatan replika

Secara umum, kelambatan replika terjadi ketika beban kerja tulis terlalu tinggi bagi instans basis data pembaca untuk menerapkan transaksi dengan efisien. Berbagai beban kerja dapat menimbulkan kelambatan replika sementara atau sinambung. Berikut beberapa contoh penyebab umum:

Mengurangi kelambatan replika

Untuk klaster-klaster basis data Multi-AZ RDS for MySQL dan RDS for PostgreSQL, Anda dapat mengurangi kelambatan replika dengan mengurangi beban pada instans basis data penulis. Anda juga dapat menggunakan kontrol aliran untuk mengurangi kelambatan replika. Kontrol aliran bekerja dengan melakukan throttling operasi tulis pada instans basis data penulis, yang memastikan bahwa kelambatan replika tidak terus tumbuh tanpa batas. Throttling tulis dilakukan dengan menambahkan penundaan ke akhir transaksi, yang mengurangi throughput tulis pada instans basis data penulis. Meskipun tidak menjamin hilangnya kelambatan, kontrol aliran dapat membantu mengurangi kelambatan keseluruhan dalam banyak beban kerja. Bagian-bagian berikut memberikan informasi tentang cara menggunakan kontrol aliran dengan RDS for MySQL dan RDS for PostgreSQL.

Mengurangi kelambatan replika dengan kontrol aliran untuk RDS for MySQL

Bila Anda menggunakan klaster basis data Multi-AZ RDS for MySQL, kontrol aliran diaktifkan secara default dengan menggunakan parameter dinamis rpl_semi_sync_master_target_apply_lag. Parameter ini menentukan batas atas yang Anda inginkan untuk kelambatan replika. Saat kelambatan replika mendekati batas yang dikonfigurasikan ini, kontrol aliran membatasi transaksi tulis pada instans basis data penulis untuk mencoba mempertahankan kelambatan replika di bawah nilai yang ditentukan. Dalam beberapa kasus, kelambatan replika dapat melebihi batas yang ditentukan. Secara default, parameter ini diatur ke 120 detik. Untuk mematikan kontrol aliran, atur parameter ini ke nilai maksimumnya 86.400 detik (satu hari).

Untuk melihat penundaan saat ini yang disuntikkan oleh kontrol aliran, tampilkan parameter Rpl_semi_sync_master_flow_control_current_delay dengan menjalankan kueri berikut.

SHOW GLOBAL STATUS like '%flow_control%';

Output-nya semestinya mirip dengan yang berikut.

+-------------------------------------------------+-------+
| Variable_name                                   | Value |
+-------------------------------------------------+-------+
| Rpl_semi_sync_master_flow_control_current_delay | 2010  |
+-------------------------------------------------+-------+
1 row in set (0.00 sec)

Jika Wawasan Performa diaktifkan untuk klaster basis data Multi-AZ RDS for MySQL, Anda dapat memantau peristiwa tunggu yang bersangkutan dengan suatu pernyataan SQL yang menunjukkan bahwa kueri ditunda oleh kontrol aliran. Saat penundaan dikenakan oleh kontrol aliran, Anda dapat melihat peristiwa tunggu /wait/synch/cond/semisync/semi_sync_flow_control_delay_cond yang bersangkutan dengan pernyataan SQL itu di dasbor Wawasan Performa. Untuk melihat semua metrik ini, pastikan bahwa Skema Performa diaktifkan. Lihat informasi tentang Wawasan Performa di Memantau muatan DB dengan Wawasan Performa di Amazon RDS.

Mengurangi kelambatan replika dengan kontrol aliran untuk RDS for PostgreSQL

Saat Anda menggunakan klaster basis data Multi-AZ RDS for PostgreSQL, kontrol aliran digunakan sebagai ekstensi. Kontrol mengaktifkan pekerja latar belakang untuk semua instans basis data dalam klaster basis data. Secara default, pekerja latar belakang pada instans basis data pembaca mengomunikasikan kelambatan replika saat ini dengan pekerja latar belakang pada instans basis data penulis. Jika kelambatan melebihi dua menit pada sebarang instans basis data pembaca, pekerja latar belakang pada instans basis data penulis menambahkan penundaan di akhir transaksi. Untuk mengendalikan ambang batas kelambatan, gunakan parameter flow_control.target_standby_apply_lag.

Saat kontrol aliran membatasi proses PostgreSQL, peristiwa tunggu Extension di pg_stat_activity dan Wawasan Performa menunjukkan hal itu. Fungsi get_flow_control_stats menampilkan detail lama penundaan yang saat ini ditambahkan.

Kontrol aliran dapat menguntungkan sebagian besar beban kerja pemrosesan transaksi online (OLTP) yang memiliki transaksi singkat tetapi sangat konkuren. Jika kelambatan disebabkan oleh transaksi yang berjalan lama, seperti operasi tumpak/batch, kontrol aliran tidak memberikan manfaat yang sama besarnya.

Anda dapat mematikan kontrol aliran dengan menghapus ekstensi dari shared_preload_libraries dan mem-boot ulang instans basis data Anda.

Proses failover untuk klaster basis data Multi-AZ

Jika ada pemadaman terencana atau tidak terencana instans basis data dalam klaster basis data Multi-AZ, Amazon RDS akan melakukan failover ke instans basis data pembaca di Zona Ketersediaan yang berbeda. Waktu yang diperlukan untuk menyelesaikan failover bergantung pada aktivitas basis data dan kondisi-kondisi lain ketika instans basis data penulis tidak tersedia. Durasi failover biasanya kurang dari 35 detik. Failover selesai ketika kedua instans basis data pembaca telah menerapkan transaksi tertunggak dari penulis yang gagal. Setelah failover selesai, mungkin perlu beberapa waktu sebelum konsol RDS dapat mencerminkan Zona Ketersediaan baru.

Failover otomatis

Amazon RDS menangani secara otomatis failover sehingga Anda dapat melanjutkan operasi basis data secepat mungkin tanpa campur tangan administratif. Agar dapat failover, instans basis data penulis beralih secara otomatis ke instans basis data pembaca.

Melakukan failover secara manual klaster basis data Multi-AZ

Jika Anda gagal secara manual melalui cluster DB multi-AZ, RDS pertama-tama menghentikan instans DB utama. Kemudian, sistem pemantauan internal mendeteksi bahwa instans DB primer tidak sehat dan mempromosikan instance DB replika yang dapat dibaca. Durasi failover biasanya kurang dari 35 detik.

Anda dapat gagal melalui cluster DB multi-AZ secara manual menggunakan AWS Management Console, AWS CLI, atau RDS API.

aws rds failover-db-cluster --db-cluster-identifier mymultiazdbcluster

Menentukan apakah klaster basis data Multi-AZ sudah failover

Untuk mengetahui apakah klaster basis data Multi-AZ Anda sudah failover, Anda dapat melakukan hal-hal berikut:

Lihat informasi tentang cara merespons failover, mengurangi waktu pemulihan, dan praktik-praktik terbaik lain untuk Amazon RDS di Praktik terbaik untuk Amazon RDS.

Mengatur TTL JVM untuk pencarian nama DNS

Mekanisme failover mengubah secara otomatis catatan Sistem Nama Domain (DNS) dari instans basis data untuk menunjuk ke instans basis data pembaca. Alhasil, Anda perlu membentuk kembali koneksi yang ada dengan instans basis data Anda. Di lingkungan mesin virtual Java (JVM), karena cara kerja mekanisme caching DNS Java, Anda mungkin perlu mengonfigurasi ulang pengaturan JVM.

JVM menyimpan cache pencarian nama DNS. Ketika JVM menyelesaikan nama host ke alamat IP, JVM menyimpan cache alamat IP untuk jangka waktu tertentu, yang disebut time-to-live (TTL).

Karena AWS sumber daya menggunakan entri nama DNS yang terkadang berubah, kami sarankan Anda mengonfigurasi JVM Anda dengan nilai TTL tidak lebih dari 60 detik. Hal ini dapat memastikan bahwa ketika alamat IP sumber daya berubah, aplikasi Anda dapat menerima dan menggunakan alamat IP baru sumber daya dengan mengueri ulang DNS.

Pada beberapa konfigurasi Java, TTL default JVM diatur untuk tidak pernah menyegarkan entri DNS hingga JVM dimulai ulang. Jadi, jika alamat IP untuk AWS sumber daya berubah saat aplikasi Anda masih berjalan, itu tidak dapat menggunakan sumber daya itu sampai Anda secara manual me-restart JVM dan informasi IP cache di-refresh. Dalam kasus ini, mengatur TTL JVM adalah penting agar fungsi itu menyegarkan secara berkala informasi IP yang tersimpan dalam cache.

Untuk mengubah TTL JVM, atur nilai properti networkaddress.cache.ttl. Gunakan salah satu metode berikut, tergantung pada kebutuhan Anda: