Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Amazon DocumentDB Ketersediaan dan replikasi tinggi
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:
+ [Memahami toleransi kesalahan klaster Amazon DocumentDB](db-cluster-fault-tolerance.md)
+ [Failover Amazon DocumentDB](failover.md)
+ [Mengontrol target failover](failover.md#failover-target_control)
### Ketersediaan tinggi dengan cluster global
Untuk ketersediaan tinggi di beberapa Wilayah AWS, Anda dapat mengatur klaster global [Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html). 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 Konsol Manajemen AWS, 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](db-cluster-create.md). Untuk menambahkan lebih banyak replika untuk klaster Amazon DocumentDB, lihat [Menambahkan instance Amazon DocumentDB ke klaster](db-instance-add.md).
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:
+ [Membuat cluster Amazon DocumentDB](db-cluster-create.md)
+ [Menambahkan instance Amazon DocumentDB ke klaster](db-instance-add.md)
# Failover Amazon DocumentDB
Dalam kasus tertentu, seperti jenis tertentu dari pemeliharaan yang direncanakan, atau peristiwa simpul primer yang tidak dimungkinkan node utama atau kegagalan Availability Zone, Amazon DocumentDB (dengan kompatibilitas MongoDB) mendeteksi kegagalan dan menggantikan simpul primer. Selama failover, penulisan waktu diminimalkan. Hal ini karena peran simpul primer tidak berhasil ke salah satu replika baca alih-alih harus membuat dan menyediakan simpul primer baru. Deteksi kegagalan dan promosi replika ini memastikan bahwa Anda dapat melanjutkan penulisan ke primer baru segera setelah promosi selesai.
Agar failover berfungsi, klaster Anda harus memiliki setidaknya dua instans — primer dan setidaknya satu instans replika.
**catatan**
Topik ini hanya berlaku untuk cluster berbasis instans Amazon DocumentDB asli. Ini tidak berlaku untuk cluster elastis atau global.
## Mengontrol target failover
Amazon DocumentDB menyediakan Anda dengan tingkatan failover sebagai sarana untuk mengontrol instans replika mana yang dipromosikan ke primer ketika terjadi failover.
**Tingkatan Failover**
Setiap instans replika berkaitan dengan tingkatan failover (0-15). Ketika failover terjadi akibat pemeliharaan atau kegagalan perangkat keras yang tidak dimungkinkan, instan utama tidak berhasil menjadi replika dengan prioritas tertinggi (tingkatan bernomor terendah). Jika beberapa replika memiliki tingkatan prioritas yang sama, primer tidak berhasil menjadi replika tingkatan tersebut yang paling dekat dalam ukuran primer sebelumnya.
Dengan menetapkan tingkatan failover untuk grup pilih replika menjadi `0` (prioritas tertinggi), Anda dapat memastikan bahwa failover akan mempromosikan salah satu replika dalam grup tersebut. Anda dapat secara efektif mencegah replika spesifik yang dipromosikan ke primer dalam kasus failover dengan menetapkan tingkatan prioritas rendah (nomor tinggi) untuk replika tersebut. Hal ini berguna dalam kasus di mana replika spesifik menerima penggunaan berat oleh aplikasi dan ketidakberhasilan untuk salah satu dari mereka akan berdampak negatif pada aplikasi kritis.
Anda dapat mengatur tingkatan failover instans ketika Anda membuatnya atau kemudian dengan memodifikasinya. Menetapkan tingkatan failover instans dengan memodifikasi instans tidak memicu failover. Untuk informasi selengkapnya lihat topik berikut:
+ [Menambahkan instance Amazon DocumentDB ke klaster](db-instance-add.md)
+ [Memodifikasi instance Amazon DocumentDB](db-instance-modify.md)
Ketika secara manual menginisiasi failover, Anda memiliki dua cara untuk mengontrol instans replika yang dipromosikan ke primer: tingkatan failover seperti yang diuraiakn sebelumnya, dan parameter `--target-db-instance-identifier`.
**--`target-db-instance-identifier`**
Untuk pengujian, Anda dapat memaksa peristiwa failover menggunakan operasi `failover-db-cluster`. Anda dapat menggunakan parameter `--target-db-instance-identifier` untuk menentukan replika mana yang akan dipromosikan ke primer. Menggunakan parameter `--target-db-instance-identifier` akan menggantikan tingkatan prioritas failover. Jika Anda tidak menentukan parameter `--target-db-instance-identifier`, failover primer adalah sesuai dengan tingkatan prioritas failover.
## Apa yang terjadi selama failover
Failover secara otomatis ditangani oleh Amazon DocumentDB sehingga aplikasi Anda dapat melanjutkan operasi basis data secepat mungkin tanpa intervensi administratif.
+ Jika Anda memiliki instans replika Amazon DocumentDB di Availability Zone yang sama atau berbeda ketika terjadi failover: Amazon DocumentDB membalik catatan nama kanonik (CNAME) untuk instans Anda untuk menunjuk pada replika sehat, yang, pada gilirannya, dipromosikan untuk menjadi primer baru. Failover biasanya selesai dalam waktu 30 detik dari awal sampai akhir.
+ Jika Anda tidak memiliki instans replika Amazon DocumentDB (sebagai contoh, klaster instans tunggal): Amazon DocumentDB akan mencoba untuk membuat instans baru di Availability Zone yang sama seperti instans asli. Penggantian instans asli ini dilakukan atas dasar upaya terbaik dan mungkin tidak berhasil jika, sebagai contoh, terdapat masalah yang secara luas memengaruhi Availability Zone.
Aplikasi Anda harus mencoba kembali koneksi basis data dalam peristiwa kehilangan koneksi.
## Menguji failover
Failover untuk klaster mempromosikan salah satu replika Amazon DocumentDB (instans baca-saja) di klaster menjadi instans primer (penulis klaster).
Ketika instans primer gagal, Amazon DocumentDB secara otomatis melakukan failover ke replika Amazon DocumentDB, jika ada. Anda dapat memaksa failover saat Anda ingin menyimulasikan kegagalan instans primer untuk pengujian. Setiap instans dalam klaster memiliki alamat titik akhir sendiri. Oleh karena itu, Anda perlu membersihkan dan membentuk kembali koneksi yang sudah ada yang menggunakan titik akhir tersebut yang ditujukan saat failover selesai.
Untuk memaksa failover, gunakan operasi `failover-db-cluster` dengan parameter tersebut.
+ `--db-cluster-identifier`—Wajib. Nama kluster yang akan di-failover.
+ `--target-db-instance-identifier`—Opsional. Nama instans yang akan dipromosikan ke instans primer.
**Example**
Operasi berikut ini memaksa failover kluster `sample-cluster`. Operasi tersebut tidak menentukan instans mana yang akan menjadi instans primer baru, sehingga Amazon DocumentDB memilih instans sesuai dengan prioritas tingkatan failover.
Untuk Linux, macOS, atau Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster
```
Untuk Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster
```
Operasi berikut ini memaksa failover klaster `sample-cluster`, yang menentukan bahwa `sample-cluster-instance` akan dipromosikan menjadi peran primer. (Perhatikan `"IsClusterWriter": true` dalam keluaran.)
Untuk Linux, macOS, atau Unix:
```
aws docdb failover-db-cluster \
--db-cluster-identifier sample-cluster \
--target-db-instance-identifier sample-cluster-instance
```
Untuk Windows:
```
aws docdb failover-db-cluster ^
--db-cluster-identifier sample-cluster ^
--target-db-instance-identifier sample-cluster-instance
```
Output dari operasi ini terlihat seperti berikut (format JSON).
```
{
"DBCluster": {
"HostedZoneId": "Z2SUY0A1719RZT",
"Port": 27017,
"EngineVersion": "3.6.0",
"PreferredMaintenanceWindow": "thu:04:05-thu:04:35",
"BackupRetentionPeriod": 1,
"ClusterCreateTime": "2018-06-28T18:53:29.455Z",
"AssociatedRoles": [],
"DBSubnetGroup": "default",
"MasterUsername": "master-user",
"Engine": "docdb",
"ReadReplicaIdentifiers": [],
"EarliestRestorableTime": "2018-08-21T00:04:10.546Z",
"DBClusterIdentifier": "sample-cluster",
"ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "sample-cluster-instance",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": true
},
{
"DBInstanceIdentifier": "sample-cluster-instance-00",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
},
{
"DBInstanceIdentifier": "sample-cluster-instance-01",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
}
],
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1a"
],
"DBClusterParameterGroup": "default.docdb3.6",
"Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"IAMDatabaseAuthenticationEnabled": false,
"AllocatedStorage": 1,
"LatestRestorableTime": "2018-08-22T21:57:33.904Z",
"PreferredBackupWindow": "00:00-00:30",
"StorageEncrypted": false,
"MultiAZ": true,
"Status": "available",
"DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-12345678"
}
],
"DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ"
}
}
```
## 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 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 kelambatan replikasi adalah hasil dari throughput penulisan yang tinggi dan kueri yang berjalan lama, kami merekomendasikan pemecahan masalah lag replikasi dengan memanfaatkan metrik DBCluster ReplicaLagMaximum 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.