PolarDB mendukung peningkatan mulus dari instansi ApsaraDB RDS untuk MySQL ke kluster PolarDB untuk MySQL. Selama proses ini, sistem secara otomatis menyinkronkan akun, database, daftar putih IP, dan konfigurasi parameter yang diperlukan dari instansi RDS ke kluster PolarDB. Anda juga dapat mempertahankan titik akhir database asli sehingga aplikasi tetap terhubung ke kluster PolarDB tanpa perlu mengubah pengaturan koneksi. Proses ini secara signifikan mengurangi kompleksitas migrasi serta memastikan transisi yang lancar untuk operasi bisnis.
Anda dapat meningkatkan instans RDS ke kluster PolarDB dengan versi yang sama atau lebih tinggi, seperti dalam contoh berikut:
Instansi ApsaraDB RDS untuk MySQL 5.6 dapat ditingkatkan ke kluster PolarDB untuk MySQL versi 5.6, 5.7, 8.0.1, atau 8.0.2.
Instansi ApsaraDB RDS untuk MySQL 5.7 dapat ditingkatkan ke kluster PolarDB untuk MySQL versi 5.7, 8.0.1, atau 8.0.2.
Instansi ApsaraDB RDS untuk MySQL 8.0 dapat ditingkatkan ke kluster PolarDB untuk MySQL versi 8.0.1 atau 8.0.2.
CatatanPolarDB untuk MySQL 8.0.1 sepenuhnya kompatibel dengan Edisi Komunitas MySQL 8.0.13 dan versi sebelumnya, sedangkan PolarDB untuk MySQL 8.0.2 sepenuhnya kompatibel dengan Edisi Komunitas MySQL 8.0.18 dan versi sebelumnya.
Fitur yang disediakan oleh PolarDB untuk MySQL versi 8.0.1 dan 8.0.2 memiliki beberapa perbedaan. Untuk informasi lebih lanjut, lihat Fitur di PolarDB untuk MySQL 5.6, 5.7, dan 8.0.
Metode Migrasi
Peningkatan ini mendukung dua metode migrasi: migrasi fisik (replikasi fisik) dan migrasi logis (sinkronisasi data DTS). Sistem secara otomatis memilih metode migrasi yang sesuai berdasarkan versi, edisi, dan tipe penyimpanan instance RDS MySQL. Metode migrasi tidak dapat diubah secara manual. Tabel berikut membandingkan kedua metode migrasi tersebut.
Item Perbandingan | Migrasi Fisik (Replikasi Fisik) | Migrasi Logis (Sinkronisasi Data DTS) |
Instansi Sumber | Instansi ApsaraDB RDS untuk MySQL versi 5.6 dan 5.7 Edisi Ketersediaan Tinggi yang menggunakan tipe penyimpanan SSD Lokal dapat ditingkatkan ke kluster PolarDB untuk MySQL dengan versi yang sama. Catatan Versi minor dari instans ApsaraDB RDS untuk MySQL harus memenuhi persyaratan berikut:
| Instansi ApsaraDB RDS untuk MySQL, kecuali yang mendukung migrasi fisik, dapat ditingkatkan ke kluster PolarDB untuk MySQL dengan versi yang sama atau berbeda. Catatan Tidak ada batasan pada versi minor. |
Metode Implementasi | Pertama, salin data penuh dari instansi RDS ke kluster PolarDB, kemudian pertahankan sinkronisasi inkremental dari instansi RDS ke kluster PolarDB. Penting Selama sinkronisasi inkremental, semua tabel non-InnoDB secara otomatis dikonversi menjadi tabel InnoDB. | Buat tugas sinkronisasi data menggunakan DTS. Tugas ini pertama-tama menyinkronkan skema dan data penuh dari instansi RDS ke kluster PolarDB, kemudian mempertahankan sinkronisasi data inkremental dari instansi RDS ke kluster PolarDB. Catatan
|
Apakah DTS Diperlukan | Tidak. | Ya. |
Migrasi Versi MySQL | Hanya mendukung migrasi ke versi yang sama. | Mendukung migrasi ke versi yang sama atau lebih tinggi. |
Durasi Peningkatan | Peningkatan harus diselesaikan dalam 30 hari. Setelah periode 30 hari berakhir, sistem secara otomatis menghentikan proses migrasi. | Peningkatan harus diselesaikan dalam 30 hari. Setelah periode 30 hari berakhir, sistem secara otomatis menghentikan proses migrasi. |
Apakah migrasi lintas wilayah didukung | Tidak. | Tidak. |
Apakah sinkronisasi inkremental didukung | Ya. | Ya. |
Apakah database yang baru ditambahkan dapat dimigrasi | Ya. | Tidak. Catatan Untuk menyinkronkan database yang baru ditambahkan, buka Konsol DTS untuk memodifikasi objek sinkronisasi dan mengonfigurasi database baru dalam tugas maju dan mundur. |
Apakah skema dapat dimigrasi | Ya. | Hanya database, tabel, tampilan, prosedur tersimpan, dan fungsi yang dapat dimigrasi. |
Keuntungan
Switchover dengan titik akhir didukung. Anda dapat memilih untuk mempertahankan titik akhir database asli, sehingga aplikasi dapat terhubung ke kluster PolarDB tanpa perlu mengubah konfigurasi koneksi.
Tidak ada data yang hilang selama proses peningkatan.
Migrasi inkremental didukung.
Migrasi panas online didukung. Selama proses peningkatan, hanya ada satu gangguan singkat, dengan downtime kurang dari 10 menit (yang terjadi ketika bisnis dialihkan).
Jika migrasi gagal atau migrasi tidak lagi diperlukan, Anda dapat memutar balik migrasi. Pembatalan dapat diselesaikan dalam waktu 10 menit.
Catatan Penggunaan
Dampak pada Instansi RDS
Selama proses peningkatan, beberapa operasi pada instansi RDS mungkin dibatasi, dan dapat menyebabkan gangguan singkat atau beban tambahan pada instansi RDS.
Selama proses peningkatan, Anda tidak dapat mengubah parameter instansi.
Jika Anda memilih Switch without Endpoints saat melakukan switchover, bisnis Anda mungkin mengalami gangguan selama 1 hingga 5 menit selama proses pergantian. Jika Anda memilih opsi Switch without Endpoints, Anda harus segera memperbarui konfigurasi koneksi aplikasi Anda untuk terhubung ke kluster PolarDB.
Jika Anda menggunakan metode migrasi logis (sinkronisasi data DTS) untuk migrasi, ikuti panduan berikut:
Hapus pemicu yang dibuat untuk instansi RDS, karena jika tidak, migrasi akan terganggu.
Selama sinkronisasi data penuh awal, jangan jalankan operasi DDL yang mengubah skema database atau tabel. Jika tidak, tugas sinkronisasi data gagal.
Selama sinkronisasi data penuh awal, sumber daya baca/tulis (seperti CPU dan IOPS) dari instansi RDS dan kluster PolarDB digunakan, sehingga dapat menambah beban pada instansi RDS.
Prasyarat
Instansi RDS sumber harus memenuhi persyaratan berikut:
Informasi dasar instansi:
Versi MySQL
Edisi Dasar
Edisi Ketersediaan Tinggi
Edisi Kluster
5.6
-
SSD Lokal
-
5.7
Disk Cloud
SSD Lokal, Disk Cloud
Disk Cloud
8.0
Disk Cloud
SSD Lokal, Disk Cloud
Disk Cloud
Tipe mesin penyimpanan tabel data harus berupa InnoDB atau X-Engine.
Jika kondisi untuk metode migrasi fisik (replikasi fisik) tidak terpenuhi, metode logical migration (DTS data synchronization) digunakan. Pastikan bahwa instansi RDS memenuhi persyaratan berikut:
Tidak ada tugas sinkronisasi dua arah DTS. Jika ada tugas sinkronisasi dua arah DTS, jangan lakukan peningkatan. Jika tidak, ketidaksesuaian data mungkin terjadi selama peningkatan.
Hapus pemicu yang dibuat untuk instansi RDS, karena jika tidak, migrasi akan terganggu.
Secara default, fitur pencatatan biner diaktifkan untuk instansi RDS. Pastikan bahwa nilai parameter binlog_row_image adalah full. Jika tidak, kesalahan akan muncul selama fase pra-pemeriksaan, dan tugas sinkronisasi data tidak dapat dimulai dengan sukses.
Agar DTS dapat mengakses file log biner secara andal untuk sinkronisasi data inkremental selama proses migrasi, instance RDS harus menyimpan file log biner setidaknya selama 7 hari. Jika tidak, tugas sinkronisasi mungkin gagal, dan dalam kasus ekstrem, dapat terjadi ketidaksesuaian data atau kehilangan data. Service Level Agreement (SLA) DTS tidak mencakup masalah yang disebabkan oleh pengaturan periode penyimpanan file binlog kurang dari 7 hari yang dipersyaratkan.
Jika Anda ingin menggunakan metode migrasi fisik (replikasi fisik) untuk migrasi meskipun kondisi tidak terpenuhi, pastikan bahwa versi instansi RDS memenuhi persyaratan berikut:
Untuk instansi ApsaraDB RDS untuk MySQL 5.6 Edisi Ketersediaan Tinggi, versi minor harus 20190815 atau lebih baru.
Untuk instansi ApsaraDB RDS untuk MySQL 5.7 Edisi Ketersediaan Tinggi, versi minor harus 20200331 atau lebih baru.
CatatanUntuk melihat Minor Version instansi RDS, buka halaman . Informasi versi minor dapat ditemukan di bagian Configuration Information. Jika versinya lebih lama dari yang ditentukan, perbarui.
Jika Anda menggunakan migrasi fisik (replikasi fisik), disarankan untuk mengatur periode retensi file log biner minimal selama 24 jam.
Batasan
Peningkatan menggunakan metode migrasi logis (sinkronisasi data DTS) migrasi tunduk pada batasan berikut:
Selama sinkronisasi data, kami sarankan Anda hanya menggunakan DTS untuk menulis data ke database tujuan. Ini mencegah ketidaksesuaian data antara database sumber dan tujuan. Sebagai contoh, jika Anda menggunakan Data Management (DMS) untuk menjalankan pernyataan DDL online sementara data dari sumber lain ditulis ke database tujuan, kehilangan data mungkin terjadi di database tujuan.
Secara default, Data Transmission Service (DTS) menonaktifkan kendala FOREIGN KEY untuk database tujuan dalam tugas sinkronisasi data. Oleh karena itu, operasi kaskade dan penghapusan dari database sumber tidak disinkronkan ke database tujuan.
Pernyataan SQL yang didukung untuk sinkronisasi inkremental:
Jenis Operasi
Pernyataan SQL
DML
INSERT,UPDATE,DELETEDDL
ALTER TABLE,ALTER VIEWCREATE FUNCTION,CREATE INDEX,CREATE PROCEDURE,CREATE TABLE,CREATE VIEWDROP INDEX,DROP TABLERENAME TABLETRUNCATE TABLE
Pertimbangan Utama
Fase Migrasi | Deskripsi |
Sebelum migrasi |
|
Selama migrasi |
|
Penagihan
Metode Migrasi Logis (Sinkronisasi Data DTS)
Jika menggunakan metode migrasi logis (sinkronisasi data DTS), Anda akan dikenakan biaya untuk tugas sinkronisasi data DTS serta kluster PolarDB tujuan.
Tugas sinkronisasi data DTS:
Selama proses peningkatan, sistem secara otomatis membuat tugas sinkronisasi data DTS antara instansi RDS dan kluster PolarDB. Untuk informasi lebih lanjut mengenai aturan penagihan tugas DTS, lihat Ikhtisar Penagihan.
Kluster tujuan PolarDB:
Ketika metode penagihan adalah bayar sesuai pemakaian, Anda tidak dikenakan biaya untuk kluster selama proses migrasi. Anda akan dikenakan biaya berdasarkan pemakaian setelah operasi berikut:
Migrasi selesai (termasuk operasi penyelesaian migrasi selama proses peningkatan).
CatatanMigrasi selesai saat tautan sinkronisasi antara instansi RDS dan kluster PolarDB terputus.
Migrasi harus diselesaikan dalam waktu 30 hari. Setelah periode tersebut berakhir, fitur migrasi akan dinonaktifkan, dan baik instansi RDS maupun kluster PolarDB akan kembali ke status baca-tulis, sehingga hubungan replikasi terputus.
Migrasi dihentikan (termasuk operasi membatalkan migrasi saat pra-pemeriksaan gagal dan operasi membatalkan migrasi selama proses peningkatan).
Dalam hal ini, kluster PolarDB telah dibuat meskipun peningkatan dihentikan. Lepaskan kluster jika Anda tidak memerlukannya lagi.
Jika kluster PolarDB tujuan adalah kluster serverless, kluster tujuan mulai dikenakan biaya ketika memasuki status Berjalan.
Jika kluster PolarDB tujuan menggunakan metode penagihan berlangganan, Anda perlu menyelesaikan pembayaran saat membuat kluster.
Metode Migrasi Fisik (Replikasi Fisik)
Jika migrasi fisik (replikasi fisik) digunakan, Anda tidak dikenakan biaya untuk proses migrasi data dalam peningkatan. Anda hanya dikenakan biaya untuk kluster PolarDB tujuan.
Jika kluster PolarDB tujuan menggunakan metode penagihan bayar sesuai pemakaian, Anda tidak dikenakan biaya untuk kluster selama proses migrasi. Anda akan dikenakan biaya berdasarkan pemakaian setelah operasi berikut:
Migrasi selesai (termasuk operasi penyelesaian migrasi selama proses peningkatan).
CatatanMigrasi selesai saat tautan sinkronisasi antara instansi RDS dan kluster PolarDB terputus.
Migrasi harus diselesaikan dalam 30 hari. Setelah periode tersebut berakhir, fitur migrasi akan dinonaktifkan, dan baik instansi RDS maupun kluster PolarDB akan kembali ke status baca-tulis.
Migrasi dihentikan (termasuk operasi membatalkan migrasi saat pra-pemeriksaan gagal dan operasi membatalkan migrasi selama proses peningkatan).
Dalam hal ini, kluster PolarDB telah dibuat meskipun peningkatan dihentikan. Lepaskan kluster jika Anda tidak memerlukannya lagi.
Jika kluster PolarDB tujuan adalah kluster serverless, kluster tujuan mulai dikenakan biaya ketika memasuki status Berjalan.
Jika kluster PolarDB tujuan menggunakan metode penagihan berlangganan, Anda perlu menyelesaikan pembayaran saat membuat kluster.
Prosedur
1. Evaluasi Migrasi
Untuk memastikan proses migrasi yang lancar dan pengalaman migrasi yang lebih baik, PolarDB menyediakan fitur evaluasi migrasi. Fitur ini memungkinkan Anda melakukan pemeriksaan awal terhadap prasyarat seperti status instansi, dependensi tugas migrasi, dan atribut instansi sumber sebelum peningkatan. Dengan demikian, Anda dapat mengidentifikasi faktor-faktor yang berpotensi memengaruhi kemajuan migrasi dan menyelesaikan masalah terlebih dahulu untuk mengurangi biaya pemrosesan dan penggunaan sumber daya selama migrasi.
2. Lakukan Peningkatan
(Direkomendasikan) Operasi Konsol
Di bawah ini adalah deskripsi singkat dari proses peningkatan. Untuk instruksi langkah demi langkah yang rinci, lihat Langkah-langkah Peningkatan.
(Opsional) Periksa konfigurasi daftar putih
Jika daftar putih node utama dan node baca-saja instansi RDS sumber berbeda, tambahkan daftar putih node baca-saja ke daftar putih node utama terlebih dahulu. Langkah ini memastikan bahwa daftar putih node baca-saja dapat disinkronkan ke kluster PolarDB tujuan.
CatatanKonfigurasi daftar putih kluster PolarDB berlaku untuk seluruh kluster dan tidak mendukung pengaturan individu per node. Setelah migrasi selesai, disarankan untuk meninjau kembali daftar putih serta izin akun database kluster PolarDB.
Buka Halaman Pembelian Kluster PolarDB, pilih metode pembuatan Migrate From RDS, dan tentukan versi RDS sumber serta instansi untuk membeli kluster PolarDB. Setelah pembelian selesai, sistem akan melakukan inisialisasi, pra-pemeriksaan, dan operasi sinkronisasi data penuh. Selama proses ini, kluster berstatus Creating. Tunggu hingga proses pembuatan selesai.
CatatanSelama proses peningkatan menggunakan migrasi logis (sinkronisasi data DTS), kesalahan seperti Precheck Failure mungkin terjadi. Anda dapat menangani kesalahan tersebut berdasarkan informasi dalam Error Message. Setelah kesalahan diselesaikan, klik Continue Migration untuk melanjutkan proses peningkatan. Jika penyelesaian kesalahan memengaruhi bisnis online Anda, Anda dapat memilih untuk mengklik Abandon Migration guna mengakhiri proses peningkatan.
(Opsional) Tambahkan Titik Akhir
Fitur switchover dengan titik akhir memungkinkan Anda mempertahankan titik akhir database asli sehingga aplikasi dapat terhubung ke kluster PolarDB tanpa perlu mengubah konfigurasi koneksi. Namun, hanya titik akhir yang tersedia secara bersamaan di instansi RDS dan kluster PolarDB yang dapat dipertukarkan.
Anda dapat memilih untuk menambahkan titik akhir yang relevan di kluster PolarDB sesuai dengan situasi aktual Anda.
Periksa status enkripsi SSL titik akhir. Status enkripsi SSL untuk instansi RDS dan kluster PolarDB harus konsisten.
Ketika Replication Delay kluster PolarDB kurang dari 60 detik, Anda dapat melakukan alih layanan. Klik Switch Over untuk menukar status baca-tulis instansi RDS dan kluster PolarDB, yaitu mengubah instansi RDS menjadi Read-only dan kluster PolarDB menjadi Read/write. Selain itu, ubah arah replikasi data dengan menyinkronkan data baru dari kluster PolarDB ke instansi RDS.
PentingJika Anda memilih Switchover with Endpoints saat melakukan pergantian, bacalah dengan cermat catatan penggunaan untuk penukaran titik akhir. Perhatikan bahwa bisnis Anda mungkin terganggu selama 1 hingga 5 menit selama proses pergantian.
Jika terjadi kesalahan data setelah pergantian selesai, Anda dapat memutar balik pergantian. Ini memungkinkan Anda mengembalikan database dan data ke keadaan semula sebelum pergantian dilakukan. Setelah itu, Anda masih dapat memilih Batalkan Migrasi untuk mengembalikan status sebelum migrasi.
Jika instansi RDS sumber terlibat dalam tugas DTS (bukan tugas migrasi satu klik), Anda dapat memodifikasi database sumber atau tujuan pada tugas DTS guna memastikan pergantian yang lancar.
Setelah migrasi data selesai dan kluster PolarDB beroperasi secara stabil, Anda dapat mengklik Complete Migration untuk menyelesaikan proses peningkatan jika sinkronisasi data tidak lagi diperlukan.
Lepas atau Batalkan Langganan Instansi ApsaraDB RDS
Ketika bisnis Anda berjalan stabil di kluster PolarDB dan Anda tidak lagi memerlukan instansi RDS, Anda dapat membatalkan langganan atau melepaskan instansi RDS.
Operasi API
Di bawah ini adalah deskripsi singkat dari proses peningkatan. Untuk instruksi langkah demi langkah yang rinci, lihat Langkah-langkah Peningkatan dan dokumentasi API terkait.
(Opsional) Periksa Konfigurasi Daftar Putih
Jika daftar putih node utama dan node baca-saja instansi RDS sumber berbeda, tambahkan daftar putih node baca-saja ke daftar putih node utama terlebih dahulu. Langkah ini memastikan bahwa daftar putih node baca-saja dapat disinkronkan ke kluster PolarDB tujuan.
CatatanKonfigurasi daftar putih kluster PolarDB berlaku untuk seluruh kluster dan tidak mendukung pengaturan individu per node. Oleh karena itu, setelah migrasi selesai, disarankan untuk meninjau kembali daftar putih serta izin akun database kluster PolarDB.
Panggil CreateDBCluster untuk membuat kluster PolarDB.
Saat memanggil API untuk membuat kluster PolarDB, atur SourceResourceId ke wilayah instansi RDS sumber, CreationOption ke MigrationFromRDS, dan SourceResourceId ke ID instansi RDS sumber. Setelah pemanggilan selesai, sistem akan melakukan inisialisasi, pra-pemeriksaan, dan operasi sinkronisasi data penuh. Selama periode ini, kluster berada dalam status Creating. Tunggu hingga proses pembuatan selesai.
Panggil DescribeDBClusterMigration untuk memeriksa status kluster PolarDB.
Ketika parameter MigrationStatus bernilai RDS2POLARDB_SYNCING, sistem telah menyelesaikan sinkronisasi data penuh dan sedang menjalankan sinkronisasi inkremental.
CatatanSelama proses peningkatan menggunakan migrasi logis (sinkronisasi data DTS), kesalahan seperti Precheck Failure (MigrationStatus adalah PRE_CHECK_FAIL) dapat terjadi. Anda dapat menangani kesalahan ini berdasarkan informasi dalam Pesan Kesalahan (Comment). Setelah kesalahan diselesaikan, klik Continue Migration untuk melanjutkan proses peningkatan. Jika penyelesaian kesalahan memengaruhi bisnis online Anda, Anda dapat memilih untuk mengklik Abandon Migration guna mengakhiri proses peningkatan.
Panggil ModifyDBClusterMigration untuk melakukan migrasi dan pergantian.
Jika parameter DelayedSeconds dari DescribeDBClusterMigration kurang dari 60 detik, Anda dapat melakukan pergantian untuk menukar status baca-tulis antara instansi RDS dan kluster PolarDB. Ubah instansi RDS menjadi Read-only dan kluster PolarDB menjadi Read/write, serta ubah arah replikasi data (sinkronkan data baru dari kluster PolarDB ke instansi RDS).
PentingJika Anda memilih Switchover with Endpoints saat melakukan pergantian, bacalah dengan cermat catatan penggunaan untuk penukaran titik akhir. Perhatikan bahwa bisnis Anda mungkin terganggu selama 1 hingga 5 menit selama proses pergantian.
Setelah pergantian migrasi selesai, jika Anda menemukan anomali data atau masalah lainnya, Anda dapat memanggil ModifyDBClusterMigration untuk memutar balik tugas migrasi guna dengan cepat mengembalikan ke keadaan sebelum peningkatan. Setelah itu, Anda masih dapat memilih untuk memanggil CloseDBClusterMigration untuk membatalkan migrasi dan mengembalikan ke status sebelum pergantian.
Jika terjadi kesalahan data setelah pergantian selesai, Anda dapat memanggil ModifyDBClusterMigration untuk memutar balik pergantian. Ini memungkinkan Anda mengembalikan database dan data ke keadaan aslinya sebelum pergantian dilakukan. Anda kemudian dapat memilih CloseDBClusterMigration untuk membatalkan migrasi dan mengembalikan status sebelum migrasi.
(Opsional) Panggil ModifyDtsJobEndpoint untuk memodifikasi instansi sumber atau tujuan tugas DTS.
Jika instansi RDS sumber terlibat dalam tugas DTS (bukan tugas migrasi satu klik), Anda dapat memodifikasi database sumber atau tujuan pada tugas DTS guna memastikan pergantian yang lancar.
Panggil CloseDBClusterMigration untuk menyelesaikan migrasi.
Setelah migrasi data selesai dan kluster PolarDB beroperasi secara stabil, Anda dapat mengklik Complete Migration untuk menyelesaikan proses peningkatan jika sinkronisasi data tidak lagi diperlukan.
Lepas atau Batalkan Langganan Instansi ApsaraDB RDS
Ketika bisnis Anda stabil di kluster PolarDB dan Anda tidak lagi memerlukan instansi RDS, Anda dapat membatalkan langganan atau melepaskan instansi RDS.
3. Sesuaikan Kebijakan Cadangan
Kebijakan cadangan instansi RDS dan kluster PolarDB memiliki beberapa perbedaan. Setelah migrasi selesai, Anda dapat mengubah kebijakan cadangan di konsol berdasarkan situasi aktual Anda.
Informasi Terkait
Kebijakan Cadangan
Kebijakan cadangan instansi RDS dan kluster PolarDB memiliki beberapa perbedaan.
Siklus cadangan reguler dan waktu mulai tetap konsisten antara instansi RDS dan kluster PolarDB. Secara default, kluster PolarDB mewarisi siklus cadangan dan waktu mulai yang sama dari instansi RDS.
Pemetaan periode retensi cadangan:
Jika periode retensi file cadangan pada instansi RDS adalah 14 hari atau kurang, periode retensi file cadangan level-1 pada kluster PolarDB akan sama dengan periode retensi pada instansi RDS.
Jika periode retensi file cadangan pada instansi RDS berada di antara 14 hari (eksklusif) dan 30 hari (inklusif), periode retensi file cadangan level-1 pada kluster PolarDB ditetapkan menjadi 14 hari. Fitur cadangan level-2 diaktifkan pada kluster PolarDB, dengan periode retensi file cadangan level-2 di wilayah yang sama ditetapkan menjadi 30 hari. Jika periode retensi file cadangan pada instansi RDS lebih dari 30 hari, fitur cadangan level-2 diaktifkan pada kluster PolarDB dan periode retensi file cadangan level-2 di wilayah yang sama disamakan dengan instansi RDS.
Jika cadangan RDS disimpan untuk jangka panjang, periode retensi cadangan level-1 PolarDB diatur menjadi 14 hari, sedangkan cadangan level-2 disimpan untuk jangka waktu yang lebih lama.
Jika fitur cadangan frekuensi tinggi diaktifkan pada instansi RDS, fitur tersebut juga akan diaktifkan secara default pada kluster PolarDB. Periode retensi file cadangan frekuensi tinggi untuk instansi RDS dan kluster PolarDB adalah sebagai berikut:
Jika periode retensi file cadangan frekuensi tinggi pada instansi RDS tidak lebih dari 120 menit, periode retensi file cadangan frekuensi tinggi pada kluster PolarDB diatur menjadi 120 menit.
Jika periode retensi file cadangan frekuensi tinggi pada instansi RDS berada di antara 120 menit (eksklusif) dan 180 menit (inklusif), periode retensi file cadangan frekuensi tinggi pada kluster PolarDB akan ditetapkan menjadi 180 menit.
Jika periode retensi file cadangan frekuensi tinggi pada instansi RDS lebih dari 180 menit, periode retensi file cadangan frekuensi tinggi pada kluster PolarDB diatur menjadi 240 menit.
Switchover dengan Titik Akhir
Proses peningkatan satu klik mendukung fitur penukaran alamat. Saat diaktifkan, sistem secara otomatis menukar alamat koneksi instans RDS dan kluster PolarDB, sehingga aplikasi Anda dapat terhubung ke kluster PolarDB tanpa memerlukan perubahan konfigurasi.
Diagram
Berikut mengilustrasikan hubungan penukaran alamat koneksi default antara instansi RDS dan kluster PolarDB. Selama proses penukaran, Anda dapat menyesuaikan hubungan penukaran alamat koneksi melalui konsol.
Titik akhir baca-saja dari instansi RDS mencakup titik koneksi proksi baca-saja dan titik akhir instansi baca-saja.
Catatan Penggunaan
Fitur switchover dengan titik akhir tidak mendukung alamat IPv6.
Fitur switchover dengan titik akhir hanya menukar titik akhir instansi RDS dan kluster PolarDB, tanpa mengubah konfigurasi lainnya seperti vSwitches dan alamat IP virtual.
Titik akhir hanya dapat dipertukarkan jika baik instansi RDS sumber maupun kluster PolarDB tujuan memiliki titik akhir. Secara default, kluster PolarDB tujuan hanya memiliki titik akhir utama pribadi dan titik akhir kluster pribadi. Jika instansi RDS memiliki lebih dari dua titik akhir, Anda harus membuat titik akhir yang sesuai di kluster PolarDB tujuan untuk menukar titik akhir tersebut.
Anda dapat menukar titik akhir utama instansi RDS sumber dengan titik akhir utama atau titik akhir kluster default kluster PolarDB tujuan. Selain itu, titik akhir proksi instansi RDS dapat dipertukarkan dengan titik akhir kluster default atau titik akhir kustom kluster PolarDB. Anda dapat menentukan apakah akan melakukan penukaran titik akhir serta memilih pasangan titik akhir yang ingin dipertukarkan. Kluster PolarDB mendukung hingga tujuh titik akhir kluster, sehingga memungkinkan hingga tujuh titik akhir proksi instansi RDS untuk dipertukarkan dengan titik akhir kluster PolarDB.
Cluster Read-only Endpoint dan Direct Node Connection Endpoint dari instansi Edisi Kluster RDS tidak dapat saling dipertukarkan.
Sebelum menukar titik akhir pribadi, pastikan bahwa instansi RDS sumber dan kluster PolarDB tujuan berada dalam VPC yang sama. Jika tidak, layanan asli tidak akan dapat terhubung setelah pergantian.
Setelah sinkronisasi inkremental selesai, kluster PolarDB tujuan akan berstatus Running. Sebelum menukar titik akhir, Anda dapat mengonfigurasi parameter, menambahkan node baca-saja, serta menambahkan pengaturan alamat.
Jika Anda ingin menggunakan Data Management (DMS) untuk mengakses kluster PolarDB setelah titik akhir dipertukarkan, pastikan untuk menentukan ID kluster dan titik akhir yang benar.
Setelah titik akhir dipertukarkan, entri titik akhir asli mungkin tetap tersimpan dalam cache Sistem Nama Domain (DNS) hingga entri tersebut kedaluwarsa. Selama periode ini, Anda mungkin mengalami kegagalan terhubung ke kluster PolarDB, atau instansi hanya mengizinkan operasi baca. Untuk mengatasi masalah ini, disarankan agar Anda menyegarkan cache DNS.