Migrasi lintas zona memindahkan instans ApsaraDB RDS untuk MySQL ke zona berbeda dalam wilayah yang sama tanpa kehilangan data. Proses ini memakan waktu hingga satu jam untuk instans disk cloud dan beberapa jam untuk instans Premium Local SSD, tergantung pada volume data.
Batasan
Sebelum memulai, pastikan instans Anda memenuhi semua kondisi berikut:
Instans tersebut menjalankan Edisi Ketersediaan Tinggi atau Edisi Dasar. Instans Serverless tidak didukung.
Instans tidak menggunakan tipe instans yang sudah dihentikan. Lihat Tipe instans untuk instans utama standar ApsaraDB RDS untuk MySQL (arsitektur x86 asli). Untuk mengubah tipe instans, lihat Ubah spesifikasi instans.
Instans berada dalam status Running. Jika instans memiliki instansi hanya baca, instansi tersebut juga harus berada dalam status Running — jika tidak, error
OperationDenied.MasterDBlnstancestateakan muncul saat Anda memulai migrasi.Jika instans menggunakan disk cloud, versi mesin minor adalah 20201031 atau yang lebih baru. Untuk memperbarui, lihat Perbarui versi mesin minor.
Wilayah tersebut memiliki beberapa zona. Lihat Wilayah dan zona.
Proksi database bersama dinonaktifkan. Untuk memeriksa: pada halaman Database Proxy, cari tab Read/Write Splitting (Shared). Jika tab tersebut muncul, proksi bersama diaktifkan.
Proksi database bersama tidak lagi dipelihara sejak 1 April 2021. Jika Anda masih menggunakannya, lakukan upgrade ke proksi database khusus. Lihat Upgrade proksi database dari proksi database bersama ke proksi database khusus. Proksi database khusus dan general-purpose tidak terpengaruh oleh migrasi lintas zona.
Jika instans menggunakan Premium Enterprise SSD (ESSD) dengan Buffer Pool Extension (BPE) diaktifkan, zona tujuan harus mendukung BPE. Lihat Cakupan penerapan. Untuk melakukan migrasi ke zona yang tidak mendukung BPE, nonaktifkan BPE terlebih dahulu.
Penagihan
Migrasi lintas zona tidak dikenai biaya, termasuk migrasi dari zona tunggal ke multi-zona.
Dampak migrasi
Alih bencana instans
Alih bencana dapat terjadi selama migrasi, sehingga titik akhir instans utama dan titik akhir proxy database menjadi sementara tidak tersedia. Konfigurasikan aplikasi Anda agar terhubung ulang secara otomatis. Jika tidak dikonfigurasi untuk terhubung ulang otomatis, lakukan koneksi ulang secara manual.
Alih bencana terjadi jika salah satu kondisi berikut terpenuhi:
Kondisi | Efek |
Zona tujuan instans utama berbeda dari zona saat ini | Instans utama diganti selama migrasi |
Zona tujuan instans utama berbeda dari zona jaringannya saat ini | Instans utama diganti selama migrasi |
Untuk detail perilaku alih bencana, lihat Dampak alih bencana instans.
Perubahan VIP
Jika terjadi alih bencana, alamat IP virtual (VIP) instans berubah sedangkan titik akhir tetap sama. Hubungkan aplikasi Anda menggunakan titik akhir, bukan alamat IP.
Pemasangan PolarDB-X 1.0: Perubahan VIP dapat memutus konektivitas antara instans RDS dan instans PolarDB-X 1.0 yang terpasang. Segera perbaiki masalah konektivitas tersebut. Lihat Perbaiki koneksi shard database.
Cache DNS: Hapus rekaman Domain Name System (DNS) yang di-cache dari klien database segera setelah migrasi. Untuk klien JVM, atur waktu hidup (TTL) menjadi 60 detik atau kurang agar klien melakukan resolusi ulang titik akhir setelah perubahan VIP. Untuk informasi lebih lanjut tentang cara mengatur TTL dalam konfigurasi JVM, lihat Kelas InetAddress.
Dampak lainnya
Dampak | Detail |
Tugas DTS | Mulai ulang semua Tugas Data Transmission Service (DTS) yang sedang berjalan setelah migrasi selesai. Lihat Apa itu DTS? |
Pembuatan ulang tabel | Tabel dibuat ulang selama migrasi. Bidang |
Ketersediaan resource | Jika inventaris resource di zona tujuan tidak mencukupi, migrasi dapat gagal. |
Hanya perubahan vSwitch | Anda tidak dapat hanya mengubah vSwitch selama migrasi lintas zona. Untuk mengubah vSwitch, lihat Ubah VPC dan vSwitch. |
Skenario migrasi
Anda hanya dapat melakukan migrasi dalam Wilayah yang sama. Untuk berpindah ke Wilayah berbeda, buat instans RDS di Wilayah tujuan, migrasikan data menggunakan DTS, verifikasi beban kerja Anda, lalu rilis instans asli.
Skenario migrasi berikut didukung. Penerapan multi-zona melindungi dari kegagalan pusat data; penerapan zona tunggal hanya melindungi dari kegagalan server dan rak.
Skenario | Hasil | Kapan digunakan |
Satu zona ke satu zona | Instans utama dan secondary berada di zona tujuan yang sama. Contoh: keduanya di Singapura Zona C dipindahkan ke Singapura Zona A. | Pilih opsi ini jika Anda perlu mengonsolidasikan instans ke dalam satu zona. Perhatikan bahwa penerapan zona tunggal tidak menyediakan pemulihan bencana lintas zona (DR). |
Satu zona ke beberapa zona | Instans utama dan secondary berada di zona tujuan yang berbeda. Contoh: instans utama dipindahkan dari Singapura Zona C ke Singapura Zona B; instans secondary dipindahkan ke Singapura Zona A. | Pilih opsi ini jika Anda menginginkan DR lintas zona. Penerapan multi-zona melindungi dari kegagalan pusat data. |
Beberapa zona ke satu zona | Instans utama dan secondary dipindahkan ke zona tujuan yang sama. Contoh: instans utama di Singapura Zona B dan instans secondary di Singapura Zona A keduanya dipindahkan ke Singapura Zona C. | Pilih opsi ini jika Anda ingin menyederhanakan topologi. Perhatikan bahwa DR lintas zona hilang. |
Beberapa zona ke beberapa zona | Instans utama dan secondary dipindahkan ke zona tujuan yang berbeda. Contoh: instans utama dipindahkan dari Singapura Zona B ke Singapura Zona A; instans secondary dipindahkan dari Singapura Zona C ke Singapura Zona B. | Pilih opsi ini untuk mengubah penempatan zona sambil mempertahankan DR lintas zona. |
Migrasikan instans lintas zona
Pastikan virtual private cloud (VPC) dan minimal satu vSwitch telah ada di zona tujuan sebelum Anda memulai. Jika belum, buat vSwitch di zona tujuan terlebih dahulu.
Masuk ke Konsol ApsaraDB RDS. Di bilah navigasi atas, pilih wilayah instans. Temukan instans tersebut dan klik ID-nya.
Pada halaman Basic Information, klik Migrate Data Across Zones di pojok kanan atas.
Jika Migrate Data Across Zones tidak ditampilkan, periksa apakah instans memenuhi semua batasan yang tercantum di atas.
Pada kotak dialog Migrate Instance Across Zones, atur parameter Destination Zone dan pilih vSwitch. Lalu atur parameter Switching Time: Klik Yes.
Switch Immediately — failover dilakukan segera setelah migrasi selesai.
Switch Within Maintenance Window — pemindahan dialihkan hingga jendela pemeliharaan berikutnya.
PentingSetelah alih bencana, jika vSwitch berubah, instans akan terhubung ulang melalui koneksi baru. Pastikan aplikasi Anda terhubung ulang secara otomatis. Jika rekaman DNS yang di-cache tidak segera diperbarui, alih bencana kedua dapat terjadi sekitar 10 menit kemudian saat trafik dialihkan ke zona utama tujuan. Konfigurasikan aplikasi Anda agar terhubung ulang secara otomatis. Untuk informasi lebih lanjut, lihat Dampak alih bencana instans.
Pada kotak dialog konfirmasi, tinjau informasi zona sebelum dan sesudah migrasi, lalu klik OK.
FAQ
Jika data ditulis ke instans selama migrasi, apakah data asli terpengaruh setelah alih bencana? Apakah data yang baru ditulis tetap disimpan?
Data asli tidak terpengaruh, dan data yang baru ditulis tetap disimpan. Alih bencana instans terjadi selama migrasi — konfigurasikan aplikasi Anda agar terhubung ulang secara otomatis. Lihat Dampak alih bencana instans.
Apa yang memengaruhi durasi migrasi?
Untuk instans Premium Local SSD, durasi migrasi bergantung pada jumlah data — set data besar dapat memakan waktu beberapa jam. Untuk instans disk cloud, migrasi memakan waktu hingga satu jam.
Referensi API
Operasi | Deskripsi |
Migrasikan instans lintas zona |
Langkah berikutnya
Untuk migrasi lintas zona mesin database lain dalam wilayah yang sama, lihat: