Data Transmission Service:Sinkronisasi satu arah antar instans RDS MySQL

Struktur tabel

• Tabel yang akan disinkronkan harus memiliki PRIMARY KEY atau kendala UNIK dengan semua bidang unik. Tanpa ini, instans tujuan mungkin berisi catatan duplikat.

• Jika Anda memilih tabel (bukan database) sebagai objek sinkronisasi dan berencana mengganti nama tabel atau kolom, satu tugas mendukung hingga 1.000 tabel. Untuk lebih dari 1.000 tabel, konfigurasikan beberapa tugas atau lakukan sinkronisasi di tingkat database.

Log biner

Pengaturan log biner berikut harus diterapkan sebelum DTS dapat membaca perubahan dari sumber:

• binlog_row_image harus diatur ke full. Binary logging diaktifkan secara default pada instans ApsaraDB RDS untuk MySQL, tetapi verifikasi parameter ini. Lihat Ubah parameter instans.

  • Jika sumber adalah database MySQL yang dikelola sendiri: Anda harus mengaktifkan binary logging dan mengatur binlog_format ke row dan binlog_row_image ke full.

  • Jika sumber adalah database MySQL yang dikelola sendiri yang dideploy dalam kluster dual-primary: Anda juga harus mengatur log_slave_updates ke ON untuk memastikan DTS dapat memperoleh semua log biner. Lihat Buat akun untuk database MySQL yang dikelola sendiri dan konfigurasi binary logging.

• Retensi log biner harus minimal 7 hari. Jika DTS tidak dapat mengakses log biner yang diperlukan, tugas gagal dan kehilangan data mungkin terjadi. Lihat Kelola file log biner.

Jangan mengeksekusi pernyataan DDL pada database sumber selama sinkronisasi skema atau sinkronisasi data penuh. Hal ini menyebabkan tugas gagal.

Kompatibilitas versi dan set karakter

• Versi database tujuan harus sama dengan atau lebih baru daripada sumber. Versi tujuan yang lebih lama dapat menyebabkan masalah kompatibilitas.

• Jika database sumber adalah MySQL 8.0.23 atau lebih baru dan mencakup kolom tak terlihat, DTS tidak dapat memperoleh data kolom tersebut — terjadi kehilangan data.

• Jika database tujuan adalah MySQL 8.0.23 atau lebih baru dan mencakup kolom tak terlihat, kolom tujuan untuk menerima data tidak dapat ditemukan, menyebabkan instans DTS gagal dan terjadi kehilangan data.

• Dalam kedua kasus tersebut, jalankan ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuat kolom tak terlihat menjadi terlihat sebelum memulai tugas. Tabel tanpa kunci utama secara otomatis menghasilkan kunci utama tak terlihat; buat juga kunci tersebut terlihat. Lihat Kolom Tak Terlihat dan Kunci Utama Tak Terlihat yang Dihasilkan.

• Jika Anda tidak menggunakan sinkronisasi skema, pastikan kompatibilitas tipe bidang dipertahankan. Misalnya, bidang text di sumber yang dipetakan ke bidang varchar(255) di tujuan dapat menyebabkan pemotongan data.

• Jika data berisi karakter 4-byte (seperti karakter langka atau emoji), tabel tujuan harus menggunakan set karakter UTF8mb4. Jika menggunakan sinkronisasi skema, atur parameter character_set_server ke UTF8mb4 di database tujuan.

• Nama kolom di MySQL tidak peka huruf besar/kecil. Jika sumber memiliki beberapa kolom yang namanya hanya berbeda dalam kapitalisasi, kolom tersebut ditulis ke kolom yang sama di tujuan, menyebabkan hasil yang tidak diinginkan.

DDL Online

• Jangan gunakan pt-online-schema-change untuk DDL online pada tabel yang dipilih sebagai objek sinkronisasi. Gunakan Data Management (DMS) sebagai gantinya. Lihat Lakukan operasi DDL tanpa lock.

• Jika operasi DDL gagal di tujuan, tugas DTS tetap berjalan. Periksa log tugas untuk pernyataan DDL yang gagal. Lihat Lihat log tugas.

• DTS tidak menyinkronkan data yang menggunakan parser yang didefinisikan oleh komentar.

Konsistensi data

• Jangan menulis data dari sumber lain ke tujuan selama sinkronisasi berlangsung. Hal ini menyebabkan ketidakkonsistenan data.

• Data yang dihasilkan oleh operasi perubahan log biner (seperti data yang dipulihkan dari backup fisik atau operasi kaskade) tidak dicatat atau disinkronkan ke tujuan selama tugas berjalan.

Perilaku kunci asing

• Selama sinkronisasi skema, DTS menyinkronkan kunci asing dari sumber ke tujuan.

• Selama sinkronisasi data penuh dan inkremental, DTS sementara menonaktifkan pemeriksaan kendala kunci asing dan operasi kaskade di tingkat session. Operasi pembaruan atau penghapusan kaskade di sumber selama periode ini dapat menyebabkan ketidakkonsistenan data.

Dampak performa

Sinkronisasi data penuh membaca semua data dari database sumber sekali, yang meningkatkan beban pada kedua database. Untuk mengurangi risiko:

• Jalankan tugas sinkronisasi selama jam sepi.

• Perkirakan ruang tabel tujuan akan lebih besar daripada sumber setelah sinkronisasi penuh, karena fragmentasi INSERT konkuren.

• Setelah status tugas berubah menjadi Completed, jalankan analyze table <table_name> untuk memverifikasi bahwa data telah ditulis dengan benar ke tujuan. (Misalnya, alih bencana ketersediaan tinggi (HA) di sumber dapat menyebabkan beberapa data hanya ditulis ke memori.)

Kasus khusus

Untuk sumber MySQL yang dikelola sendiri:

• Jika terjadi alih bencana primary/secondary pada database sumber saat tugas sedang berjalan, tugas gagal.

• DTS menghitung latensi sinkronisasi berdasarkan timestamp data terbaru yang disinkronkan di tujuan dan timestamp saat ini di sumber. Jika tidak ada operasi DML yang dilakukan di sumber dalam waktu lama, latensi mungkin tidak akurat. Jika latensi terlalu tinggi, lakukan operasi DML di sumber untuk memperbaruinya. Jika Anda memilih seluruh database sebagai objek sinkronisasi, Anda dapat membuat tabel heartbeat yang diperbarui setiap detik untuk menjaga akurasi latensi.

• DTS mengeksekusi CREATE DATABASE IF NOT EXISTS 'test' di sumber secara berkala untuk memajukan posisi log biner.

Untuk sumber ApsaraDB RDS untuk MySQL:

• Instans ApsaraDB RDS untuk MySQL 5.6 read-only (yang tidak mencatat log transaksi) tidak dapat digunakan sebagai sumber.

• DTS mengeksekusi CREATE DATABASE IF NOT EXISTS 'test' di sumber secara berkala untuk memajukan posisi log biner.

• Instans ApsaraDB RDS untuk MySQL dengan fitur EncDB yang diaktifkan tidak mendukung sinkronisasi data penuh. Instans dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung sinkronisasi skema, sinkronisasi data penuh, dan sinkronisasi data inkremental.

Jika dukungan teknis DTS memulihkan tugas yang gagal:

• Dukungan mencoba pemulihan dalam waktu 8 jam. Tugas mungkin dimulai ulang dan parameter tugas tertentu mungkin diubah. Parameter database tidak diubah.

Langkah 1: Buka halaman Tugas Sinkronisasi Data

1. Masuk ke Konsol Data Management (DMS).

2. Di bilah navigasi atas, klik Data + AI.

3. Di panel navigasi kiri, pilih DTS (DTS) > Data Synchronization.

Navigasi mungkin berbeda tergantung pada mode dan tata letak Konsol DMS Anda. Lihat Mode simple dan Sesuaikan tata letak dan gaya Konsol DMS. Atau, buka langsung halaman Tugas Sinkronisasi Data di Konsol DTS baru.

Langkah 2: Buat tugas

1. Pilih wilayah tempat instans sinkronisasi data Anda berada.

   Di Konsol DTS baru, pilih wilayah di bilah navigasi atas.

2. Klik Create Task.

3. (Opsional) Klik New Configuration Page di pojok kanan atas halaman.

   Lewati langkah ini jika tombol Back to Previous Version ditampilkan. Halaman konfigurasi baru direkomendasikan.

Langkah 3: Konfigurasi database sumber dan tujuan

Isi parameter berikut untuk sumber dan tujuan:

Langkah 4: Uji konektivitas

Klik Test Connectivity and Proceed.

DTS secara otomatis menambahkan blok CIDR servernya ke daftar putih instans database Alibaba Cloud. Untuk database yang di-host di ECS, DTS menambahkan blok CIDR ke aturan grup keamanan ECS dan Anda harus memastikan instans ECS dapat mengakses database — jika database tersebar di beberapa instans ECS, tambahkan blok CIDR ke grup keamanan setiap instans secara manual. Untuk database on-premises atau database yang di-host oleh penyedia cloud pihak ketiga, tambahkan blok CIDR server DTS ke daftar putih database secara manual. Lihat Blok CIDR server DTS.

Langkah 5: Konfigurasi objek sinkronisasi

Pada langkah Configure Objects, isi parameter berikut:

Mengganti nama objek dengan pemetaan nama objek dapat menyebabkan objek lain yang bergantung padanya gagal disinkronkan.

Langkah 6: Konfigurasi pengaturan lanjutan

Klik Next: Advanced Settings dan isi parameter berikut:

Langkah 7: Konfigurasi verifikasi data (opsional)

Klik Next Step: Data Verification untuk mengatur verifikasi data untuk tugas. Lihat Konfigurasi tugas verifikasi data.

Langkah 8: Jalankan pemeriksaan awal

Klik Next: Save Task Settings and Precheck.

Untuk melihat pratinjau parameter API untuk konfigurasi ini, arahkan kursor ke Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters.

DTS menjalankan pemeriksaan awal sebelum tugas dapat dimulai. Tunggu hingga pemeriksaan awal selesai:

• Jika suatu item gagal, klik View Details untuk melihat penyebabnya dan perbaiki masalah tersebut, lalu klik Precheck Again.

• Jika suatu item menampilkan peringatan, perbaiki masalah tersebut atau klik Confirm Alert Details > Ignore > OK > Precheck Again untuk melanjutkan. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

Langkah 9: Beli instans

Setelah Success Rate mencapai 100%, klik Next: Purchase Instance.

Di halaman buy, konfigurasi hal berikut:

Baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms, lalu klik Buy and Start dan konfirmasi.

Tugas muncul di daftar tugas. Pantau perkembangannya di sana.