Streaming data dari database MySQL

Datastream memungkinkan Anda mereplikasi data historis dan perubahan yang sedang berlangsung dari database MySQL sumber ke tujuan untuk analisis real-time dan sinkronisasi database.

Sebelum mengonfigurasi sumber MySQL, tinjau perilaku replikasi, versi dan jenis database yang didukung, praktik terbaik, dan batasan umum di Datastream.

Perilaku

Bagian ini menjelaskan perilaku sumber MySQL saat Anda mereplikasi data menggunakan Datastream. Saat menyerap data dari database MySQL, Anda dapat menggunakan replikasi berbasis binlog atau replikasi berbasis ID transaksi global (GTID). Anda memilih metode CDC saat membuat streaming.

Replikasi berbasis binlog

Datastream dapat menggunakan file log biner untuk menyimpan data perubahan data dalam database MySQL. Informasi yang terdapat dalam file log ini kemudian direplikasi ke tujuan untuk mereproduksi perubahan yang dibuat pada sumber.

Karakteristik utama replikasi berbasis binlog di Datastream adalah:

  • Semua database atau database tertentu dari sumber MySQL tertentu, serta semua tabel dari database atau tabel tertentu, dapat dipilih.
  • Semua data historis direplikasi.
  • Semua perubahan bahasa pengolahan data (DML), seperti penyisipan, pembaruan, dan penghapusan dari database dan tabel yang ditentukan, akan direplikasi.
  • Hanya perubahan yang di-commit yang direplikasi.

Replikasi berbasis ID transaksi global (GTID)

Datastream juga mendukung replikasi berbasis ID global (GTID).

ID transaksi global (GTID) adalah ID unik yang dibuat dan dikaitkan dengan setiap transaksi yang di-commit di sumber MySQL. ID ini unik tidak hanya untuk sumber asalnya, tetapi juga di semua server dalam topologi replikasi tertentu, berbeda dengan replikasi berbasis log biner yang setiap node dalam cluster database-nya mempertahankan file binlog-nya sendiri, dengan penomorannya sendiri. Mempertahankan file dan penomoran binlog yang terpisah mungkin menjadi masalah jika terjadi kegagalan atau periode nonaktif yang direncanakan, karena kontinuitas binlog terputus dan replikasi berbasis binlog gagal.

Replikasi berbasis GTID mendukung failover, cluster database yang dikelola sendiri, dan terus berfungsi terlepas dari perubahan dalam cluster database.

Karakteristik utama replikasi berbasis GTID di Datastream adalah:

  • Semua database atau database tertentu dari sumber MySQL tertentu, serta semua tabel dari database atau tabel tertentu, dapat dipilih.
  • Semua data historis direplikasi.
  • Semua perubahan bahasa pengolahan data (DML), seperti penyisipan, pembaruan, dan penghapusan dari database dan tabel yang ditentukan, akan direplikasi.
  • Hanya perubahan yang di-commit yang direplikasi.
  • Dukungan yang lancar untuk failover.

Beralih dari replikasi berbasis binlog ke replikasi berbasis GTID

Jika Anda ingin mengupdate aliran data dan beralih dari replikasi berbasis binlog ke replikasi berbasis GTID tanpa perlu melakukan pengisian ulang, lakukan langkah-langkah berikut:

  1. Pastikan semua persyaratan untuk replikasi berbasis GTID terpenuhi. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi database MySQL sumber.
  2. Jika ingin, buat dan jalankan pengujian aliran data berbasis GTID. Untuk mengetahui informasi selengkapnya, lihat Membuat aliran data.
  3. Buat aliran data berbasis GTID. Jangan mulai dulu.
  4. Hentikan traffic aplikasi ke database sumber.
  5. Jeda aliran data berbasis binlog yang ada. Untuk mengetahui informasi selengkapnya, lihat Menjeda streaming.
  6. Tunggu beberapa menit untuk memastikan Datastream telah mengikuti database. Anda dapat memeriksanya menggunakan metrik di tab Monitoring, di halaman Stream details untuk aliran data Anda. Nilai untuk keaktualan data dan Throughput harus 0.
  7. Mulai streaming berbasis GTID. Untuk mengetahui informasi selengkapnya, lihat Memulai streaming.
  8. Lanjutkan traffic ke database sumber.

Jika melakukan pengisian ulang tidak menjadi masalah, Anda dapat memotong tabel di BigQuery, menghapus aliran data lama, dan memulai aliran data baru dengan pengisian ulang. Untuk mengetahui informasi selengkapnya tentang cara mengelola pengisian ulang, lihat Mengelola pengisian ulang untuk objek streaming.

Versi

Datastream mendukung versi database MySQL berikut:

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (hanya didukung untuk replikasi berbasis GTID)

Datastream mendukung jenis database MySQL berikut:

Praktik terbaik

Bagian ini menjelaskan praktik terbaik yang direkomendasikan untuk mengonfigurasi sumber MySQL Anda agar dapat digunakan dengan Datastream.

Menggunakan GTID untuk penyiapan ketersediaan tinggi

Jika sumber MySQL produksi Anda menggunakan replika atau konfigurasi ketersediaan tinggi lainnya, gunakan replikasi berbasis GTID.

Replikasi berbasis posisi dan file binlog dapat terganggu selama failover database karena saat instance utama gagal, instance utama baru memiliki histori binlog yang berbeda. Dalam kasus seperti ini, Datastream akan kehilangan posisinya dan tidak dapat dilanjutkan.

GTID menetapkan ID unik untuk setiap transaksi di seluruh topologi replikasi Anda (utama dan replika). Setelah failover, Datastream dapat melanjutkan dari GTID terakhir yang dicatat di instance utama baru, tanpa perlu mengetahui file atau posisi binlog.

Rekomendasi: untuk sumber MySQL produksi apa pun dengan konfigurasi replika atau ketersediaan tinggi, penggunaan metode CDC GTID wajib dilakukan untuk replikasi data yang tangguh dan andal.

Menentukan ukuran replika baca dengan tepat

Jika Anda mengonfigurasi Datastream untuk mereplikasi dari replika baca, Anda dapat mengalami jeda ganda, yang merupakan kombinasi dari jeda replikasi MySQL (dari utama ke replika) dan jeda replikasi Datastream (dari replika ke tujuan). Replika baca sering kali disediakan dengan resource (CPU, RAM, IOPS) yang lebih sedikit daripada replika utama untuk menghemat biaya, sehingga dapat menyebabkan replika baca tertinggal dari replika utama selama periode penulisan tinggi.

Rekomendasi: saat menggunakan replika baca sebagai sumber untuk Datastream, sediakan resource yang sebanding dengan resource utama, sehingga replika dapat mengimbangi throughput tulis utama.

Meningkatkan throughput untuk metode CDC binlog

Jika Anda menggunakan replikasi berbasis binlog dan mengalami latensi tinggi karena volume penulisan sumber yang besar menghasilkan file binlog lebih cepat daripada yang dapat diproses oleh satu tugas, tingkatkan throughput dengan menyesuaikan parameter maxConcurrentCdcTasks. Parameter ini mengontrol jumlah tugas CDC yang dijalankan aliran data secara paralel. Meningkatkan nilai untuk parameter ini memungkinkan Datastream memproses lebih banyak file binlog secara serentak.

Rekomendasi: Untuk menentukan nilai yang sesuai untuk keaktualan data, pantau tingkat pembuatan binlog server MySQL Anda selama jam puncak. Anda dapat melakukannya dengan mengamati kecepatan pembuatan dan rotasi file binlog baru di direktori data MySQL, atau dengan menggunakan alat pemantauan MySQL untuk melacak pertumbuhan log biner. Misalnya, jika sumber Anda menghasilkan 10 file binlog per menit selama waktu puncak, menetapkan maxConcurrentCdcTasks ke nilai seperti 10-15 akan memungkinkan Datastream memproses file ini secara paralel, sehingga mencegah backlog.

Anda dapat meningkatkan maxConcurrentCdcTasks hingga nilai maksimum yang didukung, yaitu 50, asalkan beban pada database sumber tetap terkendali. Untuk mengetahui informasi selengkapnya, lihat Kontrol konkurensi streaming.

Menentukan ukuran parameter max_allowed_packet dengan benar

Setelan max_allowed_packet default di MySQL (misalnya, 16 MB-64 MB) mungkin terlalu kecil. Jika satu baris dengan kolom jenis BLOB, JSON, atau TEXT yang besar, atau satu transaksi besar melebihi ukuran ini, MySQL akan menghentikan koneksi Datastream, sehingga menyebabkan aliran data gagal dengan error seperti Packet for query is too large atau Got a packet bigger than 'max_allowed_packet' bytes.

Rekomendasi: tetapkan parameter max_allowed_packet di server MySQL Anda ke nilai maksimum yang diizinkan, yaitu 1G. Hal ini memastikan bahwa server dapat menangani baris atau transaksi besar yang perlu dibaca Datastream dari binlog.

Batasan umum

Batasan umum untuk menggunakan database MySQL sebagai sumber meliputi:

  • Streaming dibatasi hingga 10.000 tabel.
  • Tabel yang direplikasi harus menggunakan mesin penyimpanan InnoDB. Tabel yang menggunakan mesin penyimpanan MyISAM tidak didukung dan gagal dalam validasi aliran data.
  • Tabel yang memiliki kunci utama yang ditentukan sebagai INVISIBLE tidak dapat diisi ulang.
  • Tabel yang memiliki lebih dari 500 juta baris tidak dapat diisi ulang kecuali jika kondisi berikut terpenuhi:
    1. Tabel memiliki indeks unik.
    2. Tidak ada kolom indeks yang nullable.
    3. Indeks tidak menurun.
    4. Semua kolom indeks disertakan dalam aliran data.
  • Datastream secara berkala mengambil skema terbaru dari sumber saat peristiwa diproses. Jika skema berubah, Datastream akan mendeteksi perubahan skema dan memicu pengambilan skema. Namun, beberapa peristiwa mungkin diproses secara tidak benar atau dihapus di antara pengambilan skema, yang dapat menyebabkan perbedaan data.
  • Tidak semua perubahan pada skema sumber dapat dideteksi secara otomatis, sehingga dapat menyebabkan kerusakan data. Perubahan skema berikut dapat menyebabkan kerusakan data atau kegagalan memproses peristiwa di downstream:
    • Menghapus kolom
    • Menambahkan kolom ke bagian tengah tabel
    • Mengubah jenis data kolom
    • Mengurutkan ulang kolom
    • Menghapus tabel (relevan jika tabel yang sama kemudian dibuat ulang dengan data baru yang ditambahkan)
    • Memotong tabel
  • Datastream tidak mendukung replikasi tampilan.
  • Datastream tidak mendukung kolom jenis data spasial, misalnya, GEOMETRY, POINT, LINESTRING, POLYGON. Nilai dalam kolom ini diganti dengan nilai NULL.
  • Datastream tidak mendukung nilai nol (0000-00-00 00:00:00) di kolom jenis data DATETIME, DATE, atau TIMESTAMP. Nilai nol diganti dengan nilai NULL.
  • Datastream tidak mendukung replikasi baris yang menyertakan nilai berikut dalam kolom JSON: DECIMAL, NEWDECIMAL, TIME, TIME2 DATETIME, DATETIME2, DATE, TIMESTAMP, atau TIMESTAMP2. Peristiwa yang berisi nilai tersebut akan dihapus.
  • Datastream tidak mendukung kompresi transaksi log biner.
  • Datastream tidak mendukung file log biner yang lebih besar dari 4 GiB. Karena MySQL menulis setiap transaksi ke satu file log biner, pastikan transaksi individual tidak melebihi 4 GiB agar file log biner tidak melebihi batas ini.
  • Datastream tidak mendukung rantai sertifikat SSL di profil koneksi MySQL sumber. Hanya satu sertifikat berenkode x509 PEM yang didukung.
  • Datastream tidak mendukung operasi bertingkat: ON UPDATE CASCADE dan ON DELETE CASCADE. Peristiwa tersebut tidak ditulis ke log biner, dan akibatnya, tidak disebarkan ke tujuan. Sebagai solusinya, Anda dapat mengganti operasi bertingkat dengan pemicu database.
  • Datastream tidak mendukung operasi DROP PARTITION. Operasi tersebut adalah operasi khusus metadata dan tidak direplikasi. Peristiwa lain tidak terpengaruh dan streaming berjalan dengan baik.
  • Anda mungkin mengalami masalah konektivitas saat mereplikasi tabel FEDERATED. Jika hal itu terjadi, hapus semua tabel FEDERATED dari konfigurasi database sumber dan tingkatkan nilai untuk parameter connect_timeout, net_read_timeout, dan max_allowed_packet guna mengurangi masalah waktu tunggu selama pengisian ulang.
  • Instance Cloud SQL Enterprise Plus harus menggunakan replikasi berbasis GTID karena tunduk pada pemeliharaan dengan periode nonaktif mendekati nol. Replikasi berbasis log biner akan berhenti saat failover, sehingga sebaiknya gunakan replikasi berbasis GTID untuk kasus penggunaan ketersediaan tinggi.
  • Untuk MySQL versi 8.0 dan yang lebih baru, variabel binlog_row_value_options harus ditetapkan ke nilai kosong. Ini adalah setelan default untuk sebagian besar versi, tetapi untuk beberapa versi, misalnya sumber MySQL di Oracle Cloud Infrastructure (OCI), Anda harus menetapkannya secara eksplisit. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi database MySQL yang dikelola sendiri.
  • Batasan MariaDB:
    • Replikasi berbasis GTID tidak didukung untuk MariaDB. Anda harus mengonfigurasi aliran data MariaDB untuk menggunakan replikasi berbasis binlog.
    • Untuk MariaDB versi 11.4 hingga 12.2, Anda harus mengaktifkan variabel sistem binlog_legacy_event_pos di database sumber untuk memastikan kompatibilitas dengan Datastream.
    • Datastream tidak mendukung jenis data UUID (diperkenalkan di MariaDB 10.7). Anda harus mengecualikan kolom jenis data UUID dari konfigurasi aliran data.

Batasan tambahan untuk replikasi berbasis GTID

  • Pemulihan aliran data yang menggunakan replikasi berbasis GTID hanya tersedia saat menggunakan Datastream API.
  • Membuat tabel dari tabel lain menggunakan pernyataan CREATE TABLE ... SELECT tidak didukung.
  • Datastream tidak mendukung GTID yang diberi tag.
  • Untuk batasan MySQL yang berlaku pada replikasi berbasis GTID, lihat dokumentasi MySQL.

Langkah berikutnya