Gunakan panduan ini untuk melakukan scale-up atau scale-down instans Tair (kompatibel dengan Redis OSS). Lakukan upgrade untuk menangani peningkatan traffic atau downgrade untuk mengurangi biaya selama periode penggunaan yang lebih rendah.
Billing
Billing tergantung pada metode pembayaran Anda:
| Metode Penagihan | Apa yang terjadi |
|---|---|
| Subscription | Bayar selisih harga untuk upgrade, atau terima pengembalian dana untuk downgrade. |
| Pay-as-you-go | Ditagih berdasarkan spesifikasi baru. |
Untuk detail harga, lihat Perubahan konfigurasi.
Batasan
Periksa batasan berikut sebelum memulai:
| Batasan | Detail |
|---|---|
| Batas memori minimum untuk downgrade | Setelah downgrade, memori yang digunakan tidak boleh melebihi 80% dari kapasitas memori baru. Misalnya, jika instans berbasis DRAM Anda saat ini menggunakan 2 GB, Anda tidak dapat menurunkan spesifikasi ke kurang dari 2,5 GB. |
| Instans terdistribusi | Semua instans anak dalam instans terdistribusi harus memiliki spesifikasi yang identik. Spesifikasi campuran tidak didukung. |
| Instans berbasis ESSD | Kapasitas penyimpanan hanya dapat ditingkatkan, dengan kenaikan per 10 GB. Penurunan kapasitas penyimpanan tidak didukung. |
| Upgrade CPU saja | Anda tidak dapat meningkatkan CPU secara independen. Untuk menambah jumlah core CPU yang tersedia, beralihlah ke arsitektur kluster, aktifkan pemisahan baca/tulis, tambahkan node read-only, atau tambahkan shard. |
Ubah spesifikasi instans
Apa yang tetap sama
Saat mengubah spesifikasi, hal-hal berikut tetap tidak berubah—tidak diperlukan perubahan kode aplikasi:
-
Endpoints
-
Akun dan kata sandi database
-
Pengaturan daftar putih
Data instans dipertahankan. Dalam kasus langka di mana node primary gagal selama alih bencana, sejumlah kecil data yang belum tersinkronisasi mungkin hilang. Sebagai tindakan pencegahan, buat backup manual sebelum mengubah spesifikasi.
Mengubah spesifikasi (baik scale-up maupun scale-down) tidak secara langsung memengaruhi utilisasi CPU, jumlah koneksi client, throughput, atau tingkat hit cache—metrik ini ditentukan oleh workload aktual Anda, bukan oleh tier spesifikasi.
Dampak layanan
Baik scale-up (upgrade) maupun scale-down (downgrade—termasuk downgrade yang hanya mengurangi memori node) dapat memicu migrasi host jika host saat ini tidak dapat menampung spesifikasi target. Alih bencana akibat migrasi tidak mulus: menyebabkan 1–2 gangguan koneksi singkat dan sekitar 1 menit dalam keadaan read-only. Hanya instans kluster Cloud-native dan instans standar Cloud-native pada host dengan sumber daya mencukupi yang menyelesaikan perubahan secara in-place tanpa downtime.
| Skenario | Gangguan layanan |
|---|---|
| Instans kluster Cloud-native, atau instans standar Cloud-native pada host dengan sumber daya mencukupi | Tidak ada. Pembaruan in-place yang mulus—tanpa downtime. |
| Instans standar Cloud-native pada host dengan sumber daya tidak mencukupi, atau instans Classic apa pun | 1–2 diskoneksi sementara (masing-masing berlangsung kurang dari 30 detik), ditambah sekitar 1 menit dalam keadaan read-only. Pastikan aplikasi Anda melakukan reconnect secara otomatis. |
Saat terjadi alih bencana, instans juga berada dalam keadaan read-only selama sekitar satu menit untuk memastikan sinkronisasi data cepat dan mencegah masalah dual-write akibat caching DNS. Untuk instans dengan volume write tinggi, periode ini mungkin lebih lama.
Selama perubahan, versi minor instans Anda secara otomatis ditingkatkan ke versi terbaru. Versi minor bersifat backward-compatible.
Durasi perubahan konfigurasi
Durasi keseluruhan perubahan konfigurasi terdiri dari dua fase:
-
Persiapan backend: Sistem menyediakan node baru sesuai spesifikasi target dan menyinkronkan data. Proses ini dapat memakan waktu puluhan menit hingga beberapa jam tergantung volume data. Selama fase ini, instans tetap melayani permintaan secara normal dan bisnis tidak terganggu.
-
Alih bencana: Setelah persiapan selesai, traffic dialihkan ke node baru. Instans kluster Cloud-native dan instans standar dengan sumber daya mencukupi beralih secara transparan; dalam kasus lain, terjadi 1–2 diskoneksi sementara masing-masing kurang dari 30 detik.
Oleh karena itu, durasi total perubahan konfigurasi (puluhan menit hingga beberapa jam) dan durasi dampak bisnis (kurang dari 30 detik, atau tidak ada) adalah dua konsep yang berbeda. Anda dapat melacak progres di Task Center Konsol.
Langkah-langkah
-
Login ke halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans Anda berada, lalu klik ID instans.
-
Di pojok kanan atas, klik Specification Adjustment, lalu pilih opsi yang sesuai:
-
Instans Subscription: Pilih Specification Upgrade atau Specification Downgrade.
-
Instans Pay-as-you-go: Pilih Specifications Upgrade/Downgrade.
-
-
Pada halaman yang muncul, pilih spesifikasi target.
-
Tetapkan Switching Time:
-
Switch During the Maintenance Window: Sistem menerapkan perubahan selama jendela pemeliharaan yang telah dikonfigurasi (jam sepi). Untuk menyesuaikan waktu sebelum alih bencana, buka Task Center dan klik Change Switching Time di sebelah tugas tersebut.
-
Switch Immediately After Data Migration: Sistem beralih ke node baru segera setelah migrasi data selesai.
-
-
Klik Create Now dan selesaikan pembayaran.
Setelah mengirimkan permintaan, status instans berubah menjadi Changing Configuration. Sistem mulai meminta sumber daya dan menyinkronkan data di latar belakang—layanan Anda tidak terpengaruh pada tahap ini. Diskoneksi sementara hanya terjadi saat alih bencana ke node baru.
Cara kerja perubahan spesifikasi
Memahami proses di balik layar membantu Anda memprediksi kapan gangguan mungkin terjadi.
Instans Cloud-native
-
Instans memasuki status Changing Configuration.
-
Sistem memeriksa apakah host saat ini memiliki sumber daya yang cukup untuk spesifikasi target.
-
Berdasarkan ketersediaan sumber daya, sistem mengambil salah satu dari dua jalur:
-
Sumber daya mencukupi: Perubahan spesifikasi selesai secara in-place tanpa gangguan.
-
Sumber daya tidak mencukupi: Sistem menyediakan node host baru, melakukan pre-sync data instans ke node tersebut, lalu mengalihkan traffic ke node baru dalam jendela pemeliharaan (atau segera). Hal ini menyebabkan diskoneksi sementara singkat.
-
-
Instans kembali ke status Running.
Instans Classic
-
Instans memasuki status Changing Configuration.
-
Sistem menyediakan node host baru dan melakukan pre-sync data instans ke node tersebut.
-
Sistem mengalihkan traffic ke node baru dalam jendela pemeliharaan (atau segera). Hal ini menyebabkan diskoneksi sementara singkat.
-
Instans kembali ke status Running.
FAQ
Apakah saya bisa melakukan upgrade hanya pada CPU tanpa mengubah memori?
Tidak. Tair (termasuk Redis Edisi Open-Source) tidak mendukung upgrade CPU secara independen. Untuk menambah jumlah core CPU yang tersedia, gunakan salah satu pendekatan berikut:
-
Beralih dari arsitektur standar ke arsitektur kluster, atau aktifkan pemisahan baca/tulis.
-
Tambahkan node read-only (untuk instans yang telah mengaktifkan pemisahan baca/tulis).
-
Tambahkan shard (untuk instans kluster).
Untuk detail lebih lanjut, lihat Cara melakukan upgrade spesifikasi CPU instans dan Tipe instans dan FAQ.
Apa yang perlu saya pertimbangkan sebelum mengubah spesifikasi saat penggunaan memori tinggi?
Jika Anda berencana melakukan scale-down dan penggunaan memori saat ini tinggi, pastikan terlebih dahulu bahwa spesifikasi target memenuhi batasan: kapasitas memori baru × 0,8 > memori yang sedang digunakan. Jika kondisi ini tidak terpenuhi, scale-down akan gagal dan konfigurasi asli dipertahankan—tidak ada data yang hilang.
Jika Anda berencana melakukan scale-up untuk mengatasi penggunaan memori yang terus-menerus tinggi, pertimbangkan terlebih dahulu untuk menyelidiki akar permasalahannya. Mengurangi data yang tidak perlu (misalnya, dengan membersihkan kunci yang tidak digunakan, menetapkan kebijakan TTL, atau menyesuaikan kebijakan penggantian) dapat menurunkan konsumsi memori dan memungkinkan Anda menunda atau menghindari upgrade. Untuk pendekatan troubleshooting yang sistematis, lihat Troubleshoot penggunaan memori tinggi.