Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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.
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:
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 saat gagal: Amazon DocumentDB membalik catatan nama kanonik (CNAME) agar instans Anda menunjukkan replika sehat, yang, pada gilirannya, dipromosikan menjadi primer baru. Failover biasanya selesai dalam waktu 30 detik dari awal sampai akhir.
-
Jika Anda tidak memiliki instans replika Amazon DocumentDB (misalnya, klaster instans tunggal): Amazon DocumentDB akan mencoba membuat instans baru di Availability Zone yang sama dengan 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.
Failover Pengujian
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.
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"
}
}