Halaman ini menjelaskan cara Memorystore for Valkey menjalankan pemeliharaan pada instance. Dasbor ini juga memberikan rekomendasi informasi dan konfigurasi yang harus diketahui oleh aplikasi klien Anda agar dapat memanfaatkannya. Memorystore untuk desain pemeliharaan tanpa periode nonaktif Valkey. Rekomendasi ini berlaku untuk instance yang sangat tersedia maupun instance tanpa replika. Namun, kami sangat merekomendasikan konfigurasi ketersediaan tinggi untuk semua kasus penggunaan produksi.
Memorystore for Valkey mengupdate instance secara rutin untuk memastikan bahwa layanan dapat diandalkan, berperforma tinggi, aman, dan terbaru. Update ini disebut pemeliharaan. Pemeliharaan dikelola sepenuhnya oleh layanan dan dirancang agar tidak memiliki dampak periode nonaktif.
Pemeliharaan biasanya termasuk dalam kategori berikut:
- Fitur Memorystore. Untuk meluncurkan beberapa fitur, Memorystore memerlukan pembaruan pemeliharaan.
- Patch sistem operasi. Kami terus memantau kerentanan keamanan yang baru teridentifikasi di sistem operasi. Setelah ditemukan, kami akan mem-patch sistem operasi untuk melindungi Anda dari risiko baru.
- Patch database. Pemeliharaan dapat mencakup update Valkey untuk meningkatkan karakteristik keamanan, performa, dan keandalan instance di luar fitur yang disediakan OSS Valkey.
Mengonfigurasi aplikasi klien Anda
Untuk mengonfigurasi aplikasi klien agar mendapatkan performa dan ketersediaan terbaik selama pemeliharaan, ikuti langkah-langkah berikut:
- Gunakan dan konfigurasi klien pihak ketiga Anda sesuai dengan panduan di Praktik terbaik klien untuk memastikan bahwa pemeliharaan terjadwal tidak memengaruhi aplikasi klien. Konfigurasi klien yang kami rekomendasikan dapat mencegah reset koneksi melalui refresh topologi inline berkala dan rotasi koneksi latar belakang.
- Uji aplikasi klien Anda dengan serangkaian operasi update (seperti peningkatan atau penurunan skala, perubahan jumlah replika) saat menjalankan beban kerja representatif pada node utama dan replika, serta memantau dampak klien. Update ini menguji logika refresh topologi inline pada klien, dampak sinkronisasi penuh, penemuan node baru, dan kemampuan penghapusan node yang ada. Pengujian membantu memastikan bahwa klien pihak ketiga dikonfigurasi dengan benar untuk menghindari dampak negatif terhadap aplikasi Anda.
Pemeliharaan terjadwal
Memorystore for Valkey memanfaatkan deployment bertahap dan strategi siklus proses buat-sebelum-pemusnahan untuk menghindari dampak periode nonaktif dari pemeliharaan terjadwal Memorystore pada instance Valkey Anda. Pemeliharaan tanpa periode nonaktif dilakukan dengan menggunakan kemampuan pengalihan permintaan dari protokol cluster OSS Valkey bersama dengan mekanisme Memorystore berikut:
- Failover terkoordinasi tanpa kehilangan data
- Penghapusan node secara tuntas agar klien dapat mengikuti pembaruan topologi node tanpa memengaruhi ketersediaan apa pun
- Endpoint PSC instance tidak terpengaruh oleh pemeliharaan. Untuk mengetahui informasi selengkapnya tentang endpoint PSC, lihat Endpoint instance.
Perilaku layanan yang dijelaskan di bagian berikut hanya berlaku untuk pemeliharaan terjadwal. Untuk informasi tentang dampak peristiwa yang tidak direncanakan seperti kegagalan hardware, lihat Perilaku klien selama failover yang tidak direncanakan.
Masa pemeliharaan default
Secara default, Memorystore memperbarui instance Anda dalam sesuai dengan zona waktu instance Anda:
Periode hari kerja (Hari Senin sampai hari Jumat): 22.00-06.00
Periode akhir pekan: Hari Jumat, 22.00 hingga hari Senin, 06.00
Strategi deployment bertahap
Deployment Memorystore for Valkey dilakukan dengan cakupan yang meningkat secara bertahap, dan pada kecepatan yang memungkinkan deteksi kegagalan cukup dini untuk mengurangi dampak dan membangun keyakinan stabilitas. Waktu tunggu (waktu saat update diterapkan dan dipantau sebelum dianggap berhasil dan diterapkan) terintegrasi di seluruh fleet instance Memorystore pada skala layanan. Selain itu, waktu pemanggangan diintegrasikan dalam instance di seluruh zona dalam satu region (beberapa domain fault) untuk mengurangi cakupan dampak, jika ada.
Untuk instance yang dikonfigurasi untuk ketersediaan tinggi, maksimal satu domain/zona fault akan diupdate pada waktu tertentu untuk memastikan bahwa shard instance, termasuk replika utama dan replika, memiliki ketersediaan tinggi selama proses update. Selain itu, hanya beberapa node Valkey yang diupdate pada waktu tertentu. Update menggunakan mekanisme siklus proses buat-sebelum-penghancuran untuk memaksimalkan stabilitas instance. Strategi ini akan memberikan manfaat terbesar jika Anda mengupdate instance yang memiliki banyak shard. Ketersediaan data akan maksimal maksimal jika hanya diterapkan ke sebagian kecil dari keseluruhan keyspace pengguna pada waktu tertentu.
Strategi siklus proses Buat-Sebelum-Menghancurkan
Instance Valkey memiliki beberapa shard. Setiap shard memiliki satu node utama dan nol atau beberapa node replika. Memorystore menggunakan proses berikut untuk mengupdate node Valkey utama atau replika yang ada di shard:
- Memorystore for Valkey menambahkan replika yang benar-benar baru terlebih dahulu dengan update software terbaru ke shard. Memorystore membuat node yang benar-benar baru, bukan memperbarui node yang ada, untuk memastikan kapasitas yang Anda sediakan tetap dipertahankan jika terjadi kegagalan bootstrap yang tidak terduga.
- Jika node dalam shard yang akan diperbarui adalah node utama, node tersebut akan dikonversi menjadi replika terlebih dahulu sebelum dihapus menggunakan failover terkoordinasi.
- Next Memorystore menghapus replika yang menggunakan software sebelumnya.
- Prosesnya diulang untuk setiap node dalam instance.
Strategi buat-sebelum-pemusnahan membantu mempertahankan kapasitas yang disediakan dari instance, dibandingkan dengan deployment berkelanjutan biasa yang diperbarui secara langsung, tetapi mengakibatkan pemadaman ketersediaan (dan terkadang kehilangan data) untuk aplikasi klien. Untuk shard tanpa replika, Memorystore for Valkey tetap menyediakan replika baru terlebih dahulu, mengoordinasikan failover, dan terakhir mengganti node utama shard yang ada.
Langkah 1: Tambahkan replika Valkey
Langkah pertama dari mekanisme buat-sebelum-pemusnahan adalah menambahkan node replika dengan software terbaru menggunakan mekanisme Valkey OSS sinkronisasi penuh untuk menyalin data dari node utama ke node replika. Hal ini dilakukan dengan membagi proses turunan dan memanfaatkan replikasi tanpa disk untuk mem-bootstrap replika.
Anda dapat memanfaatkan arsitektur skala horizontal instance secara optimal dengan menyediakan jumlah shard yang lebih tinggi untuk mengurangi ukuran keyspace dalam node. Memiliki set data yang lebih kecil per node membantu mengurangi dampak latensi fork dari operasi sinkronisasi penuh. Ini juga mempercepat penyalinan data di seluruh {i>node<i}.
Langkah 2: Failover utama terkoordinasi
Jika node Valkey yang perlu diperbarui adalah node utama, Memorystore terlebih dahulu menjalankan failover terkoordinasi ke node replika yang baru ditambahkan, lalu melanjutkan dengan penghapusan node. Selama failover terkoordinasi, klien dan node Valkey bekerja sama dan menggunakan strategi berikut untuk menghindari periode nonaktif untuk aplikasi:
- Permintaan klien yang masuk akan diblokir untuk sementara di node utama, sehingga menyediakan jendela untuk memastikan replika yang ada 100% disinkronkan dengan yang utama.
- Replika ini menyelesaikan proses pemilu untuk mengambil alih peran utama.
- Node utama sebelumnya, yang kini menjadi replika, berhenti memblokir permintaan yang ada dan mengalihkannya ke primer yang baru dipilih menggunakan protokol cluster OSS Valkey. Setiap permintaan baru yang dikirim ke node replika sebelumnya akan terus dialihkan ke node utama yang baru.
- Klien Anda yang cocok untuk Valkey memperbarui topologi dalam memori. Layanan ini mempelajari alamat endpoint utama baru, dan tidak lagi memerlukan pengalihan.
Failover terkoordinasi biasanya memerlukan waktu puluhan milidetik. Namun, data yang sedang berlangsung yang tertunda untuk dipindahkan ke replika dan total ukuran instance Anda dapat meningkatkan latensi failover. Ukuran instance dapat memengaruhi konvergensi di seluruh node primer, sehingga memengaruhi pengambilan keputusan dalam memilih primer baru.
Langkah 3: Hapus replika Valkey
Langkah terakhir dari mekanisme buat-sebelum-pemusnahan adalah menghapus node replika pada perangkat lunak sebelumnya. Penghapusan node secara tiba-tiba akan berdampak bagi aplikasi klien karena klien meng-cache informasi endpoint dan topologi instance. Memorystore for Valkey telah merancang penghapusan replika Valkey secara halus agar aplikasi klien dapat memperbarui topologinya sebelum penonaktifan hard node. Topologi tersebut disesuaikan agar klien dapat mempelajari replika baru dan juga melupakan replika yang harus dihapus sebelumnya.
Node replika yang menjalankan software sebelumnya disimpan selama periode pengosongan tertentu, biasanya dengan urutan menit, selama itu mulai mengalihkan permintaan baca yang masuk ke node utama shard-nya. Fungsi ini memungkinkan klien pihak ketiga untuk memperbarui topologi node dan mempelajari endpoint replika baru. Jika klien mencoba menjangkau node yang dihapus setelah periode pengurasan, upaya tersebut akan gagal, yang kemudian akan memicu refresh topologi node pada klien yang terhubung sehingga klien mempelajari perubahan replika. Refresh baru pada topologi node tidak melihat node replika yang akan dihapus.