全部产品
Search

搜索本产品

    PolarDB：Kloning instansi ApsaraDB RDS untuk MySQL ke cluster PolarDB untuk MySQL

    文档中心

    PolarDB：Kloning instansi ApsaraDB RDS untuk MySQL ke cluster PolarDB untuk MySQL

    更新时间：Jul 06, 2025

    Topik ini menjelaskan prosedur untuk mengkloning instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster dengan satu klik, dua metode kloning dan perbandingannya, manfaat, prasyarat, batasan, serta aturan penagihan.

    Perhatian

    Jika Anda memigrasikan data ke PolarDB cluster menggunakan pengkloningan satu klik, data tambahan dari sumber instansi ApsaraDB RDS untuk MySQL tidak disinkronkan ke PolarDB cluster.

    Catatan

    Untuk informasi lebih lanjut tentang cara menyinkronkan data tambahan dari instansi sumber ApsaraDB RDS untuk MySQL ke PolarDB cluster saat Anda membuat PolarDB cluster, lihat Buat Cluster PolarDB untuk MySQL dengan Meningkatkan Instansi ApsaraDB RDS untuk MySQL.

    Informasi latar belakang

    PolarDB memungkinkan Anda untuk mengkloning data dari instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster. Anda dapat menggunakan metode pengkloningan satu klik untuk membuat PolarDB cluster yang memiliki data yang sama dengan instansi sumber ApsaraDB RDS. PolarDB cluster mempertahankan akun, database, daftar putih IP, dan parameter yang diperlukan dari instansi sumber ApsaraDB RDS.

    Instansi sumber ApsaraDB RDS untuk MySQL dan tujuan PolarDB untuk MySQL cluster harus memenuhi persyaratan berikut:

    • Instansi sumber ApsaraDB RDS untuk MySQL yang menjalankan all MySQL versions dan yang menggunakan all storage types dapat dikloning. Anda dapat mengkloning instansi yang menjalankan MySQL 5.6, 5.7, dan 8.0 serta yang menggunakan SSD lokal dan disk cloud ke PolarDB untuk MySQL cluster dengan satu klik.

    • Instansi ApsaraDB RDS untuk MySQL dapat dikloning ke PolarDB untuk MySQL cluster yang menjalankan the same or different MySQL versions dengan satu klik. Sebagai contoh, Anda dapat mengkloning instansi ApsaraDB RDS untuk MySQL 5.6 ke PolarDB untuk MySQL 5.6 cluster, atau ke PolarDB untuk MySQL 8.0 cluster.

    Catatan

    Metode migrasi logis digunakan dalam skenario berikut: mengkloning instansi ApsaraDB RDS untuk MySQL 8.0, mengkloning instansi ApsaraDB RDS untuk MySQL dengan disk cloud ke PolarDB untuk MySQL cluster, dan mengkloning instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster yang menjalankan versi MySQL yang berbeda. Metode ini diimplementasikan berdasarkan kemampuan sinkronisasi data Data Transmission Service (DTS).

    Perbandingan antara migrasi fisik dan migrasi logis

    Fitur pengkloningan satu klik mendukung migrasi fisik (replikasi fisik) dan migrasi logis (sinkronisasi data melalui DTS).

    • Physical migration: Anda dapat menggunakan metode replikasi fisik untuk menyalin data penuh dari instansi sumber ApsaraDB RDS untuk MySQL ke tujuan PolarDB untuk MySQL cluster.

    • Logical migration: Anda dapat membuat tugas sinkronisasi data pada DTS untuk memigrasikan skema dan data penuh dari instansi sumber ApsaraDB RDS untuk MySQL ke tujuan PolarDB untuk MySQL cluster.

    Tabel berikut membandingkan metode migrasi fisik dan migrasi logis.

    Item

    Migrasi Fisik

    Migrasi Logis

    Apakah DTS diperlukan

    Tidak.

    Ya.

    Apakah migrasi atau sinkronisasi data tambahan didukung

    Tidak.

    Tidak.

    Apakah operasi pada instansi sumber ApsaraDB RDS untuk MySQL terpengaruh

    Tidak.

    Tidak.

    Apakah sumber dan tujuan dapat menjalankan versi MySQL yang berbeda

    Hanya instansi sumber yang menjalankan MySQL 5.6 dan 5.7 dan menggunakan disk lokal yang dapat dikloning ke cluster tujuan yang menjalankan versi MySQL yang sama.

    Versi MySQL bisa sama atau berbeda antara sumber dan tujuan.

    Apakah akun database baru harus dibuat di PolarDB cluster setelah pengkloningan

    Tidak. Setelah pengkloningan, tujuan PolarDB cluster berisi akun dari instansi sumber.

    Tidak. Setelah pengkloningan, tujuan PolarDB cluster berisi akun dari instansi sumber.

    Apakah database baru dapat dimigrasi

    Tidak.

    Tidak.

    Tabel berikut menjelaskan versi MySQL dan jenis penyimpanan yang didukung oleh kedua metode migrasi.

    Versi ApsaraDB RDS untuk MySQL

    Edisi Dasar

    Edisi Ketersediaan Tinggi

    Edisi Kluster

    Edisi Perusahaan

    5.6

    N/A

    SSD Lokal

    N/A

    SSD Lokal

    5.7

    Disk Cloud

    SSD Lokal dan Disk Cloud

    Disk Cloud

    SSD Lokal

    8.0

    Disk Cloud

    SSD Lokal dan Disk Cloud

    Disk Cloud

    SSD Lokal

    Migrasi fisik hanya digunakan untuk mengkloning instansi ApsaraDB RDS untuk MySQL 5.6 atau 5.7 Edisi Ketersediaan Tinggi yang menggunakan SSD lokal ke PolarDB untuk MySQL cluster dengan versi MySQL yang sama. Migrasi logis digunakan untuk mengkloning instansi ApsaraDB RDS untuk MySQL spesifikasi lainnya ke PolarDB untuk MySQL cluster dengan versi yang sama atau berbeda.

    Manfaat

    • Fitur pengkloningan gratis.

    • Tidak ada kehilangan data selama proses pengkloningan.

    Prasyarat

    • Saat migrasi fisik digunakan, instansi sumber ApsaraDB RDS harus memenuhi persyaratan berikut. Migrasi logis tidak tunduk pada persyaratan ini.

      • Untuk ApsaraDB RDS untuk MySQL 5.6, versi minor dari instansi harus 20190815 atau lebih baru.

      • Untuk ApsaraDB RDS untuk MySQL 5.7, versi minor dari instansi harus 20200331 atau lebih baru.

      Catatan

      Anda dapat mengeksekusi pernyataan SHOW VARIABLES LIKE '%rds_release_date%'; untuk melihat versi minor dari instansi sumber ApsaraDB RDS. Jika versi minor lebih awal dari versi yang diperlukan, Anda dapat mengkloning versi minor ke versi terbaru. Untuk informasi lebih lanjut, lihat Perbarui Versi Mesin Minor.

    • Mesin penyimpanan tabel untuk instansi RDS sumber harus InnoDB atau X-Engine.

    • Transparent Data Encryption (TDE) dan SSL dinonaktifkan pada instansi sumber ApsaraDB RDS untuk MySQL. Untuk informasi lebih lanjut, lihat TDE dan SSL. Jika TDE atau SSL diaktifkan, Anda dapat secara manual membuat tugas sinkronisasi data pada DTS untuk memigrasikan instansi sumber ke tujuan PolarDB cluster. Untuk informasi lebih lanjut, lihat Migrasikan Data dari Instansi ApsaraDB RDS untuk MySQL ke Cluster PolarDB untuk MySQL.

    • Jika Database Proxy (Mode Aman) diaktifkan untuk instansi ApsaraDB RDS untuk MySQL, akun istimewa dibuat atau mode koneksi jaringan instansi ApsaraDB RDS untuk MySQL beralih ke mode kinerja tinggi. Untuk informasi lebih lanjut, lihat Buat Akun dan [Perubahan Produk/Perubahan Fitur] Mode Koneksi Jaringan Instansi ApsaraDB RDS Ditingkatkan. 查看数据库模式

    Batasan

    • Anda hanya dapat meningkatkan instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster dengan versi MySQL yang sama atau lebih baru, tetapi tidak ke cluster dengan versi MySQL yang lebih lama.

      Sebagai contoh, Anda tidak dapat meningkatkan instansi ApsaraDB RDS untuk MySQL 5.7 ke PolarDB untuk MySQL 5.6 cluster, atau meningkatkan instansi ApsaraDB RDS untuk MySQL 8.0.2 ke PolarDB untuk MySQL 8.0.1 cluster.

    • Metode migrasi fisik tunduk pada batasan berikut:

      • Migrasi data lintas wilayah tidak didukung.

      • Anda tidak dapat mengonfigurasi parameter instansi sumber ApsaraDB RDS untuk MySQL selama migrasi data.

    • Metode migrasi logis tunduk pada batasan berikut:

      • Migrasi data lintas wilayah tidak didukung.

      • Anda tidak dapat mengonfigurasi parameter instansi sumber ApsaraDB RDS untuk PostgreSQL selama migrasi data.

      • Instansi sumber ApsaraDB RDS untuk PostgreSQL tunduk pada batasan yang dijelaskan dalam tabel berikut.

        Item

        Deskripsi

        Batasan pada instansi sumber

        • Tabel yang akan disinkronkan harus memiliki PRIMARY KEY atau kendala UNIQUE, dan semua bidang harus unik. Jika tidak, database tujuan mungkin berisi catatan data duplikat.

        • Jika Anda memilih tabel sebagai objek yang akan disinkronkan dan ingin mengedit tabel, seperti mengganti nama tabel atau kolom, Anda dapat menyinkronkan hingga 1.000 tabel dalam satu tugas sinkronisasi data. Jika Anda menjalankan tugas untuk menyinkronkan lebih dari 1.000 tabel, permintaan kesalahan terjadi. Dalam hal ini, kami sarankan Anda mengonfigurasi beberapa tugas untuk menyinkronkan tabel dalam batch atau mengonfigurasi tugas untuk menyinkronkan seluruh database.

        • Pencatatan biner: Fitur pencatatan biner harus diaktifkan. Untuk informasi lebih lanjut tentang cara mengaktifkan pencatatan biner, lihat Ubah parameter instansi ApsaraDB RDS untuk MySQL. Selain itu, parameter binlog_row_image harus diatur ke full. Jika tidak, pesan kesalahan dikembalikan selama pra-pemeriksaan, dan tugas sinkronisasi data tidak dapat dimulai.

      • Batasan berikut juga berlaku:

        Item

        Deskripsi

        Batasan lainnya

        • Sebelum Anda menyinkronkan data, evaluasi dampak sinkronisasi data pada kinerja database sumber dan tujuan. Kami sarankan Anda menyinkronkan data selama jam-jam sepi. Selama sinkronisasi data penuh awal, DTS menggunakan sumber daya baca dan tulis dari database sumber dan tujuan. Ini dapat meningkatkan beban pada server database.

        • Selama sinkronisasi data penuh awal, operasi INSERT bersamaan menyebabkan fragmentasi dalam tabel database tujuan. Oleh karena itu, setelah sinkronisasi data penuh awal selesai, ukuran tablespace yang digunakan oleh database tujuan lebih besar daripada database sumber.

        • Jika Anda memilih satu atau lebih tabel alih-alih seluruh database sebagai objek untuk disinkronkan, jangan gunakan gh-ost atau pt-online-schema-change untuk melakukan operasi DDL pada tabel selama sinkronisasi data. Jika tidak, data mungkin gagal disinkronkan.

          Jika Anda hanya menggunakan DTS untuk menulis data ke database tujuan, Anda dapat menggunakan Data Management (DMS) untuk melakukan operasi DDL online pada tabel sumber selama sinkronisasi data. Untuk informasi lebih lanjut, lihat Ubah skema tanpa mengunci tabel.

        • Ketidaksesuaian data antara database sumber dan tujuan terjadi jika data dari sumber lain ditulis ke database tujuan selama sinkronisasi data. Sebagai contoh, jika Anda menggunakan DMS untuk mengeksekusi pernyataan DDL online sementara data dari sumber lain ditulis ke database tujuan, kehilangan data mungkin terjadi di database tujuan.

        • Secara default, DTS menonaktifkan kendala FOREIGN KEY untuk database tujuan dalam tugas sinkronisasi data. Oleh karena itu, operasi tertentu seperti operasi kaskade dan hapus operasi dari database sumber tidak disinkronkan ke database tujuan.

    Aturan penagihan

    • Aturan penagihan berikut berlaku untuk metode migrasi fisik:

      Anda tidak dikenakan biaya untuk migrasi data dari instansi sumber ApsaraDB RDS untuk MySQL ke PolarDB cluster. Anda hanya dikenakan biaya untuk pembelian PolarDB cluster. Untuk informasi lebih lanjut, lihat Ikhtisar Item Penagihan.

    • Aturan penagihan berikut berlaku untuk metode migrasi logis:

      Anda dikenakan biaya untuk pembelian PolarDB cluster dan pembuatan tugas sinkronisasi data pada DTS. Namun, fitur peningkatan sedang dalam fase uji coba gratis. Tidak ada biaya yang dikenakan untuk tugas sinkronisasi dalam 30 hari setelah dibuat. Uji coba gratis tidak tersedia untuk akun operator jaringan virtual (VNO) dan pengguna RAM. Tabel berikut menjelaskan aturan penagihan untuk metode migrasi logis.

      Objek migrasi

      Aturan penagihan

      Sinkronisasi skema dan sinkronisasi data penuh

      Tidak ada biaya yang dihasilkan untuk tugas sinkronisasi dalam 30 hari setelah tugas dibuat.

      Setelah lebih dari 30 hari, tugas sinkronisasi akan dibatalkan.

      Catatan

      Anda dapat pergi ke Halaman Sinkronisasi Data konsol DTS baru untuk melihat waktu tersisa tugas sinkronisasi.

    Bagian berikut menjelaskan prosedur untuk mengkloning instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster.

    Pra-pemeriksaan untuk migrasi logis

    Pra-pemeriksaan apakah peran terkait layanan untuk PolarDB telah dibuat

    Sebelum Anda menggunakan metode migrasi logis (sinkronisasi data melalui DTS) untuk melakukan pengkloningan satu klik, periksa apakah peran terkait layanan untuk PolarDB telah dibuat. Lakukan langkah-langkah berikut:

    1. Masuk ke halaman Roles di Konsol Resource Access Management (RAM).

    2. Periksa apakah peran terkait layanan bernama AliyunServiceRoleForPolarDB sudah ada dalam daftar seperti yang ditunjukkan pada gambar berikut.image

      1. Jika peran terkait layanan ada dalam daftar, lewati pemeriksaan ini.

      2. Jika peran terkait layanan tidak ada dalam daftar, lanjutkan pemeriksaan ini.

    3. Di pojok kiri atas, klik Create Role. Di halaman Create Role, klik Create Service Linked Role di pojok kanan atas.image

    4. Di halaman Buat Peran Terkait Layanan, pilih ApsaraDB for POLARDB dari daftar drop-down Select Service. Klik Create Service Linked Role.

      image

    Pra-pemeriksaan apakah akun sistem redundan telah dihapus dari instansi sumber

    Untuk memastikan kompatibilitas antara ApsaraDB RDS untuk MySQL dan PolarDB dalam hal struktur akun sistem dan mencegah akun sistem tujuan PolarDB cluster tertimpa selama pengkloningan, pastikan bahwa akun root dan aliyun_root tidak ada di instansi sumber ApsaraDB RDS pada saat yang bersamaan. Sebelum Anda memulai proses pengkloningan, kami sarankan Anda menghapus akun sistem ekstra dari instansi sumber ApsaraDB untuk RDS.

    Tabel berikut mencantumkan nama akun sistem yang benar untuk setiap versi ApsaraDB RDS untuk MySQL.

    Versi ApsaraDB RDS untuk MySQL

    Nama akun sistem yang benar

    RDS MySQL 5.6

    root

    RDS MySQL 5.7

    aliyun_root

    RDS MySQL 8.0

    aliyun_root

    Selain akun sistem yang sesuai untuk setiap versi yang disebutkan dalam tabel sebelumnya, semua akun sistem lainnya harus dihapus. Sebagai contoh, aliyun_root benar dalam RDS MySQL 5.7. Jika Anda membuat root di konsol, Anda harus menghapusnya. Sebelum Anda menghapus root, konfirmasikan bahwa itu tidak digunakan dalam bisnis Anda.

    Catatan

    Akun sistem ekstra mungkin telah dibuat oleh pengguna atau diwarisi dari versi sumber selama peningkatan versi. Dalam beberapa skenario, akun tertentu mungkin tidak terlihat di konsol.

    Contoh berikut menunjukkan cara menghapus akun sistem ekstra dari instansi ApsaraDB RDS untuk MySQL 5.6:

    1. Gunakan akun istimewa untuk terhubung ke database.

    2. Temukan semua akun sistem root dan aliyun_root.

      SELECT * FROM mysql.user WHERE `user` IN ('root', 'aliyun_root');

    3. Hapus akun sistem ekstra. Nama akun sistem yang benar dari ApsaraDB RDS untuk MySQL 5.6 adalah root. Oleh karena itu, Anda harus menghapus akun aliyun_root.

      DELETE FROM mysql.user WHERE `user` = 'aliyun_root' LIMIT n;

    Langkah 1: Migrasikan data dari instansi sumber ApsaraDB RDS untuk MySQL

    Pada langkah ini, sebuah PolarDB cluster dibuat. Cluster tersebut menyimpan data yang sama dengan instansi sumber ApsaraDB RDS untuk MySQL.

    1. Masuk ke Konsol PolarDB.

    2. Di pojok kiri atas, pilih wilayah tempat cluster diterapkan.

    3. Klik Create Cluster.

    4. Atur Billing Method ke Subscription, Pay-as-you-go, atau Serverless.

      • Berlangganan: Anda harus membayar di muka untuk node komputasi saat Anda membuat cluster. Penyimpanan ditagih berdasarkan penggunaan aktual per jam, dan biaya akan dipotong dari akun Anda secara per jam.

      • Bayar sesuai pemakaian: Pembayaran di muka tidak diperlukan. Anda akan dikenakan biaya untuk node komputasi dan jumlah penyimpanan yang dikonsumsi oleh data Anda. Biaya ini akan dipotong dari akun Anda secara per jam.

      • Serverless: Pembayaran di muka tidak diperlukan. Sumber daya seperti node komputasi, ruang penyimpanan, dan PolarProxy secara dinamis diskalakan berdasarkan permintaan aktual. Anda akan dikenakan biaya berdasarkan penggunaan aktual dari sumber daya yang diskalakan ini.

    5. Konfigurasikan parameter berikut.

      Catatan

      Untuk informasi tentang parameter yang tidak dijelaskan dalam tabel berikut, lihat Beli Cluster.

      Parameter

      Deskripsi

      Creation Method

      Pilih Clone from RDS.

      Region

      Wilayah tempat instansi sumber ApsaraDB RDS untuk MySQL diterapkan.

      Catatan

      Tujuan PolarDB cluster juga harus diterapkan di wilayah ini.

      Source RDS Version

      Versi mesin instansi RDS sumber. Anda dapat memilih 5.6, 5.7, atau 8.0.

      Source RDS Instance

      Instansi sumber ApsaraDB RDS untuk MySQL. Instansi ApsaraDB RDS untuk MySQL hanya-baca tidak ditampilkan.

      Database Engine

      Versi mesin database tujuan PolarDB cluster. Anda dapat memilih versi yang sama dengan instansi sumber ApsaraDB RDS untuk MySQL atau versi yang berbeda.

      Node Specification

      Spesifikasi node cluster. Anda dapat menentukan spesifikasi node berdasarkan kebutuhan bisnis Anda. Kami sarankan Anda memilih spesifikasi yang sama atau lebih tinggi dari spesifikasi instansi sumber ApsaraDB RDS untuk MySQL. Untuk informasi lebih lanjut tentang PolarDB spesifikasi node, lihat Spesifikasi node komputasi PolarDB untuk MySQL Edisi Perusahaan.

    6. Di pojok kanan atas halaman, periksa konfigurasi cluster dan konfigurasikan parameter Duration, Quantity, dan Auto-renewal. Parameter Durasi hanya tersedia untuk cluster berlangganan.

    7. Baca dan pilih syarat layanan. Klik Confirm Order.

    8. Di halaman Purchase, konfirmasikan pesanan dan metode pembayaran, lalu klik Purchase.

      Catatan

      • Setelah Anda menyelesaikan pembayaran, tunggu 10 hingga 15 menit. Kemudian, Anda dapat melihat cluster baru yang dibuat di halaman Cluster.

      • Jika node tertentu dalam cluster berada dalam status Dibuat, cluster masih dalam proses pembuatan dan tidak tersedia. Cluster hanya tersedia ketika berada dalam status Berjalan.

      • Pastikan Anda telah memilih wilayah tempat cluster diterapkan. Jika tidak, Anda tidak dapat melihat cluster.

    9. Masuk ke Konsol PolarDB dan periksa status PolarDB cluster baru.

      Catatan

      Jika metode migrasi logis digunakan, klik ID cluster untuk pergi ke halaman Basic Information dan lihat status migrasi. Jika bidang Status di bagian Migrasi RDS adalah Precheck Failed, ikuti instruksi dalam error message untuk menyelesaikan masalah.预检查失败

      Sebagai contoh, jika pemicu dibuat di instansi sumber ApsaraDB RDS untuk MySQL, pra-pemeriksaan gagal dan pesan kesalahan "Instansi RDS memiliki pemicu." dilaporkan. Anda dapat menghapus pemicu dan kemudian klik Continue Migration. Atau, Anda dapat klik Cancel Migration dan kemudian secara manual buat tugas sinkronisasi data di konsol DTS. Untuk informasi lebih lanjut, lihat Konfigurasikan Tugas Sinkronisasi Data untuk Database Sumber yang Berisi Pemicu.

      Anda juga dapat klik Cancel untuk membatalkan tugas migrasi. Untuk informasi lebih lanjut, lihat FAQ.

    Langkah 2: Lihat detail tugas sinkronisasi data (hanya untuk migrasi logis)

    Jika metode migrasi logis digunakan, klik ID cluster untuk pergi ke halaman Basic Information dan lihat status migrasi. Jika terjadi kesalahan migrasi (seperti kegagalan pra-pemeriksaan) atau pengecualian lainnya (seperti latensi replikasi sangat tinggi), Anda dapat pergi ke halaman detail tugas sinkronisasi data untuk melihat detailnya.

    1. Masuk ke Konsol PolarDB.

    2. Temukan cluster target dan klik ID-nya.

    3. Di bagian RDS Migration halaman Basic Information, klik nama DTS Data Synchronization Task untuk pergi ke daftar tugas sinkronisasi data di konsol DTS.

      DTS任务

    4. Temukan tugas sinkronisasi data. Anda dapat melihat detail kegagalan pra-pemeriksaan, detail tugas sinkronisasi data, dan log tugas sinkronisasi data.

      进入详情详情

    FAQ

    • Apa perbedaan antara meningkatkan instansi ApsaraDB RDS untuk MySQL ke cluster PolarDB untuk MySQL dan mengkloning instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL cluster?

      Tabel berikut menjelaskan perbedaan tersebut.

      Item

      Menigkatkan Instansi ApsaraDB RDS untuk MySQL ke Cluster PolarDB untuk MySQL

      Mengkloning Instansi ApsaraDB RDS untuk MySQL ke PolarDB untuk MySQL Cluster

      Apakah migrasi atau sinkronisasi data tambahan didukung

      Ya.

      Tidak.

      Apakah operasi pada instansi sumber terpengaruh

      Tidak.

      Tidak.

      Apakah database sumber dan tujuan dapat menggunakan versi MySQL yang berbeda

      Ya.

      Ya.

    • Apakah instansi sumber ApsaraDB RDS untuk MySQL terpengaruh saat data dikloning dari instansi ApsaraDB RDS untuk MySQL?

      Tidak, pengkloningan data tidak mengganggu operasi instansi sumber ApsaraDB RDS untuk MySQL tetapi mengonsumsi beberapa sumber daya dari instansi sumber.

    • Apa yang terjadi saat saya membatalkan migrasi?

      Setelah Anda membatalkan migrasi, dampak berikut terjadi:

      • Tautan sinkronisasi dari instansi sumber ke cluster tujuan terputus. Instansi sumber tidak lagi terkait dengan cluster tujuan.

      • Cluster tujuan menjadi dapat dibaca dan ditulis dan tidak dilepaskan secara otomatis. Jika Anda tidak lagi menggunakan cluster tujuan, lepaskan cluster sesegera mungkin untuk mencegah biaya tambahan.

      • Anda dapat menentukan apakah akan menonaktifkan fitur pencatatan biner untuk cluster saat Anda secara manual membatalkan migrasi. Fitur pencatatan biner tidak dinonaktifkan saat migrasi dibatalkan secara otomatis.

        Catatan

        Jika Anda menonaktifkan fitur pencatatan biner untuk cluster, kinerja tulis cluster sedikit meningkat. Setelah Anda menonaktifkan fitur pencatatan biner, catatan biner yang ada tetap ada. Untuk menghapus catatan biner, Anda dapat terlebih dahulu mengurangi periode retensi untuk catatan biner. Setelah catatan biner dihapus secara otomatis, Anda kemudian dapat menonaktifkan fitur pencatatan biner. Setelah Anda menonaktifkan fitur pencatatan biner, cluster secara otomatis restart. Tugas restart selesai dalam 5 menit. Layanan terganggu selama sekitar 40 detik selama restart. Durasi restart bervariasi berdasarkan jumlah data dan jumlah tabel. Kami sarankan Anda menonaktifkan fitur pencatatan biner selama jam-jam sepi dan pastikan aplikasi Anda dapat secara otomatis menyambung kembali ke layanan database.

    Operasi API terkait

    API

    Operasi

    CreateDBCluster

    Membuat PolarDB cluster.

    Catatan

    Jika Anda membuat cluster PolarDB dengan mengkloning instansi ApsaraDB RDS untuk MySQL, atur CreationOption ke CloneFromRDS.

    Apa yang harus dilakukan selanjutnya

    Anda harus mengubah titik akhir tempat aplikasi Anda mengakses database ke titik akhir PolarDB cluster sesegera mungkin. Untuk informasi lebih lanjut, lihat Kelola Titik Akhir Cluster.