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 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 dilakukan di sumber MySQL. ID ini unik tidak hanya untuk sumber tempat ID tersebut berasal, tetapi juga di semua server dalam topologi replikasi tertentu, berbeda dengan replikasi berbasis log biner di mana setiap node dalam cluster database mempertahankan file binlog-nya sendiri, dengan penomorannya sendiri. Mempertahankan file binlog dan penomoran yang terpisah 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 di-commit 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 untuk aliran Anda. Nilai untuk Keaktualan data dan Throughput harus 0.
  7. Mulai aliran 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 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 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.

Menyesuaikan 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 sibuk. 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 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 menurun.
    4. Semua kolom indeks disertakan dalam aliran.
  • 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 hilir:
    • Melepas kolom
    • Menambahkan kolom ke tengah tabel
    • Mengubah jenis data kolom
    • Mengurutkan ulang kolom
    • Menghapus tabel (relevan jika tabel yang sama kemudian dibuat ulang dengan data baru yang ditambahkan)
    • Memangkas tabel
  • Datastream tidak mendukung replikasi tampilan.
  • Datastream tidak mendukung kolom jenis data spasial. 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 di kolom JSON: DECIMAL, NEWDECIMAL, TIME, TIME2 DATETIME, DATETIME2, DATE, TIMESTAMP, atau TIMESTAMP2. Peristiwa yang berisi nilai tersebut akan dibuang.
  • Datastream tidak mendukung kompresi transaksi log biner.
  • Datastream tidak mendukung rangkaian sertifikat SSL di profil koneksi MySQL sumber. Hanya sertifikat tunggal berenkode PEM x509 yang didukung.
  • Datastream tidak mendukung penghapusan bertingkat. Peristiwa tersebut tidak ditulis ke log biner, dan akibatnya, tidak disebarkan ke tujuan.
  • Datastream tidak mendukung operasi DROP PARTITION. Operasi tersebut adalah operasi khusus metadata dan tidak direplikasi. Acara lain tidak terpengaruh dan streaming berjalan dengan lancar.
  • 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 untuk mengurangi masalah waktu tunggu selama pengisian ulang.
  • Instance Cloud SQL Enterprise Plus harus menggunakan replikasi berbasis GTID karena tunduk pada pemeliharaan dengan periode nonaktif nyaris nol. Replikasi berbasis log biner akan terganggu saat failover, oleh karena itu 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 menyetelnya secara eksplisit. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi database MySQL yang dikelola sendiri.

Batasan tambahan untuk replikasi berbasis GTID

  • Memulihkan aliran 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 mengetahui batasan MySQL yang berlaku untuk replikasi berbasis GTID, lihat dokumentasi MySQL.

Langkah berikutnya