Tair (Redis OSS-compatible) memungkinkan Anda mengubah konfigurasi instans—termasuk arsitektur instans, kapasitas memori, jumlah shard, dan jumlah node replika—untuk memenuhi kebutuhan bisnis yang berubah terkait kinerja dan kapasitas.
Perubahan konfigurasi yang didukung dan dampaknya
Apa yang tetap tidak berubah selama perubahan konfigurasi?
Semua perubahan konfigurasi menjamin hal-hal berikut:
Titik akhir koneksi, akun, kata sandi, dan daftar izin tetap tidak berubah: Anda tidak perlu memodifikasi kode aplikasi setelah perubahan.
Data biasanya dipertahankan: Namun, dalam kasus langka terjadi kegagalan bersamaan—misalnya node primary asli gagal selama alih bencana—sejumlah kecil data yang belum tersinkronisasi mungkin hilang.
FAQ
Periksa riwayat scaling
Di Task Center, filter tugas dengan Status Successful dan periksa apakah ada tugas bernama Modify Instance Specification or Instance. Atau, Anda dapat memanggil operasi API DescribeHistoryTasks.
Kegagalan perubahan konfigurasi
Kunci besar (large keys) dalam instans dapat menyebabkan kegagalan perubahan konfigurasi.
Identifikasi dan hapus kunci besar sebelum mengubah konfigurasi. Untuk informasi cara menemukan large keys, lihat Analisis kunci lengkap offline.
Untuk mencegah kehilangan data, penurunan spesifikasi tunduk pada batasan berikut: memori yang digunakan oleh instans asli harus kurang dari 80% kapasitas memori instans baru (Memori yang digunakan < Kapasitas memori baru × 0,8). Jika tidak, penurunan spesifikasi akan gagal. Sebagai contoh, instans berbasis memori arsitektur Standard (master-replica) 8 GB yang menggunakan 2 GB memori dapat diturunkan spesifikasinya menjadi instans berbasis memori arsitektur Standard (master-replica) 4 GB.
Ubah media penyimpanan untuk Tair (Enterprise Edition)
Tair (Enterprise Edition) tidak mendukung perubahan antar media penyimpanan yang berbeda, seperti berbasis memori, memori persisten, dan berbasis ESSD.
Tingkatkan kinerja CPU
Tair (dan open source Redis) tidak mendukung peningkatan CPU secara mandiri. Sebagai gantinya, Anda dapat meningkatkan kinerja CPU secara keseluruhan dengan cara berikut:
Ubah instans arsitektur Standard (master-replica) menjadi arsitektur kluster atau arsitektur read/write splitting.
Tingkatkan jumlah node read-only untuk instans yang menggunakan arsitektur read/write splitting.
Tingkatkan jumlah shard untuk instans arsitektur kluster.
Untuk informasi lebih lanjut, lihat Bagaimana cara meningkatkan spesifikasi CPU instans?
Untuk informasi tentang spesifikasi instans, lihat Ikhtisar spesifikasi instans dan FAQ.
High-availability ke standalone
Anda tidak dapat mengubah instans high-availability menjadi instans standalone karena instans standalone tidak menyediakan tingkat keandalan data yang sama.
Jika Anda memerlukan instans standalone, beli instans baru dan gunakan Data Transmission Service (DTS) untuk memigrasikan data dari instans high-availability ke instans standalone baru tersebut. Untuk informasi lebih lanjut, lihat Migrasi data antar instans Tair (Redis OSS-compatible).
Jeda aplikasi selama perubahan
Tidak perlu. Namun, instans mungkin menjadi read-only selama sekitar satu menit dan mengalami satu atau dua pemutusan sementara yang masing-masing berlangsung kurang dari 30 detik. Lakukan perubahan konfigurasi dan alih bencana selama jam sepi untuk meminimalkan dampak terhadap bisnis Anda. Untuk detail dampak setiap perubahan, lihat Perubahan konfigurasi yang didukung dan dampaknya.
Migrasi data otomatis
Ya. Sistem secara otomatis memigrasikan dan menyeimbangkan ulang data di seluruh shard.
Durasi perubahan konfigurasi
Waktu yang dibutuhkan untuk mengubah konfigurasi bergantung pada berbagai faktor, seperti kondisi jaringan, volume permintaan, dan ukuran data. Oleh karena itu, durasi tidak dapat diperkirakan.
Anda dapat memantau progres tugas dengan mengklik ikon 
di pojok kanan atas halaman detail instans.
Kehilangan set cadangan
Tidak. Namun, ketika Anda mengurangi jumlah shard untuk instans arsitektur kluster Classic atau mengubahnya menjadi arsitektur Standard (master-replica), pemetaan antara set cadangan historis dan node instans berubah.
Dalam skenario ini, Anda dapat menemukan set cadangan historis dengan mencari berdasarkan waktu pembuatan atau ID set cadangan.
Untuk memulihkan data dari cadangan historis, unduh set cadangan (file RDB), urai, lalu impor data tersebut ke instans baru.
Pembaruan konfigurasi tertunda
Hal ini mungkin disebabkan oleh keterlambatan penyegaran cache metadata. Tunggu beberapa menit lalu refresh halaman.
Eksekusi tugas segera
Untuk instans high-availability dalam arsitektur standard cloud-native, peningkatan atau penurunan spesifikasi merupakan operasi tanpa dampak jika sumber daya lokal mencukupi. Dalam kasus ini, sistem mengabaikan jendela pemeliharaan dan menjalankan tugas segera. Jika sumber daya lokal tidak mencukupi, sistem menjalankan tugas selama jendela pemeliharaan, dan satu atau dua pemutusan sementara yang masing-masing berlangsung kurang dari 30 detik dapat terjadi selama alih bencana.