All Products
Search

This Product

    ApsaraDB RDS:Alih bencana primary/secondary

    Document Center

    ApsaraDB RDS:Alih bencana primary/secondary

    Last Updated:Aug 22, 2026

    Topik ini menjelaskan cara mengalihkan workload antara instans ApsaraDB RDS for MariaDB primary dan secondary. Anda dapat mengaktifkan alih bencana primary/secondary otomatis untuk sistem database Anda. Jika instans RDS primary mengalami kegagalan, sistem secara otomatis akan mengalihkan workload ke instans RDS secondary. Setelah alih bencana, instans RDS secondary ditingkatkan menjadi instans RDS primary yang baru, sedangkan endpoint yang digunakan untuk menghubungkan sistem database tetap tidak berubah. Aplikasi Anda dapat terus menggunakan endpoint tersebut untuk terhubung ke instans RDS primary yang baru. Fitur alih bencana primary/secondary otomatis dirancang untuk memastikan ketersediaan tinggi. Selain itu, Anda juga dapat secara manual mengalihkan workload antara instans RDS primary dan secondary.

    Jika Anda menggunakan Edisi Ketersediaan Tinggi RDS, sebuah instans RDS secondary disediakan sebagai cadangan untuk instans RDS primary pada sistem database Anda. Data dari instans RDS primary disinkronkan secara real time ke instans RDS secondary. Anda hanya dapat mengakses instans RDS primary; akses ke instans RDS secondary tidak tersedia.

    Jika instans RDS primary mengalami kegagalan, workload Anda secara otomatis dialihkan ke instans RDS secondary.

    Catatan penggunaan

    Selama proses alih bencana berlangsung, layanan Anda mungkin mengalami gangguan. Pastikan aplikasi Anda dikonfigurasi untuk melakukan koneksi ulang secara otomatis ke instans tersebut.

    Prosedur

    1. Masuk ke Konsol ApsaraDB RDS.

    2. Pada bilah navigasi atas, pilih wilayah tempat instans RDS berada.

    3. Temukan instans RDS dan klik ID instans tersebut.

    4. Pada panel navigasi di sebelah kiri, klik Service Availability.

    5. Pada bagian Availability Information, klik Switch Primary/Secondary Instance.

    6. Pilih waktu alih bencana dan klik Ok.

      Selama proses alih bencana primary/secondary, beberapa operasi tidak dapat dilakukan, seperti mengelola database dan akun atau mengubah jenis jaringan. Disarankan untuk melakukan alih bencana primary/secondary selama jendela pemeliharaan yang telah direncanakan.

      Catatan

      Jika Anda ingin mengubah jendela pemeliharaan, ikuti langkah-langkah berikut:

      1. Klik modify.

      2. Pada bagian Configuration Information, ubah jendela pemeliharaan dan klik Save.

      3. Buka kembali halaman Service Availability, refresh halaman, lalu lanjutkan prosedur.

    FAQ

    • Apakah saya perlu secara manual mengalihkan workload dari instans RDS secondary kembali ke instans RDS primary setelah alih bencana primary/secondary?

      Tidak, Anda tidak perlu mengalihkan beban kerja secara manual dari instans RDS sekunder ke instans RDS primer setelah Alih bencana primer/sekunder. Data pada instans RDS primer identik dengan data pada instans RDS sekunder. Setelah Alih bencana primer/sekunder, instans RDS sekunder secara otomatis berfungsi sebagai instans RDS primer yang baru, sehingga tidak diperlukan operasi tambahan.

    • Setiap kali alih bencana primary/secondary dilakukan, instans RDS saya tidak berjalan sesuai harapan selama 10 menit setelah proses alih bencana selesai. Apa penyebabnya? Bagaimana cara menanganinya?

      Saat suatu exception memicu alih bencana ketersediaan tinggi, koneksi berdurasi panjang (long-lived connections) dari aplikasi Anda mungkin tidak mendeteksi perubahan status koneksi. Jika timeout socket tidak diatur, aplikasi akan terus menunggu respons dari database dan sering kali baru terputus setelah ratusan detik. Selama periode ini, beberapa koneksi database tidak berfungsi dengan benar, sehingga menyebabkan banyak query SQL gagal. Untuk mencegah koneksi yang tidak valid dan mempercepat waktu pemulihan, kami menyarankan Anda mengonfigurasi parameter connectTimeout dan socketTimeout. Hal ini mencegah aplikasi menunggu tanpa batas saat terjadi error jaringan.

      Atur nilai timeout berdasarkan workload dan pola penggunaan spesifik Anda. Untuk skenario online transaction processing (OLTP), nilai awal yang direkomendasikan adalah connectTimeout 1–2 detik dan socketTimeout 60–90 detik. Nilai-nilai ini hanya bersifat referensi.