Mengelola Server Fleksibel Azure Database for MySQL

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

Replikasi data masuk memungkinkan Anda menyinkronkan data dari server MySQL eksternal ke dalam instans server fleksibel Azure Database for MySQL. Server eksternal dapat berada di lokal, di komputer virtual, server tunggal Azure Database for MySQL, atau layanan database yang dihosting oleh penyedia cloud lainnya. Replikasi data-in didasarkan pada posisi file log biner (binlog) atau replikasi berbasis GTID. Untuk mempelajari selengkapnya tentang replikasi binlog, lihat Replikasi MySQL.

Catatan

Mengonfigurasi replikasi Data-in untuk server yang diaktifkan dengan ketersediaan tinggi hanya didukung melalui replikasi berbasis GTID.

Kapan harus menggunakan Replikasi dalam data

Skenario utama yang perlu dipertimbangkan tentang penggunaan Replikasi dalam data adalah:

  • Sinkronisasi Data Hibrid: Dengan replikasi Data-in, Anda dapat menjaga data tetap sinkron antara server lokal Anda dan server fleksibel Azure Database for MySQL. Sinkronisasi ini membantu membuat aplikasi hibrid. Metode ini menarik ketika Anda memiliki server database lokal yang ada tetapi ingin memindahkan data ke wilayah yang lebih dekat ke pengguna akhir.
  • Sinkronisasi Multi-Cloud: Untuk solusi cloud yang kompleks, gunakan Replikasi Data-in untuk menyinkronkan data antara server fleksibel Azure Database for MySQL dan penyedia cloud yang berbeda, termasuk komputer virtual dan layanan database yang dihosting di cloud tersebut.
  • Migrasi: Pelanggan dapat bermigrasi dalam Waktu Minimal menggunakan alat sumber terbuka seperti MyDumper/MyLoader dengan replikasi Data-in. Pemotongan selektif beban produksi dari database sumber ke tujuan dapat dilakukan dengan Replikasi dalam data.

Untuk skenario migrasi, gunakan Azure Database Migration Service(DMS).

Batasan dan pertimbangan

Data tidak direplikasi

database sistem mysql di server sumber tidak direplikasi. Selain itu, perubahan pada akun dan izin di server sumber tidak direplikasi. Jika Anda membuat akun di server sumber dan akun ini perlu mengakses server replika, buat akun yang sama secara manual di server replika. Untuk memahami tabel dalam database sistem, lihat manual MySQL.

Replikasi data masuk didukung pada server yang diaktifkan Ketersediaan Tinggi (HA)

Dukungan untuk replikasi data masuk untuk server dengan ketersediaan tinggi (HA) yang diaktifkan hanya tersedia melalui replikasi berbasis GTID.

Prosedur tersimpan untuk replikasi menggunakan GTID tersedia di semua server berkemampuan HA dengan nama mysql.az_replication_change_master_with_gtid.

Filter

Parameter replicate_wild_ignore_table membuat filter replikasi untuk tabel di server replika. Untuk mengubah parameter ini dari portal Azure, navigasikan ke instans server fleksibel Azure Database for MySQL yang digunakan sebagai replika dan pilih "Parameter Server" untuk melihat/mengedit replicate_wild_ignore_table parameter.

Persyaratan

  • Versi server sumber harus setidaknya berupa MySQL versi 5.7.
  • Rekomendasi kami adalah menggunakan versi yang sama untuk versi server sumber dan replika. Misalnya, keduanya harus MySQL versi 5.7, atau keduanya harus MySQL versi 8.0.
  • Rekomendasi kami adalah menggunakan kunci primer di setiap tabel. Jika kita memiliki tabel tanpa kunci primer, Anda mungkin menghadapi kelambatan dalam replikasi.
  • Server sumber harus menggunakan mesin MySQL InnoDB.
  • Pengguna harus memiliki izin yang tepat untuk mengonfigurasi pengelogan biner dan membuat pengguna baru di server sumber.
  • File log biner di server sumber tidak boleh dibersihkan sebelum replika menerapkan perubahan tersebut. Jika sumbernya adalah server fleksibel Azure Database for MySQL, lihat cara mengonfigurasi binlog_expire_logs_seconds untuk server fleksibel atau Server tunggal
  • Jika server sumber mengaktifkan SSL, pastikan sertifikat SSL CA yang disediakan untuk domain telah disertakan dalam prosedur tersimpan mysql.az_replication_change_master. Lihat contoh berikut dan parameter master_ssl_ca.
  • Pastikan komputer yang menghosting server sumber mengizinkan lalu lintas masuk dan keluar di port 3306.
  • Dengan akses publik, pastikan bahwa server sumber memiliki alamat IP publik, bahwa DNS dapat diakses secara publik, atau bahwa server sumber memiliki nama domain yang sepenuhnya memenuhi syarat (FQDN).
  • Dengan akses privat, pastikan bahwa nama server sumber dapat diselesaikan dan dapat diakses dari VNet tempat instans server fleksibel Azure Database for MySQL berjalan. (Untuk detail selengkapnya, kunjungi Resolusi nama untuk sumber daya di jaringan virtual Azure).

Kunci Primer Tak Terlihat yang Dihasilkan

Untuk MySQL versi 8.0 ke atas, Generated Invisible Primary Keys (GIPK) diaktifkan secara default untuk semua instans server fleksibel Azure Database for MySQL. Server MySQL 8.0+ menambahkan kolom yang tidak terlihat my_row_id ke tabel dan kunci utama pada kolom tersebut, tempat tabel InnoDB dibuat tanpa kunci primer eksplisit. Fitur ini, ketika diaktifkan dapat berdampak pada beberapa kasus penggunaan replikasi data-in, seperti yang dijelaskan di bawah ini:

  • Replikasi data masuk gagal dengan kesalahan replikasi: "KESALAHAN 1068 (42000): Beberapa kunci primer ditentukan" jika server sumber membuat kunci Primer pada tabel tanpa Kunci Primer. Untuk mitigasi, jalankan perintah sql berikut, lewati kesalahan replikasi dan mulai ulang replikasi data-in.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • Replikasi data masuk gagal dengan kesalahan replikasi: "KESALAHAN 1075 (42000): Definisi tabel salah; hanya ada satu kolom otomatis dan harus didefinisikan sebagai kunci" jika server sumber menambahkan kolom auto_increment sebagai Kunci Unik. Untuk mitigasi, jalankan perintah sql berikut, atur "sql_generate_invisible_primary_key" sebagai NONAKTIF, lewati kesalahan replikasi, dan mulai ulang replikasi data masuk.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • Replikasi data masuk gagal jika server sumber menjalankan SQL lain yang tidak didukung saat "sql_generate_invisible_primary_key" AKTIF. Misalnya, buat tabel partisi. Dalam skenario seperti itu, mitigasi adalah mengatur "sql_generate_invisible_primary_key" sebagai NONAKTIF dan memulai ulang replikasi data-in.

Langkah berikutnya