PolarDB memungkinkan Anda meningkatkan instans ApsaraDB RDS for MySQL menjadi kluster PolarDB for MySQL hanya dengan satu klik. Selama proses peningkatan, PolarDB secara otomatis menyinkronkan akun, database, daftar putih alamat IP, dan parameter yang diperlukan dari instans RDS sumber. Anda juga dapat memilih untuk mempertahankan titik akhir database asli sehingga aplikasi Anda dapat beralih ke kluster PolarDB tanpa mengubah pengaturan koneksi apa pun. Proses ini secara signifikan mengurangi kompleksitas migrasi dan memfasilitasi transisi bisnis yang lancar.
Anda dapat meningkatkan instans RDS menjadi kluster PolarDB dengan versi yang sama atau lebih tinggi. Contohnya:
Instans ApsaraDB RDS for MySQL 5.6 dapat ditingkatkan menjadi kluster PolarDB for MySQL 5.6, 5.7, 8.0.1, atau 8.0.2.
Instans ApsaraDB RDS for MySQL 5.7 dapat ditingkatkan menjadi kluster PolarDB for MySQL 5.7, 8.0.1, atau 8.0.2.
Instans ApsaraDB RDS for MySQL 8.0 dapat ditingkatkan menjadi kluster PolarDB for MySQL 8.0.1 atau 8.0.2.
CatatanPolarDB for MySQL 8.0.1 sepenuhnya kompatibel dengan MySQL Community Edition 8.0.13 dan versi sebelumnya. Versi 8.0.2 sepenuhnya kompatibel dengan MySQL Community Edition 8.0.18 dan versi sebelumnya.
Fitur yang didukung oleh PolarDB for MySQL 8.0.1 dan 8.0.2 berbeda. Untuk informasi selengkapnya, lihat Perbandingan fitur versi kernel.
Metode migrasi
Dalam proses peningkatan satu-klik, tersedia dua metode migrasi: migrasi fisik (physical replication) dan migrasi logis (DTS data synchronization). Sistem secara otomatis memilih metode yang sesuai berdasarkan versi MySQL, edisi, dan jenis penyimpanan instans RDS. Anda tidak dapat mengubah metode yang dipilih secara manual. Perbedaannya adalah sebagai berikut:
Item | Migrasi fisik (physical replication) | Migrasi logis (DTS data synchronization) |
Instans yang berlaku | Instans ApsaraDB RDS for MySQL Edisi Ketersediaan Tinggi 5.6 dan 5.7 yang menggunakan local SSD. Instans-instans ini dapat ditingkatkan menjadi kluster PolarDB for MySQL dengan versi yang sama. Catatan Persyaratan versi minor:
| Kecuali metode migrasi fisik (physical replication), tipe instans RDS for MySQL lainnya dapat ditingkatkan menjadi kluster PolarDB for MySQL dengan versi yang sama atau berbeda. Catatan Tidak ada batasan versi minor. |
Cara kerja | Menyalin seluruh data dari instans RDS, lalu mempertahankan sinkronisasi inkremental ke kluster PolarDB. Penting Selama sinkronisasi inkremental, tabel non-InnoDB yang dibuat akan dikonversi menjadi tabel InnoDB. | Menggunakan DTS untuk membuat tugas yang melakukan sinkronisasi skema dan data penuh dari instans RDS ke kluster PolarDB, diikuti oleh sinkronisasi inkremental. Catatan
|
Diperlukan DTS | Tidak. | Ya. |
Migrasi versi MySQL | Hanya mendukung migrasi versi yang sama. | Mendukung migrasi ke versi yang sama atau lebih tinggi. |
Batas durasi peningkatan | Anda harus menyelesaikan migrasi dalam waktu 30 hari. Setelah periode ini, fitur migrasi dinonaktifkan. | Anda harus menyelesaikan migrasi dalam waktu 30 hari. Setelah periode ini, fitur migrasi dinonaktifkan. |
Migrasi lintas wilayah | Tidak didukung. | Tidak didukung. |
Sinkronisasi inkremental | Didukung. | Didukung. |
Migrasi database baru | Didukung. | Tidak didukung. Catatan Untuk menyinkronkan database baru, buka Konsol DTS untuk mengubah objek sinkronisasi. Tambahkan database baru tersebut ke tugas sinkronisasi maju maupun balik. |
Migrasi skema | Didukung. | Hanya skema database, tabel, tampilan, prosedur tersimpan, dan fungsi yang dapat dimigrasikan. |
Manfaat
Alih bencana dengan titik akhir: Anda dapat mempertahankan titik akhir database asli sehingga aplikasi Anda dapat beralih ke kluster PolarDB tanpa memodifikasi konfigurasi koneksi apa pun.
Proses peningkatan satu-klik menjamin tidak ada kehilangan data.
Mendukung migrasi inkremental.
Mendukung migrasi panas online. Layanan Anda hanya mengalami gangguan singkat kurang dari 10 menit selama operasi alih bencana.
Mendukung rollback migrasi. Anda dapat memutar balik migrasi dalam waktu 10 menit jika gagal atau jika persyaratan bisnis Anda berubah.
Dampak pada instans RDS
Peningkatan satu-klik membatasi beberapa operasi pada instans RDS dan dapat menyebabkan gangguan singkat atau peningkatan beban. Dampaknya adalah sebagai berikut:
Anda tidak dapat memodifikasi parameter instans selama proses peningkatan satu-klik.
Selama proses peningkatan satu-klik, Anda tidak dapat berhenti berlangganan, melepas, atau mengubah zona instans RDS.
Selama operasi alih bencana, jika Anda memilih Switchover with Endpoints, bisnis Anda mungkin terganggu selama 1 hingga 5 menit. Jika Anda memilih Switchover without Endpoints, Anda harus segera memperbarui pengaturan koneksi aplikasi Anda agar terhubung ke kluster PolarDB.
Berdasarkan metode migrasi, jika Anda melakukan peningkatan satu-klik menggunakan migrasi logis (DTS data synchronization), dampak berikut berlaku:
Jika pemicu ada di instans RDS, Anda harus menghapusnya sebelum memulai. Jika tidak, migrasi akan terganggu.
Selama inisialisasi data penuh, jangan lakukan operasi DDL yang mengubah skema database atau tabel. Hal ini dapat menyebabkan tugas sinkronisasi data gagal.
Inisialisasi data penuh mengonsumsi sumber daya baca dan tulis, seperti CPU dan IOPS, baik di instans RDS maupun kluster PolarDB. Hal ini dapat meningkatkan beban pada instans RDS.
Catatan Penggunaan
Prasyarat
Instans RDS Anda harus memenuhi kondisi berikut:
Spesifikasi instans:
Versi MySQL
Edisi Dasar
Edisi Ketersediaan Tinggi
Edisi Kluster
5.6
-
local SSD
-
5.7
cloud disk
local SSD, cloud disk
cloud disk
8.0
cloud disk
local SSD, cloud disk
cloud disk
Jenis mesin penyimpanan untuk tabel data harus InnoDB atau X-Engine.
Jika instans Anda tidak memenuhi persyaratan untuk migrasi fisik (physical replication), sistem akan secara otomatis memilih migrasi logis (DTS data synchronization) untuk peningkatan. Dalam hal ini, untuk mencegah kegagalan peningkatan satu-klik, instans RDS juga harus memenuhi kondisi berikut:
Instans RDS tidak boleh menjadi bagian dari tugas sinkronisasi dua arah DTS yang sudah ada. Melanjutkan peningkatan dalam kondisi ini dapat menyebabkan ketidakkonsistenan data.
Jika pemicu ada di instans RDS, Anda harus menghapusnya sebelum memulai. Jika tidak, migrasi akan terganggu.
Pencatatan biner diaktifkan secara default pada instans RDS. Pastikan bahwa parameter binlog_row_image diatur ke full. Jika tidak, kesalahan akan dilaporkan selama Pemeriksaan Awal, dan tugas sinkronisasi data tidak dapat dimulai.
DTS mensyaratkan agar log biner instans RDS dipertahankan setidaknya selama tujuh hari. Jika tidak, DTS mungkin gagal mendapatkan log biner, menyebabkan tugas gagal dan, dalam kasus ekstrem, menyebabkan ketidakkonsistenan atau kehilangan data. Masalah yang disebabkan oleh pengaturan periode retensi log biner lebih pendek dari persyaratan DTS tidak dicakup oleh Perjanjian Tingkat Layanan (SLA) DTS.
Jika instans Anda tidak memenuhi persyaratan untuk migrasi fisik (physical replication), tetapi Anda ingin menggunakan metode ini untuk melakukan peningkatan satu-klik, Anda dapat melakukan operasi berikut agar instans RDS Anda memenuhi persyaratan untuk migrasi fisik (physical replication), lalu lakukan peningkatan satu-klik:
Untuk ApsaraDB RDS for MySQL Edisi Ketersediaan Tinggi 5.6, versi minor harus 20190815 atau lebih baru.
Untuk ApsaraDB RDS for MySQL Edisi Ketersediaan Tinggi 5.7, versi minor harus 20200331 atau lebih baru.
CatatanAnda dapat membuka halaman . Di bagian Configurations, lihat minor version information instans RDS. Jika versinya lebih rendah dari yang ditentukan di atas, Anda dapat meningkatkan versi minor ke versi terbaru.
Untuk migrasi fisik (physical replication), atur periode retensi untuk log biner minimal 24 jam.
Batasan
Jika instans Anda tidak memenuhi persyaratan untuk migrasi fisik (physical replication), sistem secara otomatis memilih migrasi logis (DTS data synchronization) untuk melakukan peningkatan. Metode migrasi ini memiliki batasan penggunaan berikut:
-
Jangan menulis data ke database tujuan kecuali melalui DTS selama sinkronisasi berjalan. Jika tidak, ketidakkonsistenan data dapat terjadi antara database sumber dan tujuan. Misalnya, jika Anda menggunakan DMS untuk melakukan operasi DDL Online sementara data lain ditulis ke database tujuan, kehilangan data dapat terjadi.
DTS secara default menonaktifkan kendala kunci asing saat menyinkronkan ke database tujuan. Oleh karena itu, operasi cascading dan penghapusan di 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
Fase migrasi | Deskripsi |
Sebelum migrasi |
|
Selama migrasi |
|
Penagihan
Migrasi logis (DTS data synchronization)
Untuk metode migrasi logis (DTS data synchronization), Anda dikenai biaya untuk tugas sinkronisasi data DTS dan kluster PolarDB tujuan.
Tugas sinkronisasi data DTS:
Selama peningkatan, sistem secara otomatis membuat tugas sinkronisasi data DTS antara instans RDS dan kluster PolarDB. Untuk informasi selengkapnya, lihat Ikhtisar penagihan DTS.
Kluster PolarDB tujuan:
Jika metode penagihan adalah pay-as-you-go, kluster tidak ditagih selama proses peningkatan. Penagihan pay-as-you-go standar dimulai setelah salah satu operasi berikut:
Migrasi selesai (termasuk operasi Complete Migration).
CatatanMigrasi selesai ketika tautan sinkronisasi antara instans RDS dan kluster PolarDB dihentikan.
Migrasi harus diselesaikan dalam waktu 30 hari. Setelah periode ini, fitur migrasi dinonaktifkan, dan baik instans RDS maupun kluster PolarDB kembali ke status read/write, memutus tautan replikasi.
Migrasi dihentikan (termasuk operasi Abandon Migration untuk kegagalan pemeriksaan awal dan operasi Cancel Migration).
Pada titik ini, kluster PolarDB tujuan telah dibuat, tetapi proses peningkatan dihentikan. Jika Anda tidak lagi memerlukan kluster PolarDB tujuan, lepas segera.
Jika metode penagihan adalah Serverless, penagihan dimulai begitu status kluster berubah menjadi Running.
Jika metode penagihan adalah subscription, Anda harus membayar biaya yang sesuai saat membuat kluster.
Migrasi fisik (physical replication)
Untuk metode migrasi fisik (physical replication), tidak ada biaya tambahan untuk proses peningkatan. Anda hanya dikenai biaya untuk kluster PolarDB tujuan.
Jika metode penagihan adalah pay-as-you-go, kluster tidak ditagih selama proses peningkatan. Penagihan pay-as-you-go standar dimulai setelah salah satu operasi berikut:
Migrasi selesai (termasuk operasi Complete Migration).
CatatanMigrasi selesai ketika tautan sinkronisasi antara instans RDS dan kluster PolarDB dihentikan.
Migrasi harus diselesaikan dalam waktu 30 hari. Setelah periode ini, fitur migrasi dinonaktifkan, dan baik instans RDS maupun kluster PolarDB kembali ke status read/write, memutus tautan replikasi.
Migrasi dihentikan (termasuk operasi Abandon Migration untuk kegagalan pemeriksaan awal dan operasi Cancel Migration).
Pada titik ini, kluster PolarDB tujuan telah dibuat, tetapi proses peningkatan dihentikan. Jika Anda tidak lagi memerlukan kluster PolarDB tujuan, lepas segera.
Jika metode penagihan adalah Serverless, penagihan dimulai begitu status kluster berubah menjadi Running.
Jika metode penagihan adalah subscription, Anda harus membayar biaya yang sesuai saat membuat kluster.
Cara Menggunakan
1. Penilaian migrasi
Untuk memastikan migrasi berjalan lancar, PolarDB menyediakan fitur penilaian migrasi. Sebelum memulai migrasi, Anda dapat menggunakan fitur ini untuk memeriksa prasyarat seperti status instans, dependensi tugas migrasi, dan informasi atribut instans. Hal ini membantu Anda mengidentifikasi dan menangani potensi masalah sebelumnya, sehingga mengurangi biaya pemrosesan dan sumber daya selama proses peningkatan satu-klik.
2. Langkah-langkah peningkatan
Operasi Konsol
Bagian ini menjelaskan proses peningkatan satu-klik. Untuk petunjuk terperinci, lihat Langkah-langkah peningkatan.
(Opsional) Periksa daftar putih alamat IP
Jika instans RDS Anda memiliki instans hanya baca dan daftar putih alamat IP-nya berbeda dari daftar putih instans utama, gabungkan daftar putih instans hanya baca ke daftar putih instans utama. Hal ini memastikan bahwa daftar putih disinkronkan secara otomatis ke kluster PolarDB.
CatatanDaftar putih alamat IP kluster PolarDB berlaku untuk seluruh kluster. Anda tidak dapat mengonfigurasi daftar putih terpisah untuk masing-masing node. Oleh karena itu, setelah migrasi selesai, tinjau daftar putih alamat IP dan izin akun database untuk kluster PolarDB.
Buka halaman pembelian kluster PolarDB. Atur metode pembuatan ke Migrate from RDS, dan tentukan versi serta instans RDS sumber untuk membeli kluster PolarDB. Setelah pembelian selesai, sistem melakukan inisialisasi, pemeriksaan awal, dan sinkronisasi data penuh. Selama proses ini, status kluster adalah Creating. Harap tunggu.
CatatanSelama migrasi logis (DTS data synchronization), kesalahan seperti Precheck Failed dapat terjadi. Selesaikan kesalahan berdasarkan Error Message. Setelah Anda menyelesaikan kesalahan, klik Continue untuk melanjutkan proses peningkatan satu-klik. Jika menyelesaikan kesalahan memengaruhi layanan online Anda, Anda dapat mengklik Abandon Migration untuk menghentikan proses peningkatan.
(Opsional) Tambahkan titik akhir yang hilang
Fitur alih bencana dengan titik akhir mempertahankan titik akhir database asli. Hal ini memungkinkan aplikasi Anda beralih ke kluster PolarDB tanpa mengubah pengaturan koneksi apa pun. Namun, Anda hanya dapat mengalihkan titik akhir yang ada di kedua instans RDS dan kluster PolarDB.
Jika diperlukan, tambahkan titik akhir database yang diperlukan di kluster PolarDB.
Periksa status enkripsi SSL titik akhir database. Status SSL untuk titik akhir instans RDS dan kluster PolarDB harus sama.
Saat Replication Latency kluster PolarDB kurang dari 60 detik, Anda dapat mengalihkan layanan Anda. Klik Switch Over. Tindakan ini menukar status baca/tulis instans RDS dan kluster PolarDB. Instans RDS menjadi read-only, dan kluster PolarDB menjadi read/write. Arah replikasi data juga dibalik. Data baru dari kluster PolarDB disinkronkan ke instans RDS.
PentingJika Anda menggunakan alih bencana dengan titik akhir, bacalah dengan cermat catatan tentang alih bencana dengan titik akhir. Perhatikan bahwa layanan Anda mungkin terganggu selama 1 hingga 5 menit selama proses alih bencana.
Setelah alih bencana, jika Anda menemukan anomali data atau masalah lain, Anda dapat melakukan rollback migrasi untuk segera kembali ke kondisi sebelum peningkatan. Anda kemudian dapat membatalkan migrasi untuk mengembalikan kondisi sebelum alih bencana.
(Opsional) Alihkan tugas DTS instans sumber
Jika instans RDS memiliki tautan Data Transmission Service (DTS) yang terkait, selain yang digunakan untuk migrasi logis dalam proses peningkatan ini, Anda dapat menggunakan fitur ini. Fitur ini memungkinkan Anda mengubah instans sumber atau tujuan tugas sinkronisasi atau migrasi DTS untuk mengalihkan layanan terkait secara lancar.
Setelah data Anda dimigrasikan dan layanan Anda berjalan stabil di kluster PolarDB, Anda dapat mengakhiri proses peningkatan. Jika sinkronisasi data tidak lagi diperlukan, klik Complete Migration.
(Opsional) Berhenti berlangganan atau lepas instans RDS
Jika layanan Anda berjalan stabil di kluster PolarDB dan instans RDS tidak lagi diperlukan, berhenti berlangganan atau lepas instans RDS.
Operasi API
Bagian ini menjelaskan proses peningkatan satu-klik. Untuk petunjuk terperinci, lihat Langkah-langkah peningkatan dan dokumentasi API terkait.
(Opsional) Periksa daftar putih alamat IP
Jika instans RDS Anda memiliki instans hanya baca dan daftar putih alamat IP-nya berbeda dari daftar putih instans utama, gabungkan daftar putih instans hanya baca ke daftar putih instans utama. Hal ini memastikan bahwa daftar putih disinkronkan secara otomatis ke kluster PolarDB.
CatatanDaftar putih alamat IP kluster PolarDB berlaku untuk seluruh kluster. Anda tidak dapat mengonfigurasi daftar putih terpisah untuk masing-masing node. Oleh karena itu, setelah migrasi selesai, tinjau daftar putih alamat IP dan izin akun database untuk kluster PolarDB.
CreateDBCluster - Buat kluster PolarDB
Saat memanggil API Create Cluster, atur parameter SourceResourceId ke wilayah tempat instans RDS sumber berada, parameter CreationOption ke MigrationFromRDS, dan parameter SourceResourceId ke ID instans RDS sumber. Setelah panggilan selesai, sistem melakukan operasi seperti inisialisasi, pemeriksaan awal, dan sinkronisasi data penuh. Selama proses ini, status kluster adalah Creating. Harap tunggu.
Kueri status migrasi kluster PolarDB
Saat parameter MigrationStatus yang dikembalikan adalah RDS2POLARDB_SYNCING, artinya sistem telah menyelesaikan sinkronisasi data penuh dan sekarang melakukan sinkronisasi inkremental.
CatatanSelama migrasi logis (DTS data synchronization), kesalahan seperti Precheck Failed dapat terjadi. Dalam hal ini, parameter MigrationStatus adalah PRE_CHECK_FAIL. Anda harus menyelesaikan kesalahan berdasarkan Error Message
ModifyDBClusterMigration – Melakukan cut over pada tugas migrasi
Saat parameter DelayedSeconds yang dikembalikan oleh DescribeDBClusterMigration kurang dari 60 detik, Anda dapat melakukan alih bencana bisnis. Tukar status baca/tulis instans RDS dan kluster PolarDB (atur instans RDS ke read-only dan kluster PolarDB ke read/write), dan ubah arah replikasi data (sinkronkan data baru dari kluster PolarDB ke instans RDS).
PentingJika Anda menggunakan alih bencana dengan titik akhir, bacalah dengan cermat catatan tentang alih bencana dengan titik akhir. Perhatikan bahwa layanan Anda mungkin terganggu selama 1 hingga 5 menit selama proses alih bencana.
Setelah migrasi alih bencana selesai, jika Anda menemukan ketidakkonsistenan data atau masalah lainnya, Anda dapat memanggil ModifyDBClusterMigration untuk mengembalikan tugas migrasi dan segera memulihkan status ke kondisi sebelum peningkatan. Setelah itu, Anda juga dapat memanggil CloseDBClusterMigration untuk membatalkan migrasi dan memulihkan status ke kondisi sebelum alih bencana.
(Opsional) ModifyDtsJobEndpoint - Ubah instans database sumber atau tujuan tugas DTS
Jika instans RDS Anda memiliki tautan DTS terkait (selain tautan sinkronisasi data DTS untuk migrasi logis dalam proses peningkatan satu-klik), Anda dapat mengubah (mengganti) instans database sumber atau tujuan tugas sinkronisasi atau migrasi DTS untuk mengalihkan layanan terkait secara lancar.
CloseDBClusterMigration - Selesaikan migrasi
Setelah migrasi data bisnis selesai dan layanan Anda berjalan stabil di kluster PolarDB, Anda dapat mengakhiri proses peningkatan satu-klik jika Anda tidak lagi memerlukan sinkronisasi data.
(Opsional) Berhenti berlangganan atau lepas instans RDS
Jika layanan Anda berjalan stabil di kluster PolarDB dan instans RDS tidak lagi diperlukan, berhenti berlangganan atau lepas instans RDS.
3. Sesuaikan kebijakan cadangan
RDS dan PolarDB memiliki kebijakan pencadangan yang berbeda. Setelah migrasi selesai, Anda dapat mengubah kebijakan pencadangan di Konsol sesuai kebutuhan.