Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Ketersediaan Tinggi dan Replikasi Amazon DocumentDB
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. Lager replika bervariasi tergantung 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 Yang 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 cluster yang memiliki grup subnet dengan tiga Availability Zone: AZ1,AZ2, danAZ3.
Ketika instans pertama dalam klaster dibuat, ini adalah instans primer dan terletak di salah satu Availability Zone. Dalam contoh ini, instans berada di AZ1. Instans kedua yang dibuat adalah instans replika dan terletak di salah satu dari dua Availability Zone lainnya, yaitu AZ2. Instans ketiga yang dibuat adalah instans 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 terjadi kegagalan dalam instans primer (AZ1), failover dipicu, dan salah satu replika yang ada dipromosikan ke primer. Ketika primer yang lama pulih, maka menjadi replika di Availability Zone yang sama di mana replika tersebut 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 yang berikut:
Ketersediaan Tinggi dengan Cluster Global
Untuk ketersediaan tinggi di beberapaWilayah AWS, Anda dapat mengaturKlaster global Amazon DocumentDB. Setiap klaster global mencakup beberapa wilayah, yang memungkinkan pembacaan global dengan latensi rendah dan pemulihan bencana dari pemadaman di seluruhWilayah AWS. Amazon DocumentDB secara otomatis menangani replikasi semua data dan pembaruan dari wilayah primer ke setiap 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 kluster menggunakan AWS Management Console, instans primer secara otomatis dibuat pada waktu 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 cluster.
Saat menggunakan AWS CLI untuk membuat klaster Anda, Anda harus secara eksplisit membuat instans primer dan instans replika Anda. Untuk informasi selengkapnya, lihat bagian "Menggunakan AWS CLI" dalam topik berikut ini:
Lag Replikasi
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 tulis tinggi atau utilisasi CPU yang tinggi, kami sarankan Anda meningkatkan instans 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 terdapat jumlah kueri bersamaan yang sangat besar atau utilisasi CPU yang tinggi hanya pada replika baca, pilihan lainnya adalah untuk menskalakan keluar jumlah replika baca untuk menyebarkan beban kerja.
-
Karena lag replikasi adalah hasil dari throughput tulis yang tinggi dan kueri yang berjalan lama, kami sarankan untuk memecahkan masalah lag replikasi dengan memanfaatkan metrik DBClusterReplicaLagMaximum CW dalam kombinasi dengan logger kueri yang 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.
