Praktik terbaik umum saat menggunakan Datastream

Untuk mempertahankan replikasi yang andal dan meminimalkan waktu nonaktif di Datastream, Anda dapat menerapkan praktik terbaik operasional di seluruh aliran dan database sumber. Praktik ini membantu Anda mengganti database sumber aliran, mengonfigurasi pemberitahuan metrik, memecahkan masalah latensi, dan merencanakan batas tabel per aliran.

Mengubah database sumber aliran

Dalam beberapa kasus, Anda mungkin harus mengubah database sumber aliran. Misalnya, Anda mungkin harus mengubah aliran untuk mereplikasi dari replika, bukan dari instance database utama.

  1. Buat profil koneksi untuk instance replika.
  2. Buat aliran data menggunakan profil koneksi untuk replika yang Anda buat dan profil koneksi yang ada untuk tujuan.
  3. Mulai aliran data dengan pengisian ulang historis dinonaktifkan. Saat dimulai, aliran data hanya akan mengambil data dari log biner.
  4. Opsional. Setelah aliran data berjalan, ubah untuk mengaktifkan pengisian ulang otomatis.
  5. Jeda aliran data yang membaca dari instance utama.
  6. Opsional. Hapus aliran data yang melakukan streaming data dari instance utama.
  7. Opsional. Hapus profil koneksi untuk instance utama.

Pemberitahuan dan pemantauan di Datastream

Dasbor Datastream berisi banyak informasi. Informasi ini dapat membantu untuk tujuan proses debug. Informasi tambahan dapat ditemukan di log, yang tersedia di Cloud Logging.

Pemberitahuan Datastream

Tidak ada pemberitahuan default yang disiapkan untuk Datastream. Misalnya, Anda dapat membuat kebijakan pemberitahuan untuk metrik keaktualan data dengan mengklik link Create alerting policy di tab Overview. Untuk metrik yang tersisa, ikuti langkah-langkah berikut:

  1. Di Google Cloud konsol, buka halaman  Alerting:

    Buka Alerting

  2. Klik Create policy.

  3. Klik menu drop-down Select a metric.

  4. Di kolom filter, masukkan Datastream.

  5. Opsional: Anda mungkin perlu menonaktifkan filter Active untuk melihat semua metrik yang tersedia.

  6. Cari metrik yang ingin Anda pantau di bagian Datastream Stream.

  7. Klik Apply.

  8. Opsional: Masukkan detail yang diperlukan di bagian Add filters dan Transform data. Klik Next.

  9. Masukkan informasi yang diperlukan di bagian Configure alert trigger. Klik Next.

  10. Konfigurasi notifikasi Anda di bagian Configure notifications and finalize alert.

  11. Tinjau pemberitahuan Anda, lalu klik Create policy jika sudah siap.

    Untuk mengetahui informasi mendetail tentang cara menyelesaikan setiap langkah ini, lihat Membuat kebijakan pemberitahuan.

Sebaiknya buat pemberitahuan untuk metrik Datastream berikut:

  • Data freshness
  • Stream unsupported event count
  • Stream total latencies

Pemberitahuan pada salah satu metrik ini dapat menunjukkan masalah pada aliran data atau database sumber.

Memahami latensi

Datastream menyediakan metrik berikut untuk membantu Anda memahami latensi replikasi:

  • Keaktualan data: perbedaan antara waktu saat data di-commit ke sumber dan waktu saat data dibaca oleh Datastream. Jika metrik ini tinggi, artinya Datastream membaca data lebih lambat daripada data yang dibuat di sumber. Hal ini menunjukkan bahwa mungkin ada masalah dengan sumber atau dengan koneksi jaringan ke sumber.
  • System latency: waktu yang diperlukan Datastream untuk memproses peristiwa, mulai dari saat peristiwa dibaca dari sumber hingga ditulis ke tujuan.
  • Total latency: latensi replikasi end-to-end, yang menunjukkan total waktu dari saat data di-commit ke sumber hingga ditulis ke tujuan.

Jika keaktualan data tinggi, penyebab umumnya meliputi:

  • Source overload: database sumber menghasilkan log (file binlog, file log redo, file WAL) lebih cepat daripada yang dapat dibaca oleh Datastream.
    • Tindakan untuk MySQL/Oracle: Tingkatkan parameter maxConcurrentCdcTasks untuk membaca lebih banyak log secara paralel.
    • Tindakan untuk PostgreSQL: pisahkan tabel dengan churn tinggi ke dalam aliran khusus mereka sendiri.
    • Tindakan untuk SQL Server: tingkatkan parameter maxConcurrentCdcTasks untuk membaca lebih banyak tabel perubahan secara paralel.
  • Source resource starvation: server database sumber itu sendiri mengalami masalah seperti penggunaan CPU yang tinggi, memori rendah, atau bottleneck I/O disk.
    • Tindakan: pastikan instance sumber responsif. Periksa penggunaan CPU/RAM. Untuk PostgreSQL, pertimbangkan untuk meningkatkan nilai parameter logical_decoding_work_mem; untuk Oracle, pastikan area global sistem (SGA) yang dialokasikan sudah cukup.
  • Masalah kapasitas jaringan: waktu ping yang tinggi atau bandwidth yang jenuh antara sumber dan Google Cloud.
    • Tindakan: pantau bandwidth dan latensi VPN atau Cloud Interconnect Anda.
  • Single large transaction: tugas batch besar, seperti UPDATE pada jutaan baris, dapat menyebabkan lonjakan latensi sementara.
    • Tindakan: hal ini diharapkan. Tunggu Datastream memproses peristiwa besar. Pertimbangkan untuk membagi tugas batch besar menjadi bagian yang lebih kecil di masa mendatang.

Jika latensi sistem tinggi, hal ini mungkin menunjukkan masalah dalam Datastream atau tujuan.

  • Tindakan: periksa Cloud Logging untuk mengetahui error tingkat baris yang persisten (misalnya, invalid input for type json. Jika aliran data berada dalam loop percobaan ulang karena error jenis data atau batasan, hal ini mungkin memerlukan koreksi data manual di sumber. Jika tidak ada error yang jelas, hubungi Dukungan Google untuk mendapatkan bantuan.

Berapa banyak tabel yang dapat ditangani oleh satu aliran data?

Sebaiknya satu aliran data menyertakan hingga 10.000 tabel. Tidak ada batasan ukuran tabel. Jika Anda perlu membuat aliran data dengan lebih banyak tabel, aliran data tersebut mungkin akan memasuki status error. Untuk menghindarinya, pertimbangkan untuk membagi sumber menjadi beberapa aliran data.