Streaming data dari database MySQL

Bagian ini berisi informasi tentang:

  • Perilaku cara Datastream menangani data yang ditarik dari database MySQL sumber
  • Versi database MySQL yang didukung Datastream
  • Batasan yang diketahui untuk menggunakan database MySQL sebagai sumber
  • Ringkasan cara menyiapkan database MySQL sumber agar data dapat di-streaming dari database tersebut ke tujuan

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 aliran data.

Replikasi berbasis binlog

Datastream dapat menggunakan file log biner untuk mencatat perubahan data dalam database MySQL. Informasi yang ada dalam file log ini kemudian direplikasi ke tujuan untuk mereproduksi perubahan yang dilakukan 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, direplikasi.
  • Hanya perubahan yang dilakukan 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 dilakukan di sumber MySQL. ID ini tidak hanya unik untuk sumber tempat ID tersebut berasal, tetapi juga di semua server dalam topologi replikasi tertentu, berbeda dengan replikasi berbasis log biner yang setiap node dalam cluster database mempertahankan file binlog-nya sendiri, dengan penomorannya sendiri. Mempertahankan file binlog terpisah dan penomoran dapat menjadi masalah jika terjadi kegagalan atau periode nonaktif yang direncanakan, karena kelangsungan binlog terganggu 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, direplikasi.
  • Hanya perubahan yang dilakukan yang direplikasi.
  • Dukungan failover yang lancar.

Beralih dari replikasi berbasis binlog ke replikasi berbasis GTID

Jika Anda ingin memperbarui aliran dan beralih dari replikasi berbasis binlog ke 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 aliran berbasis GTID pengujian. Untuk mengetahui informasi selengkapnya, lihat Membuat streaming.
  3. Buat aliran berbasis GTID. Jangan mulai dulu.
  4. Hentikan traffic aplikasi ke database sumber.
  5. Jeda aliran berbasis binlog yang ada. Untuk mengetahui informasi selengkapnya, lihat Menjeda streaming.
  6. Tunggu beberapa menit untuk memastikan Datastream telah menyusul database. Anda dapat memeriksanya menggunakan metrik di tab Monitoring, di halaman Detail aliran data untuk aliran data Anda. Nilai untuk Keaktualan data dan Throughput harus 0.
  7. Mulai streaming berbasis GTID. Untuk mengetahui informasi selengkapnya, lihat Mulai streaming.
  8. Lanjutkan traffic ke database sumber.

Jika pengisian ulang tidak menjadi masalah, Anda dapat memangkas tabel di BigQuery, menghapus aliran lama, dan memulai aliran baru dengan pengisian ulang. Untuk mengetahui informasi selengkapnya tentang 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 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 itu, Datastream akan kehilangan posisinya dan tidak dapat dilanjutkan.

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

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

Menentukan ukuran replika baca dengan benar

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

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

Meningkatkan throughput untuk metode CDC binlog

Jika Anda menggunakan replikasi berbasis binlog dan mengalami latensi tinggi karena volume tulis 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 secara paralel. Meningkatkan nilai untuk parameter ini memungkinkan Datastream memproses lebih banyak file binlog secara bersamaan.

Rekomendasi: Untuk menentukan nilai yang sesuai untuk keaktualan data, pantau kecepatan 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 memungkinkan Datastream memproses file ini secara paralel, sehingga mencegah penumpukan.

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 streaming 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 yang diketahui untuk menggunakan database MySQL sebagai sumber meliputi:

  • Aliran data dibatasi hingga 10.000 tabel.
  • Tabel yang direplikasi harus menggunakan mesin penyimpanan InnoDB. Tabel yang menggunakan mesin penyimpanan MyISAM tidak didukung dan gagal validasi streaming.
  • 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 dapat bernilai null.
    3. Indeks tidak