ApsaraDB RDS:Migrasi ke zona lain

Jenis migrasi

Skenario

Migrasi dari satu zona ke zona lain

Zona saat ini berada pada kapasitas penuh atau mengalami masalah kinerja.

Migrasi dari satu zona ke multi-zona

Setelah migrasi, instans utama dan secondary berada di zona berbeda, sehingga memungkinkan pemulihan bencana lintas pusat data.

Dibandingkan dengan instans zona tunggal, instans multi-zona mampu menahan kegagalan tingkat lebih tinggi. Misalnya, instans zona tunggal hanya tahan terhadap kegagalan tingkat server dan rak, sedangkan instans multi-zona tahan terhadap kegagalan tingkat pusat data.

Migrasi dari multi-zona ke satu zona

Untuk memenuhi kebutuhan fitur tertentu.

Kategori

Deskripsi

Sebelum migrasi

• Kehilangan lingkungan host: Migrasi zona melibatkan migrasi lintas host. Hal ini akan menghapus akun host Anda serta semua program atau file yang ditempatkan di host asal (seperti SSIS, SSAS, SSRS). Cadangkan atau migrasikan data ini terlebih dahulu.

  Penting

  ApsaraDB RDS for SQL Server dibangun di atas engine Microsoft SQL Server asli dan fokus menyediakan layanan database terkelola yang stabil dan efisien. Jika bisnis Anda memerlukan fitur seperti SSIS, SSAS, atau SSRS, Anda membutuhkan keahlian operasional yang kuat untuk memastikan kelangsungan bisnis.

• Hindari perubahan metadata: Jangan menambah atau menghapus database atau mengubah model pemulihan selama migrasi zona. Tindakan ini dapat menyebabkan ketidakkonsistenan data.

• Migrasi tidak dapat dibatalkan: Setelah dimulai, migrasi tidak dapat dibatalkan. Lanjutkan dengan hati-hati.

• Pilih jam sepi: Migrasi biasanya memakan waktu sekitar 20 menit, tergantung pada volume data Anda. Aktivitas berat selama migrasi dapat memperpanjang waktu tersebut. Lakukan migrasi pada jam sepi bisnis.

• Pastikan koneksi ulang otomatis: Instans akan tidak tersedia selama beberapa menit selama alih bencana, sehingga ketersediaannya terganggu sementara. Pastikan aplikasi Anda memiliki mekanisme koneksi ulang.

• Periksa alamat koneksi: Alamat IP virtual (VIP) berubah setelah migrasi. Pastikan aplikasi Anda menggunakan titik akhir (endpoint) alih-alih alamat IP langsung untuk mengakses instans.

  Untuk klien berbasis JVM, atur TTL menjadi 60 detik atau kurang. Ini memastikan aplikasi Anda menerima VIP baru dengan melakukan kueri ulang DNS saat VIP titik akhir berubah.

  Atur TTL di JVM

  • Untuk semua aplikasi JVM: Atur parameter networkaddress.cache.ttl menjadi 60 di file $JAVA_HOME/jre/lib/security/java.security.

  • Untuk aplikasi lokal tertentu: Sebelum membuat koneksi jaringan apa pun—khususnya sebelum panggilan pertama ke InetAddress.getByName()—tambahkan baris berikut ke kode inisialisasi aplikasi Anda: java.security.Security.setProperty("networkaddress.cache.ttl" , "60");.

• Rencanakan penanganan tugas DTS: Jika Anda memiliki tugas DTS aktif, rencanakan terlebih dahulu. Anda harus me-restart tugas tersebut secara manual setelah migrasi.

• Bisnis tetap dapat diakses: Data dipindahkan selama migrasi, tetapi instans RDS SQL Server Anda tetap dapat diakses. Operasional bisnis tidak terpengaruh.

• Batasan pencadangan reguler: Jika Anda memilih untuk melakukan alih bencana selama jendela pemeliharaan, pencadangan reguler dinonaktifkan sejak pengiriman tugas hingga migrasi selesai.

Sesudah migrasi

• Verifikasi konsistensi konfigurasi: Nama instans, port, tag, akun database, dan pengaturan lainnya tetap tidak berubah. Pastikan konfigurasi ini berfungsi dengan benar.

• Bersihkan cache DNS: Segera bersihkan cache DNS klien Anda untuk menghindari kegagalan koneksi akibat entri lama.

• Validasi konektivitas: Gunakan titik akhir untuk memverifikasi bahwa instans dapat diakses dan pastikan fungsi bisnis berjalan normal.

• Restart tugas DTS: Jika Anda memiliki tugas DTS aktif sebelum migrasi, restart secara manual untuk memastikan operasional yang tepat.