Meminimalkan downtime di MemoryDB dengan Multi-AZ - Amazon MemoryDB
Skenario kegagalan dengan respons Multi-AZMenguji failover otomatis

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

Meminimalkan downtime di MemoryDB dengan Multi-AZ

Ada sejumlah contoh di mana MemoryDB mungkin perlu mengganti node primer; ini termasuk jenis pemeliharaan terencana tertentu dan kejadian yang tidak mungkin dari node primer atau kegagalan Availability Zone.

Respon terhadap kegagalan node tergantung pada node mana yang gagal. Namun, dalam semua kasus, MemoryDB memastikan bahwa tidak ada data yang hilang selama penggantian node atau failover. Misalnya, jika replika gagal, node yang gagal diganti dan data disinkronkan dari log transaksi. Jika node utama gagal, failover dipicu ke replika konsisten yang memastikan tidak ada data yang hilang selama failover. Penulisan sekarang dilayani dari simpul utama baru. Node primer lama kemudian diganti dan disinkronkan dari log transaksi.

Jika node primer gagal pada pecahan node tunggal (tidak ada replika), MemoryDB berhenti menerima penulisan sampai node utama diganti dan disinkronkan dari log transaksi.

Penggantian node dapat mengakibatkan beberapa downtime untuk cluster, tetapi jika Multi-AZ aktif, downtime diminimalkan. Peran node primer akan secara otomatis gagal ke salah satu replika. Tidak perlu membuat dan menyediakan simpul utama baru, karena MemoryDB akan menangani ini secara transparan. Failover dan promosi replika ini memastikan Anda dapat melanjutkan penulisan ke primer baru segera setelah promosi selesai.

Dalam kasus penggantian node yang direncanakan dimulai karena pembaruan pemeliharaan atau pembaruan layanan, perhatikan penggantian node yang direncanakan selesai saat cluster melayani permintaan tulis yang masuk.

Multi-AZ pada cluster MemoryDB Anda meningkatkan toleransi kesalahan Anda. Ini benar terutama dalam kasus di mana node utama cluster Anda menjadi tidak dapat dijangkau atau gagal karena alasan apa pun. Multi-AZ pada cluster MemoryDB mengharuskan setiap pecahan memiliki lebih dari satu node, dan diaktifkan secara otomatis.

Skenario kegagalan dengan respons Multi-AZ

Jika Multi-AZ aktif, node primer yang gagal gagal ke replika yang tersedia. Replika secara otomatis disinkronkan dengan log transaksi dan menjadi primer, yang jauh lebih cepat daripada membuat dan reprovisioning node primer baru. Proses ini biasanya memakan waktu hanya beberapa detik hingga Anda dapat menulis lagi ke klaster.

Ketika Multi-AZ aktif, MemoryDB terus memantau keadaan node utama. Jika simpul primer gagal, salah satu tindakan berikut akan dilakukan bergantung pada jenis kegagalan.

Skenario kegagalan ketika hanya simpul primer yang gagal

Jika hanya node primer yang gagal, replika akan secara otomatis menjadi primer. Replika pengganti kemudian dibuat dan disediakan di Availability Zone yang sama dengan primer yang gagal.

Ketika hanya node utama yang gagal, MemoryDB Multi-AZ melakukan hal berikut:

  1. Simpul primer yang gagal akan dibuat offline.

  2. up-to-date Replika secara otomatis menjadi primer.

    Menulis dapat dilanjutkan segera setelah proses failover selesai, biasanya hanya beberapa detik.

  3. Replika pengganti diluncurkan dan disediakan.

    Replika pengganti diluncurkan di Availability Zone tempat node utama yang gagal berada sehingga distribusi node dipertahankan.

  4. Replika disinkronkan dengan log transaksi.

Untuk informasi tentang cara menemukan titik akhir klaster, lihat topik berikut:

 

Skenario kegagalan ketika node utama dan beberapa replika gagal

Jika replika primer dan setidaknya satu replika gagal, up-to-date replika dipromosikan ke cluster primer. Replika baru juga dibuat dan disediakan di Availability Zone yang sama dengan node yang gagal.

Ketika node utama dan beberapa replika gagal, MemoryDB Multi-AZ melakukan hal berikut:

  1. Node primer yang gagal dan replika yang gagal diambil offline.

  2. Replika yang tersedia akan menjadi simpul utama.

    Menulis dapat dilanjutkan segera setelah failover selesai, biasanya hanya beberapa detik.

  3. Replika pengganti dibuat dan ditetapkan.

    Replika pengganti dibuat di Zona Ketersediaan dari simpul yang gagal sehingga distribusi simpul tetap terpelihara.

  4. Semua node disinkronkan dengan log transaksi.

Untuk informasi tentang cara menemukan titik akhir klaster, lihat topik berikut:

 

Skenario kegagalan ketika seluruh klaster gagal

Jika semuanya gagal, semua simpul dibuat kembali dan ditetapkan pada Zona Ketersediaan yang sama dengan simpul asli.

Tidak ada kehilangan data dalam skenario ini karena data disimpan dalam log transaksi.

Ketika seluruh cluster gagal, MemoryDB Multi-AZ melakukan hal berikut:

  1. Node primer dan replika yang gagal diambil offline.

  2. Node primer pengganti dibuat dan disediakan, disinkronkan dengan log transaksi.

  3. Replika pengganti dibuat dan disediakan, disinkronkan dengan log transaksi.

    Penggantinya dibuat di Zona Ketersediaan dari simpul yang gagal sehingga distribusi simpul tetap dipertahankan.

Untuk informasi tentang cara menemukan titik akhir klaster, lihat topik berikut:

Menguji failover otomatis

Anda dapat menguji failover otomatis menggunakan konsol MemoryDB, API AWS CLI, dan MemoryDB.

Saat menguji, perhatikan hal berikut:

  • Anda dapat menggunakan operasi ini hingga lima kali dalam periode 24 jam apa pun.

  • Jika Anda memanggil operasi ini pada pecahan di cluster yang berbeda, Anda dapat melakukan panggilan secara bersamaan.

  • Dalam beberapa kasus, Anda mungkin memanggil operasi ini beberapa kali pada pecahan yang berbeda di cluster MemoryDB yang sama. Dalam kasus tersebut, penggantian simpul pertama harus selesai sebelum panggilan berikutnya dapat dibuat.

  • Untuk menentukan apakah penggantian node selesai, periksa peristiwa menggunakan konsol MemoryDB, API AWS CLI, atau MemoryDB. Cari peristiwa berikut yang terkait denganFailoverShard, tercantum di sini dalam urutan kemungkinan terjadinya:

    1. pesan cluster: FailoverShard API called for shard <shard-id>

    2. pesan cluster: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. pesan cluster: Recovering nodes <node-id>

    4. pesan cluster: Finished recovery for nodes <node-id>

    Untuk informasi selengkapnya, lihat berikut ini:

  • API ini dirancang untuk menguji perilaku aplikasi Anda jika terjadi failover MemoryDB. Hal ini tidak dirancang untuk menjadi alat operasional untuk memulai failover guna mengatasi masalah dengan klaster. Selain itu, dalam kondisi tertentu seperti peristiwa operasional skala besar, AWS dapat memblokir API ini.

Menguji failover otomatis menggunakan AWS Management Console

Gunakan prosedur berikut untuk menguji failover otomatis dengan konsol.

  1. Masuk ke AWS Management Console dan buka konsol MemoryDB di https://console.aws.amazon.com/memorydb/.

  2. Pilih tombol radio di sebelah kiri cluster yang ingin Anda uji. Cluster ini harus memiliki setidaknya satu node replika.

  3. Pada bagian Detail, lakukan konfirmasi bahwa klaster ini sudah mengaktifkan Multi-AZ. Jika klaster tidak memiliki Multi-AZ yang aktif, pilih klaster yang berbeda atau ubah klaster ini agar memiliki Multi-AZ yang aktif. Untuk informasi selengkapnya, lihat Memodifikasi cluster MemoryDB.

  4. Pilih nama klaster.

  5. Pada halaman Pecahan dan node, untuk pecahan yang ingin Anda uji failover, pilih nama pecahan.

  6. Untuk node, pilih Failover Primary.

  7. Pilih Lanjutkan untuk melakukan failover primer, atau Batalkan untuk membatalkan failover simpul primer.

    Selama proses failover, konsol terus menunjukkan status simpul sebagai tersedia. Untuk memantau progres pengujian failover Anda, pilih Peristiwa dari panel navigasi konsol. Di tab Peristiwa, perhatikan peristiwa yang menunjukkan failover Anda telah dimulai (FailoverShard API called) dan selesai (Recovery completed).

 

Menguji failover otomatis menggunakan AWS CLI

Anda dapat menguji failover otomatis pada klaster berkemampuan multi-AZ apa pun menggunakan AWS CLI operasi failover-shard.

Parameter

  • --cluster-name – Wajib. Cluster yang akan diuji.

  • --shard-name – Wajib. Nama pecahan yang ingin Anda uji failover otomatis. Anda dapat menguji maksimal lima pecahan dalam periode 24 jam bergulir.

Contoh berikut menggunakan AWS CLI to call failover-shard on the shard 0001 di cluster MemoryDB. my-cluster

Untuk Linux, macOS, atau Unix:

aws memorydb failover-shard \
   --cluster-name my-cluster \
   --shard-name 0001

Untuk Windows:

aws memorydb failover-shard ^
   --cluster-name my-cluster ^
   --shard-name 0001

Untuk melacak kemajuan failover Anda, gunakan AWS CLI describe-events operasi.

Ini akan mengembalikan respons JSON berikut:

{
    "Events": [
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Failover to replica node my-cluster-0001-002 completed",
            "Date": "2021-08-22T12:39:37.568000-07:00"
        },
        {
            "SourceName": "my-cluster",
            "SourceType": "cluster",
            "Message": "Starting failover for shard 0001",
            "Date": "2021-08-22T12:39:10.173000-07:00"
        }
    ]
}

Untuk informasi selengkapnya, lihat berikut ini:

 

Menguji failover otomatis menggunakan API MemoryDB

Contoh berikut memanggil pecahan FailoverShard 0003 di clustermemorydb00.

contoh Menguji failover otomatis
https://memory-db.us-east-1.amazonaws.com/
    ?Action=FailoverShard
    &ShardName=0003
    &ClusterName=memorydb00
    &Version=2021-01-01
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20210801T192317Z
    &X-Amz-Credential=<credential>

Untuk melacak kemajuan failover Anda, gunakan operasi API MemoryDBDescribeEvents.

Untuk informasi selengkapnya, lihat informasi berikut: