Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penerapan cluster DB multi-AZ untuk Amazon RDS

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 database Amazon RDS for MySQL dengan downtime yang dikurangi.

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

Untuk informasi selengkapnya tentang kelas instans DB, lihat DB.

Arsitektur cluster DB 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 describe-db-clustersCLI atau operasi Deskripsikan DBClusters API untuk menemukan informasi ini.

Grup parameter untuk cluster DB 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.

Proxy RDS dengan cluster DB 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 Proksi Amazon RDS Aurora.

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 Aurora 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 CloudWatch alarm Amazon untuk lag replika cluster multi-AZ DB untuk Amazon RDS.

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.

Cuplikan cluster DB multi-AZ

Amazon RDS membuat dan menyimpan cadangan otomatis cluster DB multi-AZ Anda selama jendela pencadangan yang dikonfigurasi. RDS membuat snapshot volume penyimpanan cluster DB Anda, mencadangkan seluruh cluster dan bukan hanya instance individual.

Anda juga dapat mengambil cadangan manual cluster DB multi-AZ Anda. Untuk pencadangan jangka panjang, pertimbangkan untuk mengekspor data snapshot ke Amazon S3. Untuk informasi selengkapnya, lihat Membuat snapshot cluster DB multi-AZ untuk Amazon RDS.

Anda dapat memulihkan klaster DB Multi-AZ ke titik waktu tertentu, membuat klaster DB Multi-AZ baru. Untuk petunjuk, lihat Memulihkan klaster DB Multi-AZ ke waktu tertentu.

Sebagai alternatif, Anda dapat memulihkan snapshot cluster DB multi-AZ ke penerapan Single-AZ atau penerapan instans DB multi-AZ. Untuk petunjuk, lihat Memulihkan dari snapshot klaster DB Multi-AZ ke instans DB.