Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Anda dapat mencapai ketersediaan tinggi dan membaca penskalaan di Amazon DocumentDB (dengan kompatibilitas MongoDB) dengan menggunakan instans replika. Klaster Amazon DocumentDB tunggal mendukung instans primer tunggal dan hingga 15 instans replika. Instans tersebut dapat didistribusikan di seluruh Availability Zone di dalam Wilayah klaster. Instans primer menerima lalu lintas baca dan tulis, dan instans replika hanya menerima permintaan baca.
Volume kluster dibuat dari beberapa salinan data untuk kluster. Namun demikian, data dalam volume klaster direpresentasikan sebagai volume tunggal yang logis ke instans primer dan replika Amazon DocumentDB dalam klaster. Instans replika pada akhirnya konsisten. Mereka mengembalikan hasil kueri dengan sedikit penundaan replika—biasanya kurang dari 100 milidetik setelah instans primer menulis pembaruan. Lag replika bervariasi bergantung pada laju perubahan basis data. Artinya, selama periode di mana sejumlah besar operasi tulis terjadi untuk basis data, Anda mungkin melihat peningkatan lag replika.
Penskalaan baca
Replika Amazon DocumentDB berfungsi dengan baik untuk penskalaan baca karena didedikasikan sepenuhnya untuk membaca operasi pada volume klaster Anda. Operasi tulis dikelola oleh instans primer. Volume klaster dibagikan di semua instans di klaster Anda. Oleh karena itu, Anda tidak perlu mereplikasi dan mempertahankan salinan data untuk setiap replika Amazon DocumentDB.
Ketersediaan tinggi
Saat Anda membuat klaster Amazon DocumentDB, bergantung pada jumlah Availability Zone dalam grup subnet (harus ada setidaknya dua), Amazon DocumentDB menyediakan instans di seluruh Availability Zone. Ketika Anda membuat instans dalam klaster, Amazon DocumentDB secara otomatis mendistribusikan instans di seluruh Availability Zone dalam grup subnet untuk menyeimbangkan klaster. Tindakan ini juga mencegah semua instans diletakkan di Availability Zone yang sama.
Contoh
Untuk mengilustrasikan intinya, pertimbangkan contoh di mana Anda membuat klaster yang memiliki grup subnet dengan tiga Availability Zones: AZ1, AZ2, dan. AZ3
Ketika instans pertama dalam klaster dibuat, ini adalah instans primer dan terletak di salah satu Availability Zone. Dalam contoh ini, ada di AZ1. Instance kedua yang dibuat adalah instance replika dan terletak di salah satu dari dua Availability Zone lainnya, katakanlah AZ2. Instance ketiga yang dibuat adalah instance replika dan terletak di Availability Zone yang tersisa, AZ3. Jika Anda membuat lebih banyak instans, mereka didistribusikan di seluruh Availability Zone sehingga Anda mencapai keseimbangan dalam klaster.
Jika kegagalan terjadi pada instance utama (AZ1), failover dipicu, dan salah satu replika yang ada dipromosikan ke primer. Ketika primer lama pulih, itu menjadi replika di Availability Zone yang sama di mana ia disediakan (). AZ1 Ketika Anda menyediakan tiga klaster instans, Amazon DocumentDB terus menjaga tiga instans klaster tersebut. Amazon DocumentDB secara otomatis menangani deteksi, failover, dan pemulihan kegagalan instans tanpa intervensi manual apa pun.
Ketika Amazon DocumentDB melakukan failover dan memulihkan instans, instans yang dipulihkan tetap di Availability Zone di mana instans tersebut disediakan pada awalnya. Namun demikian, peran instans mungkin berubah dari primer ke replika. Melakukan hal ini akan mencegah skenario di mana serangkaian failover dapat mengakibatkan semua instans berada di Availability Zone yang sama.
Anda dapat menentukan replika Amazon DocumentDB sebagai target failover. Artinya, jika instans primer gagal, replika Amazon DocumentDB yang ditentukan atau replika dari tingkat dipromosikan menjadi instans primer. Terdapat gangguan singkat selama permintaan baca dan tulis dibuat ke instans primer gagal dengan pengecualian. Jika klaster Amazon DocumentDB Anda tidak mencakup replika Amazon DocumentDB apa pun, ketika instans primer gagal, replika tersebut kembali dibuat. Mempromosikan replika Amazon DocumentDB jauh lebih cepat daripada membuat ulang instans primer.
Untuk skenario dengan ketersediaan tinggi, kami sarankan Anda membuat satu atau lebih replika Amazon DocumentDB. Replika tersebut harus berasal dari kelas instans yang sama dengan instans primer dan dalam Availability Zone yang berbeda untuk klaster Amazon DocumentDB Anda.
Untuk informasi selengkapnya, lihat berikut ini:
Ketersediaan tinggi dengan cluster global
Untuk ketersediaan tinggi di beberapa Wilayah AWS, Anda dapat mengatur klaster global Amazon DocumentDB. Setiap cluster global mencakup beberapa wilayah, memungkinkan pembacaan global latensi rendah dan pemulihan bencana dari pemadaman di seluruh wilayah. Wilayah AWS Amazon DocumentDB secara otomatis menangani replikasi semua data dan pembaruan dari wilayah utama ke masing-masing wilayah sekunder.
Menambahkan replika
Instans pertama yang ditambahkan ke klaster adalah instans primer. Setiap instans yang ditambahkan setelah instans pertama adalah instans replika. Klaster dapat memiliki hingga 15 instans replika di samping instans primer.
Ketika Anda membuat cluster menggunakan AWS Management Console, instance utama secara otomatis dibuat pada saat yang sama. Untuk membuat replika pada saat yang sama seperti saat Anda membuat klaster dan instans primer, pilih Membuat replika di zona yang berbeda. Untuk informasi lebih lanjut, lihat langkah 4.d. di Membuat cluster Amazon DocumentDB. Untuk menambahkan lebih banyak replika untuk klaster Amazon DocumentDB, lihat Menambahkan instance Amazon DocumentDB ke klaster.
Saat menggunakan AWS CLI untuk membuat cluster Anda, Anda harus secara eksplisit membuat instance primer dan replika Anda. Untuk informasi lebih lanjut, lihat bagian “Menggunakan AWS CLI" dalam topik berikut:
Replikasi lag
Lag replikasi biasanya 50ms atau kurang. Alasan paling umum untuk peningkatan lag replika adalah:
-
Tingkat tulis yang tinggi pada primer yang menyebabkan replika baca jatuh di belakang primer.
-
Pertikaian pada replika baca antara kueri yang berjalan lama (misalnya, pindaian sekuensial besar, kueri agregasi) dan replikasi tulis yang masuk.
-
Jumlah kueri bersamaan yang sangat besar pada replika baca.
Untuk meminimalkan lag replikasi, cobalah teknik pemecahan masalah ini:
-
Jika Anda memiliki tingkat penulisan yang tinggi atau CPU pemanfaatan yang tinggi, sebaiknya Anda meningkatkan instance di klaster Anda.
-
Jika terdapat kueri yang berjalan lama pada replika baca Anda, dan sangat sering terdapat pembaruan untuk dokumen yang dikuerikan, pertimbangkan mengubah kueri yang berjalan lama Anda, atau jalankan mereka terhadap replika primer/tulis untuk menghindari perdebatan pada replika baca.
-
Jika ada sejumlah besar kueri bersamaan atau CPU pemanfaatan tinggi hanya pada replika baca, opsi lain adalah memperkecil jumlah replika baca untuk menyebarkan beban kerja.
-
Karena kelambatan replikasi adalah hasil dari throughput penulisan yang tinggi dan kueri yang berjalan lama, kami merekomendasikan pemecahan masalah lag replikasi dengan memanfaatkan metrik DBClusterReplicaLagMaximum CW dalam kombinasi dengan logger kueri lambat dan metrik/.
WriteThroughput
WriteIOPS
Secara umum, kami menyarankan bahwa semua replika Anda adalah dari tipe instans yang sama, sehingga failover klaster tidak akan menyebabkan penurunan performa.
Jika Anda memilih antara menaikkan skala dan menskalakan keluar (misalnya enam instans yang lebih kecil vs tiga instans yang lebih besar), kami umumnya merekomendasikan untuk pertama-tama mencoba menaikkan skala (instans yang lebih besar) sebelum menskalakan keluar, karena Anda akan mendapatkan cache buffer yang lebih besar per instans DB.
Secara proaktif, Anda harus mengatur alarm lag replikasi dan mengatur ambang batasnya untuk nilai yang Anda rasa merupakan batas atas untuk seberapa jauh dapat meninggalkan (atau “menahan”) data Anda pada instans replika sebelum mulai memengaruhi fungsionalitas aplikasi Anda. Secara umum, kami akan menyarankan bahwa ambang batas lag replikasi terlampaui untuk beberapa titik data sebelum menciptakan alarm, akibat beban kerja sementara.
catatan
Selain itu, kami sarankan Anda mengatur alarm lainnya untuk lag replikasi yang melebihi 10 detik. Jika Anda melampaui ambang batas ini untuk beberapa titik data, kami sarankan Anda menaikkan skala instans Anda atau mengurangi throughput tulis Anda pada instans primer.