Migrasi satu klik untuk meningkatkan RDS MySQL ke PolarDB MySQL - PolarDB

PolarDB memungkinkan Anda meningkatkan instans ApsaraDB RDS for MySQL menjadi kluster PolarDB for MySQL hanya dengan satu klik. PolarDB secara otomatis menyinkronkan akun, database, daftar putih IP, dan parameter dari instans RDS sumber. Anda dapat mempertahankan titik akhir asli sehingga aplikasi beralih ke kluster PolarDB tanpa perubahan konfigurasi.

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.
Catatan
- PolarDB 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. Perbandingan fitur versi kernel.

Metode migrasi

Tersedia dua metode migrasi: migrasi fisik (replikasi fisik) dan migrasi logis (sinkronisasi data DTS). Sistem memilih metode berdasarkan versi MySQL, edisi, dan jenis penyimpanan instans RDS. Anda tidak dapat mengubah metode tersebut.

Item	Migrasi fisik (replikasi fisik)	Migrasi logis (sinkronisasi data DTS)
Instans yang berlaku	Instans ApsaraDB RDS for MySQL 5.6 dan 5.7 Edisi Ketersediaan Tinggi yang menggunakan SSD lokal. Instans ini dapat ditingkatkan menjadi kluster PolarDB for MySQL dengan versi yang sama. Catatan Persyaratan versi minor: Untuk Edisi Ketersediaan Tinggi ApsaraDB RDS for MySQL 5.6, versi minornya harus 20190815 atau lebih baru. Untuk Edisi Ketersediaan Tinggi ApsaraDB RDS for MySQL 5.7, versi minornya harus 20200331 atau lebih baru.	Kecuali metode migrasi fisik (replikasi fisik), jenis 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 Selama inisialisasi data penuh, operasi `INSERT` konkuren menyebabkan fragmentasi tabel di kluster PolarDB. Oleh karena itu, setelah inisialisasi penuh selesai, ruang tabel kluster PolarDB lebih besar daripada instans RDS. Penggunaan memori tinggi dapat terjadi selama fase inisialisasi data penuh. Hal ini karena kolam buffer memori engine InnoDB, `innodb_buffer_pool`, secara aktif menyimpan cache data untuk mempercepat operasi baca dan tulis, sehingga meningkatkan penggunaan memori secara keseluruhan. Setelah peningkatan satu klik selesai, Anda dapat menyesuaikan ukuran buffer memori, `innodb_buffer_pool_size`, di konsol untuk mengurangi penggunaan memori tersebut.
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 memodifikasi objek sinkronisasi. Tambahkan database baru ke tugas sinkronisasi maju dan 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 beralih ke kluster PolarDB tanpa mengubah 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.

Anda tidak dapat memodifikasi parameter instans selama proses peningkatan satu klik.
Selama proses peningkatan satu klik, Anda tidak dapat membatalkan langganan, 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 untuk terhubung ke kluster PolarDB.
Berdasarkan metode migrasi, jika Anda melakukan peningkatan satu klik menggunakan migrasi logis (sinkronisasi data DTS), 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	-	SSD lokal	-
5.7	disk cloud	SSD lokal, disk cloud	disk cloud
8.0	disk cloud	SSD lokal, disk cloud	disk cloud

Jenis mesin penyimpanan untuk tabel data harus InnoDB atau X-Engine.
Jika instans Anda tidak memenuhi persyaratan untuk migrasi fisik (replikasi fisik), sistem akan secara otomatis memilih migrasi logis (sinkronisasi data DTS) 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 di 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 minimal selama tujuh hari. Jika tidak, DTS mungkin gagal memperoleh 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 (replikasi fisik), 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 (replikasi fisik), lalu lakukan peningkatan satu klik:
- Untuk Edisi Ketersediaan Tinggi ApsaraDB RDS for MySQL 5.6, versi minornya harus 20190815 atau lebih baru.
- Untuk Edisi Ketersediaan Tinggi ApsaraDB RDS for MySQL 5.7, versi minornya harus 20200331 atau lebih baru.
Catatan
- Anda dapat membuka halaman RDS console > Instance Details > Basic Information. 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 (replikasi fisik), atur periode retensi untuk log biner minimal 24 jam.

Batasan

Jika instans Anda tidak memenuhi persyaratan untuk migrasi fisik (replikasi fisik), sistem secara otomatis memilih migrasi logis (sinkronisasi data DTS) 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`, `DELETE`
DDL	`ALTER TABLE`, `ALTER VIEW` `CREATE FUNCTION`, `CREATE INDEX`, `CREATE PROCEDURE`, `CREATE TABLE`, `CREATE VIEW` `DROP INDEX`, `DROP TABLE` `RENAME TABLE` `TRUNCATE TABLE`

Pertimbangan

Fase migrasi	Deskripsi
Sebelum migrasi	(Opsional) Pemeriksaan daftar putih: Jika konfigurasi daftar putih instans primary RDS dan instans read-only tidak konsisten, Anda perlu menggabungkan daftar putih instans read-only ke konfigurasi daftar putih instans primary terlebih dahulu untuk memastikan bahwa daftar putih node read-only disinkronkan secara otomatis ke kluster PolarDB. Untuk migrasi logis (sinkronisasi data DTS), Anda harus memeriksa apakah peran terkait layanan untuk PolarDB sudah ada dan menghapus akun sistem tambahan dari instans RDS sumber.
Selama migrasi	Saat Anda membuat kluster PolarDB, sinkronisasi data penuh dimulai. Durasi tergantung pada volume data, dan status kluster adalah Creating selama proses ini. Saat Anda melakukan (Opsional) alih bencana dengan titik akhir, hanya titik akhir koneksi yang ada di kedua instans RDS dan kluster PolarDB yang dapat dialihkan. Anda harus membuat titik akhir koneksi yang sesuai di kluster sebelum alih bencana. Jika tidak, alih bencana tidak akan terjadi. Status enkripsi SSL titik akhir harus cocok: Jika titik akhir di instans RDS memiliki enkripsi SSL diaktifkan dan Anda memilih untuk mengalihkannya menggunakan alih bencana dengan titik akhir, pastikan titik akhir yang sesuai di kluster PolarDB juga memiliki enkripsi SSL diaktifkan. Jika titik akhir di instans RDS tidak memiliki enkripsi SSL diaktifkan, pastikan titik akhir yang sesuai di kluster PolarDB juga tidak memiliki enkripsi SSL diaktifkan. Untuk migrasi logis (sinkronisasi data DTS), jangan melepas tugas sinkronisasi data DTS secara manual.

Penagihan

Migrasi logis (sinkronisasi data DTS)

Untuk metode migrasi logis (sinkronisasi data DTS), 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. 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).
    Catatan
    
    Migrasi 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 setelah status kluster berubah menjadi Running.
- Jika metode penagihan adalah subscription, Anda harus membayar biaya yang sesuai saat membuat kluster.

Migrasi fisik (replikasi fisik)

Untuk metode migrasi fisik (replikasi fisik), 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).
  Catatan
  - Migrasi 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 setelah status kluster berubah menjadi Running.
Jika metode penagihan adalah subscription, Anda harus membayar biaya yang sesuai saat membuat kluster.

Memulai

1. Penilaian migrasi

PolarDB menyediakan fitur penilaian migrasi untuk memeriksa status instans, dependensi tugas, dan atribut instans sebelum Anda memulai. Hal ini membantu mengidentifikasi dan menyelesaikan potensi masalah lebih awal.

2. Langkah-langkah peningkatan

Operasi konsol

Bagian ini menjelaskan proses peningkatan satu klik. Langkah-langkah peningkatan.

(Opsional) Periksa daftar putih alamat IP

Jika instans RDS Anda memiliki instans read-only dan daftar putih alamat IP-nya berbeda dari daftar putih instans primary, gabungkan daftar putih instans read-only ke daftar putih instans primary. Hal ini memastikan bahwa daftar putih disinkronkan secara otomatis ke kluster PolarDB.

Catatan
Daftar 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.
Buat 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.

Catatan
Selama migrasi logis (sinkronisasi data DTS), 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.
1. Jika diperlukan, tambahkan titik akhir database yang diperlukan di kluster PolarDB.
2. Periksa status enkripsi SSL titik akhir database. Status SSL untuk titik akhir instans RDS dan kluster PolarDB harus sama.
Peralihan

Ketika 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.
Penting
- Jika Anda menggunakan alih bencana dengan titik akhir, baca 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 Layanan Transmisi Data (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 mulus.
Selesaikan migrasi

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) Batalkan langganan atau lepas instans RDS

Jika layanan Anda berjalan stabil di kluster PolarDB dan instans RDS tidak lagi diperlukan, batalkan langganan atau lepas instans RDS.

Operasi API

Bagian ini menjelaskan proses peningkatan satu klik. Langkah-langkah peningkatan.

(Opsional) Periksa daftar putih alamat IP

Jika instans RDS Anda memiliki instans read-only dan daftar putih alamat IP-nya berbeda dari daftar putih instans primary, gabungkan daftar putih instans read-only ke daftar putih instans primary. Hal ini memastikan bahwa daftar putih disinkronkan secara otomatis ke kluster PolarDB.

Catatan
Daftar 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 pemanggilan 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.

Catatan
Selama migrasi logis (sinkronisasi data DTS), kesalahan seperti Precheck Failed dapat terjadi. Dalam hal ini, parameter MigrationStatus adalah PRE_CHECK_FAIL. Anda harus menyelesaikan kesalahan berdasarkan Error Message
ModifyDBClusterMigration - Potong tugas migrasi

Ketika 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).
Penting
- Jika Anda menggunakan alih bencana dengan titik akhir, baca 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 migrasi selesai, jika Anda menemukan ketidakkonsistenan data atau masalah lain, Anda dapat memanggil ModifyDBClusterMigration untuk memutar balik tugas migrasi dan segera mengembalikan kondisi ke kondisi sebelum peningkatan. Setelah itu, Anda juga dapat memanggil CloseDBClusterMigration untuk membatalkan migrasi dan mengembalikan kondisi ke kondisi sebelum alih bencana.
(Opsional) ModifyDtsJobEndpoint - Modifikasi 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 memodifikasi (mengganti) instans database sumber atau tujuan tugas sinkronisasi atau migrasi DTS untuk mengalihkan layanan terkait secara mulus.
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) Batalkan langganan atau lepas instans RDS

Jika layanan Anda berjalan stabil di kluster PolarDB dan instans RDS tidak lagi diperlukan, batalkan langganan 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.

Informasi terkait

Deskripsi kebijakan pencadangan

Kebijakan pencadangan untuk RDS dan PolarDB berbeda. Perbedaannya sebagai berikut:

Siklus pencadangan reguler dan Waktu mulai pencadangan: Pengaturan ini sama. Secara default, PolarDB menggunakan siklus pencadangan reguler dan waktu mulai pencadangan yang sama dengan instans RDS.
Periode retensi pencadangan: Pemetaannya sebagai berikut:
- Jika periode retensi pencadangan RDS adalah 14 hari atau kurang, periode retensi pencadangan Level 1 PolarDB sama dengan periode retensi pencadangan RDS.
- Jika periode retensi pencadangan RDS lebih dari 14 hari tetapi tidak lebih dari 30 hari, periode retensi pencadangan Level 1 PolarDB tetap 14 hari. Pencadangan Level 2 juga diaktifkan, dan periode retensi pencadangan Level 2 PolarDB di wilayah yang sama tetap 30 hari. Jika periode retensi pencadangan RDS lebih dari 30 hari, PolarDB mengaktifkan pencadangan Level 2, dan periode retensi pencadangan Level 2 di wilayah yang sama sama dengan periode retensi pencadangan RDS.
- Jika pencadangan RDS dikonfigurasi untuk retensi jangka panjang, periode retensi pencadangan Level 1 PolarDB tetap 14 hari. Pencadangan Level 2 juga diaktifkan untuk retensi jangka panjang.
Jika pencadangan frekuensi tinggi diaktifkan untuk instans RDS, pencadangan frekuensi tinggi juga diaktifkan untuk kluster PolarDB secara default. Pencadangan frekuensi tinggi: Pemetaan frekuensinya sebagai berikut:
- Jika interval pencadangan frekuensi tinggi RDS adalah 120 menit atau kurang, interval pencadangan frekuensi tinggi PolarDB tetap 120 menit.
- Jika interval pencadangan frekuensi tinggi RDS lebih dari 120 menit tetapi tidak lebih dari 180 menit, interval pencadangan frekuensi tinggi PolarDB tetap 180 menit.
- Untuk interval pencadangan RDS lainnya, interval pencadangan frekuensi tinggi PolarDB tetap 240 menit.

Switchover dengan titik akhir

Selama peningkatan, pilih fitur alih bencana dengan titik akhir untuk secara otomatis menukar titik akhir koneksi antara instans RDS dan kluster PolarDB. Hal ini memungkinkan aplikasi Anda terhubung secara otomatis ke kluster PolarDB tanpa perubahan konfigurasi apa pun.

Penting

Sebelum mengalihkan titik akhir, konfirmasi pemetaan titik akhir koneksi antara instans RDS dan kluster PolarDB. Hal ini mencegah gangguan bisnis.

Diagram alih bencana titik akhir koneksi

Diagram berikut menunjukkan pemetaan default untuk alih bencana titik akhir koneksi antara instans RDS dan kluster PolarDB. Anda dapat menyesuaikan pemetaan ini di konsol selama proses alih bencana.

Catatan

Titik akhir read-only instans RDS mencakup titik akhir read-only di proksi database dan titik akhir koneksi instans read-only.

Catatan

Fitur alih bencana dengan titik akhir tidak mendukung alih bencana alamat IPv6.
Fitur alih bencana dengan titik akhir hanya menukar nama domain titik akhir koneksi untuk instans RDS dan kluster PolarDB. Konfigurasi seperti virtual switch (vSwitch) dan alamat IP virtual (VIP) tidak ditukar.
Hanya titik akhir koneksi yang ada di kedua instans RDS dan kluster PolarDB yang dapat ditukar. Secara default, kluster PolarDB hanya membuat titik akhir utama pribadi dan titik akhir kluster pribadi. Jika instans RDS memiliki lebih dari dua titik akhir koneksi, Anda harus membuat titik akhir koneksi yang sesuai di kluster PolarDB sebelum alih bencana. Jika tidak, titik akhir tidak akan ditukar.
Saat menggunakan fitur alih bencana dengan titik akhir, titik akhir koneksi utama instans RDS dapat ditukar dengan titik akhir utama atau titik akhir kluster default kluster PolarDB. Titik akhir proksi database instans RDS dapat ditukar dengan titik akhir kluster default dan titik akhir kustom kluster PolarDB. Anda juga dapat memilih untuk tidak menukarnya atau menukar beberapa kelompok. Karena kluster PolarDB dapat memiliki hingga tujuh titik akhir kluster, Anda dapat menukar maksimal tujuh titik akhir proksi database dari instans RDS.
Alih bencana saat ini tidak didukung untuk titik akhir read-only kluster dan titik akhir koneksi langsung node instans Edisi Kluster RDS.
Sebelum menggunakan fitur alih bencana dengan titik akhir untuk menukar titik akhir pribadi, pastikan instans RDS dan kluster PolarDB berada di VPC yang sama. Jika tidak, layanan yang ada Anda tidak dapat terhubung setelah alih bencana.
Setelah sinkronisasi inkremental selesai, status kluster PolarDB berubah menjadi Running. Sebelum mengalihkan titik akhir, Anda dapat melakukan operasi seperti mengonfigurasi parameter, menambahkan node read-only, dan menambahkan titik akhir.
Setelah nama domain titik akhir koneksi ditukar, jika Anda perlu login ke kluster PolarDB menggunakan Data Management (DMS), pastikan Anda telah mengonfigurasi ID kluster atau string koneksi yang benar.
Setelah nama domain titik akhir koneksi ditukar, masalah cache resolusi DNS dapat terjadi. Sebelum cache kedaluwarsa, Anda mungkin tidak dapat terhubung ke kluster PolarDB atau kluster PolarDB mungkin hanya mendukung operasi baca tetapi tidak operasi tulis. Bersihkan cache DNS di server Anda.

FAQ

Mengapa penggunaan memori kluster PolarDB tinggi selama proses peningkatan satu klik?

Selama inisialisasi data penuh, engine InnoDB menyimpan cache data di kolam buffer memori innodb_buffer_pool untuk mempercepat operasi baca dan tulis. Proses ini menyebabkan peningkatan penggunaan memori secara keseluruhan.

Setelah peningkatan satu klik selesai, sesuaikan parameter innodb_buffer_pool_size di konsol untuk mengurangi penggunaan memori kolam buffer.