Topik ini menjelaskan cara menggunakan konektor MySQL dalam pekerjaan SQL.
Informasi latar belakang
Konektor MySQL mendukung semua database yang kompatibel dengan protokol MySQL, seperti ApsaraDB RDS for MySQL, PolarDB for MySQL, OceanBase (mode MySQL), dan self-managed MySQL.
Saat menggunakan konektor MySQL untuk membaca data dari OceanBase, pastikan binary logging (binlog) diaktifkan dan dikonfigurasi dengan benar. Untuk informasi lebih lanjut, lihat Operasi terkait Binlog. Fitur ini berada dalam pratinjau publik. Gunakan fitur ini dengan hati-hati.
Konektor MySQL mendukung hal-hal berikut.
|
Kategori |
Detail |
|
Jenis yang didukung |
Tabel sumber, tabel dimensi, tabel sink, dan sumber data ingestion data |
|
Mode runtime |
Hanya mode streaming yang didukung. |
|
Format data |
Tidak berlaku |
|
Metrik pemantauan spesifik |
|
|
Jenis API |
DataStream, SQL, dan YAML ingestion data |
|
Mendukung pembaruan atau penghapusan data di tabel sink |
Ya |
Fitur
Tabel sumber change data capture (CDC) MySQL, juga dikenal sebagai tabel sumber streaming MySQL, pertama-tama membaca seluruh data historis dari database, lalu secara mulus beralih ke pembacaan log biner. Proses ini memastikan tidak ada data yang terlewat atau diduplikasi. Bahkan jika terjadi kegagalan, data diproses dengan semantik tepat-sekali. Tabel sumber CDC MySQL mendukung pembacaan konkuren data penuh dan menggunakan algoritma snapshot inkremental untuk mengimplementasikan pembacaan tanpa kunci serta transfer data yang dapat dilanjutkan. Untuk informasi lebih lanjut, lihat Tentang tabel sumber CDC MySQL.
-
Pemrosesan batch dan stream terpadu yang mendukung pembacaan data penuh dan inkremental, sehingga menghilangkan kebutuhan untuk memelihara dua proses terpisah.
-
Pembacaan konkuren data penuh untuk penskalaan kinerja horizontal.
-
Peralihan mulus dari pembacaan data penuh ke pembacaan data inkremental dan skala-masuk otomatis untuk menghemat sumber daya komputasi.
-
Transfer data yang dapat dilanjutkan selama fase pembacaan data penuh guna meningkatkan stabilitas.
-
Pembacaan data penuh tanpa kunci, yang tidak memengaruhi layanan online.
-
Dukungan untuk membaca log cadangan ApsaraDB RDS for MySQL.
-
Parsing paralel file log biner untuk latensi baca yang lebih rendah.
Prasyarat
Sebelum menggunakan tabel sumber CDC MySQL, Anda harus menyelesaikan operasi prasyarat yang dijelaskan dalam Konfigurasi MySQL.
ApsaraDB RDS for MySQL
-
Lakukan network probe untuk memastikan konektivitas jaringan ke Realtime Compute for Apache Flink.
-
Versi MySQL: 5.6, 5.7, 8.0.x, atau 8.4.
-
Binary logging harus diaktifkan. Fitur ini diaktifkan secara default.
-
Format log biner harus ROW. Ini adalah format default.
-
Parameter `binlog_row_image` harus diatur ke FULL. Ini adalah pengaturan default.
-
Binary Log Transaction Compression harus dinonaktifkan. Fitur ini diperkenalkan di MySQL 8.0.20 dan dinonaktifkan secara default.
-
Pengguna MySQL telah dibuat dengan izin SELECT, SHOW DATABASES, REPLICATION SLAVE, dan REPLICATION CLIENT.
-
Buat database dan tabel MySQL. Untuk informasi lebih lanjut, lihat Buat database dan akun untuk instans ApsaraDB RDS for MySQL. Gunakan akun istimewa untuk membuat database MySQL guna mencegah kegagalan operasi akibat izin yang tidak mencukupi.
-
Konfigurasikan daftar putih alamat IP. Untuk informasi lebih lanjut, lihat Konfigurasi daftar putih alamat IP untuk instans ApsaraDB RDS for MySQL.
PolarDB for MySQL
-
Lakukan network probe untuk memastikan konektivitas jaringan ke Realtime Compute for Apache Flink.
-
Versi MySQL: 5.6, 5.7, 8.0.x, atau 8.4.
-
Binary logging harus diaktifkan. Fitur ini dinonaktifkan secara default.
-
Format log biner harus ROW. Ini adalah format default.
-
Parameter `binlog_row_image` harus diatur ke FULL. Ini adalah pengaturan default.
-
Binary Log Transaction Compression harus dinonaktifkan. Fitur ini diperkenalkan di MySQL 8.0.20 dan dinonaktifkan secara default.
-
Anda telah membuat pengguna MySQL dengan izin SELECT, SHOW DATABASES, REPLICATION SLAVE, dan REPLICATION CLIENT.
-
Buat database dan tabel MySQL. Untuk informasi lebih lanjut, lihat Buat database dan akun untuk kluster PolarDB for MySQL. Gunakan akun istimewa untuk membuat database MySQL guna mencegah kegagalan operasi akibat izin yang tidak mencukupi.
-
Konfigurasikan daftar putih alamat IP. Untuk informasi lebih lanjut, lihat Konfigurasi daftar putih alamat IP untuk kluster PolarDB for MySQL.
Self-managed MySQL
-
Lakukan network probe untuk memastikan konektivitas jaringan ke Realtime Compute for Apache Flink.
-
Versi MySQL: 5.6, 5.7, 8.0.x, atau 8.4.
-
Binary logging harus diaktifkan. Fitur ini dinonaktifkan secara default.
-
Format log biner harus ROW. Format default adalah STATEMENT.
-
Parameter `binlog_row_image` harus diatur ke FULL. Ini adalah pengaturan default.
-
Binary Log Transaction Compression harus dinonaktifkan. Fitur ini diperkenalkan di MySQL 8.0.20 dan dinonaktifkan secara default.
-
Buat pengguna MySQL dan berikan izin SELECT, SHOW DATABASES, REPLICATION SLAVE, dan REPLICATION CLIENT.
-
Buat database dan tabel MySQL. Untuk informasi lebih lanjut, lihat Buat database dan akun untuk instans self-managed MySQL. Gunakan akun istimewa untuk membuat database MySQL guna mencegah kegagalan operasi akibat izin yang tidak mencukupi.
-
Konfigurasikan daftar putih alamat IP. Untuk informasi lebih lanjut, lihat Konfigurasi daftar putih alamat IP untuk instans self-managed MySQL.
Batasan
Batasan umum
-
Tabel sumber CDC MySQL tidak mendukung definisi watermark.
-
Konektor CDC MySQL tidak mendukung fitur Binary Log Transaction Compression. Oleh karena itu, saat menggunakan konektor CDC MySQL untuk mengonsumsi data inkremental, pastikan Binary Log Transaction Compression dinonaktifkan. Jika tidak, konektor mungkin gagal mengambil data inkremental.
ApsaraDB RDS for MySQL batasan
-
Untuk ApsaraDB RDS for MySQL, jangan membaca data dari database sekunder atau replika read-only. Hal ini karena periode retensi log biner default untuk database sekunder dan replika read-only pendek. Jika log biner kedaluwarsa dan dihapus, pekerjaan mungkin gagal mengonsumsi data log biner dan melaporkan error.
-
ApsaraDB RDS for MySQL mengaktifkan sinkronisasi primer/sekunder paralel secara default tetapi tidak menjamin urutan transaksi yang konsisten antara instans primer dan sekunder. Hal ini dapat menyebabkan data terlewat selama alih bencana primer/sekunder dan pemulihan checkpoint. Untuk menghindari masalah ini, Anda dapat mengaktifkan opsi `slave_preserve_commit_order` secara manual untuk ApsaraDB RDS for MySQL.
PolarDB for MySQL batasan
Tabel sumber CDC MySQL tidak mendukung pembacaan data dari kluster Arsitektur Kluster Multi-master PolarDB for MySQL V1.0.19 dan sebelumnya. Untuk informasi lebih lanjut, lihat Apa itu Kluster Multi-master?. Log biner yang dihasilkan oleh kluster ini mungkin berisi ID tabel duplikat. Hal ini dapat menyebabkan kesalahan pemetaan skema pada tabel sumber CDC, yang mengakibatkan kesalahan saat mengurai data log biner.
Open source MySQL batasan
Secara default, MySQL mempertahankan urutan transaksi selama replikasi log biner primer/sekunder. Jika replika MySQL memiliki replikasi paralel diaktifkan (slave_parallel_workers > 1) tetapi tidak memiliki slave_preserve_commit_order=ON diaktifkan, urutan commit transaksinya mungkin tidak konsisten dengan database primer. Saat Flink CDC pulih dari checkpoint, data mungkin terlewat karena urutan yang tidak sesuai. Anda dapat mengatur `slave_preserve_commit_order` = ON pada replika MySQL. Atau, Anda dapat mengatur `slave_parallel_workers` = 1, tetapi hal ini akan mengorbankan kinerja replikasi.
Catatan penggunaan
-
Tabel sumber
-
Selama fase pembacaan data penuh, Anda tidak dapat menyimpan titik simpan, menambahkan atau menghapus tabel dari tabel sumber, lalu me-restart pekerjaan dari titik simpan tersebut. Jika Anda melakukan operasi ini, pekerjaan akan gagal membaca data.
-
-
Tabel sink
-
Primary key auto-increment: Jangan deklarasikan primary key auto-increment dalam DDL. MySQL secara otomatis mengisinya saat menulis data.
-
Anda harus mendeklarasikan setidaknya satu bidang non-primary key. Jika tidak, error akan dilaporkan.
-
Kendala `NOT ENFORCED` dalam DDL menunjukkan bahwa Flink tidak memvalidasi primary key. Anda bertanggung jawab untuk memastikan kebenaran dan integritas primary key. Untuk informasi lebih lanjut, lihat Pemeriksaan Validitas.
-
-
Tabel dimensi
Jika Anda ingin menggunakan indeks untuk mempercepat kueri, urutan bidang dalam klausa JOIN harus sesuai dengan urutan yang ditentukan dalam indeks, sesuai aturan prefiks paling kiri. Misalnya, jika indeksnya adalah (a, b, c), kondisi JOIN-nya adalah
ON t.a = x AND t.b = y.SQL yang dihasilkan oleh Flink mungkin ditulis ulang oleh pengoptimal. Hal ini dapat mencegah indeks terkena selama kueri database aktual. Untuk memastikan apakah indeks digunakan, periksa rencana eksekusi (EXPLAIN) atau log kueri lambat di MySQL untuk melihat pernyataan SELECT aktual yang dieksekusi.
SQL
Anda dapat menggunakan konektor MySQL dalam pekerjaan SQL sebagai tabel sumber, tabel dimensi, atau tabel sink.
Sintaks
CREATE TEMPORARY TABLE mysqlcdc_source (
order_id INT,
order_date TIMESTAMP(0),
customer_name STRING,
price DECIMAL(10, 5),
product_id INT,
order_status BOOLEAN,
PRIMARY KEY(order_id) NOT ENFORCED
) WITH (
'connector' = 'mysql',
'hostname' = '<yourHostname>',
'port' = '3306',
'username' = '<yourUsername>',
'password' = '<yourPassword>',
'database-name' = '<yourDatabaseName>',
'table-name' = '<yourTableName>'
);
-
Saat menulis ke tabel sink, konektor membuat dan mengeksekusi pernyataan SQL untuk setiap catatan data yang diterima. Pernyataan tersebut disusun sebagai berikut:
-
Untuk tabel sink tanpa primary key, pernyataan
INSERT INTO table_name (column1, column2, ...) VALUES (value1, value2, ...);dieksekusi. -
Untuk tabel sink dengan primary key, pernyataan
INSERT INTO table_name (column1, column2, ...) VALUES (value1, value2, ...) ON DUPLICATE KEY UPDATE column1 = VALUES(column1), column2 = VALUES(column2), ...;dieksekusi. Catatan: Jika tabel fisik memiliki kendala indeks unik selain primary key, memasukkan dua catatan dengan primary key berbeda tetapi nilai indeks unik yang sama menyebabkan konflik indeks unik. Hal ini mengakibatkan data ditimpa dan hilang.
-
-
Jika primary key auto-increment didefinisikan dalam database MySQL, jangan deklarasikan kolom auto-increment dalam DDL Flink. Database secara otomatis mengisi bidang ini saat menulis data. Konektor mendukung penulisan dan penghapusan data dengan kolom auto-increment, tetapi tidak mendukung pembaruan data ini.
Parameter WITH
-
Umum
Parameter
Deskripsi
Wajib
Tipe data
Nilai default
Catatan
connector
Jenis tabel.
Ya
STRING
Tidak ada
Saat digunakan sebagai tabel sumber, Anda dapat mengatur parameter ini ke
mysql-cdcataumysql. Keduanya setara. Saat digunakan sebagai tabel dimensi atau tabel sink, nilainya harusmysql.hostname
Alamat IP atau hostname database MySQL.
Ya
STRING
Tidak ada
Kami menyarankan agar Anda menentukan alamat virtual private cloud (VPC).
CatatanJika database MySQL dan Realtime Compute for Apache Flink tidak berada dalam VPC yang sama, Anda harus membuat koneksi jaringan cross-VPC atau menggunakan titik akhir publik untuk mengakses database. Untuk informasi lebih lanjut, lihat Kelola dan operasikan ruang kerja dan Bagaimana kluster Flink yang sepenuhnya dikelola mengakses Internet?.
username
Username untuk layanan database MySQL.
Ya
STRING
Tidak ada
Tidak ada.
password
Password untuk layanan database MySQL.
Ya
STRING
Tidak ada
Tidak ada.
database-name
Nama database MySQL.
Ya
STRING
Tidak ada
-
Saat database digunakan sebagai tabel sumber, Anda dapat menggunakan ekspresi reguler untuk nama database guna membaca data dari beberapa database.
-
Saat menggunakan ekspresi reguler, jangan gunakan simbol ^ dan $ untuk mencocokkan awal dan akhir string. Untuk informasi lebih lanjut, lihat catatan untuk parameter table-name.
table-name
Nama tabel MySQL.
Ya
STRING
Tidak ada
-
Anda dapat menggunakan ekspresi reguler untuk nama tabel sumber guna membaca data dari beberapa tabel.
-
Saat menggunakan ekspresi reguler, jangan gunakan simbol ^ dan $ untuk mencocokkan awal dan akhir string. Untuk informasi lebih lanjut, lihat catatan berikut.
CatatanSaat tabel sumber CDC MySQL mencocokkan nama tabel menggunakan ekspresi reguler, konektor menggabungkan database-name dan table-name yang Anda tentukan dengan string \\. untuk membentuk ekspresi reguler jalur lengkap. Sebelum VVR 8.0.1, karakter . digunakan. Konektor kemudian menggunakan ekspresi reguler ini untuk mencocokkan nama tabel yang memenuhi syarat penuh di database MySQL.
Misalnya, jika Anda mengatur 'database-name'='db_.*' dan 'table-name'='tb_.+', konektor menggunakan ekspresi reguler db_.*\\.tb_.+ untuk mencocokkan nama tabel yang memenuhi syarat penuh guna menentukan tabel mana yang akan dibaca. Sebelum VVR 8.0.1, ekspresi regulernya adalah db_.*.tb_.+.
port
Nomor port layanan database MySQL.
Tidak
INTEGER
3306
Tidak ada.
-
-
Hanya untuk tabel sumber
Parameter
Deskripsi
Wajib
Tipe data
Nilai default
Catatan
server-id
ID numerik untuk klien database.
Tidak
STRING
Nilai acak antara 5400 dan 6400 dihasilkan.
ID ini harus unik secara global dalam kluster MySQL. Tetapkan ID berbeda untuk setiap pekerjaan yang terhubung ke database yang sama.
Parameter ini juga mendukung format rentang ID, seperti 5400-5408. Saat pembacaan inkremental diaktifkan, pembacaan konkuren didukung. Dalam kasus ini, tetapkan rentang ID sehingga setiap pembaca konkuren menggunakan ID berbeda. Untuk informasi lebih lanjut, lihat Gunakan Server ID.
scan.incremental.snapshot.enabled
Menentukan apakah akan mengaktifkan snapshot inkremental.
Tidak
BOOLEAN
true
Snapshot inkremental diaktifkan secara default. Snapshot inkremental adalah mekanisme baru untuk membaca snapshot data penuh. Dibandingkan dengan metode pembacaan snapshot lama, snapshot inkremental memiliki banyak keunggulan, termasuk:
-
Sumber dapat membaca data penuh secara paralel.
-
Sumber mendukung checkpoint tingkat chunk saat membaca data penuh.
-
Sumber tidak perlu mengambil kunci baca global (FLUSH TABLES WITH read lock) saat membaca data penuh.
Jika Anda ingin sumber mendukung pembacaan konkuren, setiap pembaca konkuren memerlukan server ID unik. Oleh karena itu, server-id harus berupa rentang, seperti 5400-6400, dan ukuran rentang harus lebih besar dari atau sama dengan konkurensi.
CatatanItem konfigurasi ini dihapus di Ververica Runtime (VVR) 11.1 dan versi yang lebih baru.
scan.incremental.snapshot.chunk.size
Ukuran setiap chunk dalam jumlah baris.
Tidak
INTEGER
8096
Saat pembacaan snapshot inkremental diaktifkan, tabel dibagi menjadi beberapa chunk untuk dibaca. Data chunk di-cache dalam memori sebelum sepenuhnya dibaca.
Semakin sedikit baris yang dikandung setiap chunk, semakin besar jumlah total chunk dalam tabel. Meskipun hal ini mengurangi granularitas pemulihan kesalahan, hal ini dapat menyebabkan error kehabisan memori (OOM) dan throughput keseluruhan yang lebih rendah. Oleh karena itu, Anda perlu membuat pertimbangan dan menetapkan ukuran chunk yang wajar.
scan.snapshot.fetch.size
Jumlah maksimum catatan yang ditarik sekaligus saat membaca data penuh tabel.
Tidak
INTEGER
1024
Tidak ada.
scan.startup.mode
Mode startup untuk konsumsi data.
Tidak
STRING
initial
Nilai yang valid:
-
initial (default): Saat startup pertama atau startup tanpa status, konektor memindai data historis penuh lalu membaca data log biner terbaru.
-
latest-offset: Saat startup pertama atau startup tanpa status, konektor tidak memindai data historis. Konektor mulai membaca dari akhir log biner, artinya hanya membaca perubahan terbaru setelah konektor dimulai.
-
earliest-offset: Konektor tidak memindai data historis. Konektor mulai membaca dari log biner yang tersedia paling awal.
-
specific-offset: Konektor tidak memindai data historis. Konektor mulai dari offset log biner tertentu. Anda dapat menentukan offset dengan mengonfigurasi scan.startup.specific-offset.file dan scan.startup.specific-offset.pos, atau hanya mengonfigurasi scan.startup.specific-offset.gtid-set untuk memulai dari set GTID tertentu.
-
timestamp: Konektor tidak memindai data historis. Konektor mulai membaca log biner dari timestamp tertentu. Timestamp ditentukan oleh scan.startup.timestamp-millis dalam milidetik.
PentingSaat menggunakan mode startup earliest-offset, specific-offset, atau timestamp, pastikan skema tabel yang sesuai tidak berubah antara posisi konsumsi log biner yang ditentukan dan waktu startup pekerjaan. Hal ini mencegah error yang disebabkan oleh ketidakcocokan skema.
scan.startup.specific-offset.file
Nama file log biner untuk offset awal saat menggunakan mode startup specific-offset.
Tidak
STRING
Tidak ada
Saat menggunakan parameter ini, Anda harus mengatur scan.startup.mode ke specific-offset. Contoh format nama file:
mysql-bin.000003.scan.startup.specific-offset.pos
Offset dalam file log biner yang ditentukan untuk offset awal saat menggunakan mode startup specific-offset.
Tidak
INTEGER
Tidak ada
Saat menggunakan parameter ini, Anda harus mengatur scan.startup.mode ke specific-offset.
scan.startup.specific-offset.gtid-set
Set GTID untuk offset awal saat menggunakan mode startup specific-offset.
Tidak
STRING
Tidak ada
Saat menggunakan parameter ini, Anda harus mengatur scan.startup.mode ke specific-offset. Contoh format set GTID:
24DA167-0C0C-11E8-8442-00059A3C7B00:1-19.scan.startup.timestamp-millis
Timestamp dalam milidetik untuk offset awal saat menggunakan mode startup timestamp.
Tidak
LONG
Tidak ada
Saat menggunakan parameter ini, Anda harus mengatur scan.startup.mode ke timestamp. Satuan timestamp adalah milidetik.
PentingSaat Anda menentukan waktu, CDC MySQL mencoba membaca event awal setiap file log biner untuk menentukan timestamp-nya. Kemudian, CDC MySQL menemukan file log biner yang sesuai dengan waktu yang ditentukan. Pastikan file log biner yang sesuai dengan timestamp yang ditentukan belum dihapus dari database dan dapat dibaca.
server-time-zone
Zona waktu sesi yang digunakan oleh database.
Tidak
STRING
Jika Anda tidak menentukan parameter ini, sistem menggunakan zona waktu lingkungan runtime pekerjaan Flink sebagai zona waktu server database. Ini adalah zona waktu zona yang Anda pilih.
Contoh: Asia/Shanghai. Parameter ini mengontrol bagaimana tipe TIMESTAMP di MySQL dikonversi ke tipe STRING. Untuk informasi lebih lanjut, lihat Debezium temporal values.
debezium.min.row.count.to.stream.results
Saat jumlah baris dalam tabel lebih besar dari nilai ini, mode pembacaan batch digunakan.
Tidak
INTEGER
1000
Flink membaca data dari tabel sumber MySQL dengan salah satu cara berikut:
-
Pembacaan penuh: Membaca seluruh data tabel langsung ke memori. Metode ini cepat tetapi mengonsumsi memori yang sesuai. Jika tabel sumber sangat besar, ada risiko error OOM.
-
Pembacaan batch: Membaca data dalam beberapa batch, dengan jumlah baris tertentu per batch, hingga semua data dibaca. Metode ini menghindari risiko OOM saat membaca tabel besar tetapi relatif lambat.
connect.timeout
Waktu maksimum menunggu koneksi ke server database MySQL hingga timeout sebelum mencoba lagi.
Tidak
DURATION
30s
Tidak ada.
connect.max-retries
Jumlah maksimum percobaan ulang setelah koneksi ke layanan database MySQL gagal.
Tidak
INTEGER
3
Tidak ada.
connection.pool.size
Ukuran kolam koneksi database.
Tidak
INTEGER
20
Kolam koneksi database digunakan untuk menggunakan kembali koneksi, yang dapat mengurangi jumlah koneksi database.
jdbc.properties.*
Parameter koneksi kustom dalam URL JDBC.
Tidak
STRING
Tidak ada
Anda dapat meneruskan parameter koneksi kustom. Misalnya, untuk tidak menggunakan protokol SSL, Anda dapat mengonfigurasi 'jdbc.properties.useSSL' = 'false'.
Untuk informasi lebih lanjut tentang parameter koneksi yang didukung, lihat MySQL Configuration Properties.
debezium.*
Parameter kustom untuk Debezium guna membaca log biner.
Tidak
STRING
Tidak ada
Anda dapat meneruskan parameter Debezium kustom. Misalnya, gunakan 'debezium.event.deserialization.failure.handling.mode'='ignore' untuk menentukan logika penanganan error parsing.
PeringatanJangan mengubah parameter Debezium secara sembarangan. Hal ini dapat menyebabkan konektor membaca data secara salah. Misalnya, parameter debezium.binlog.buffer.size tidak boleh dikonfigurasi.
heartbeat.interval
Interval sumber memajukan offset log biner menggunakan event heartbeat.
Tidak
DURATION
30s
Event heartbeat digunakan untuk memajukan offset log biner di sumber. Hal ini sangat berguna untuk tabel di MySQL yang jarang diperbarui. Untuk tabel tersebut, offset log biner tidak dapat maju secara otomatis. Event heartbeat dapat mendorong offset log biner maju, yang mencegah masalah yang disebabkan oleh offset log biner yang kedaluwarsa. Offset log biner yang kedaluwarsa dapat menyebabkan pekerjaan gagal dan tidak dapat dipulihkan, sehingga memerlukan restart tanpa status.
scan.incremental.snapshot.chunk.key-column
Menentukan kolom yang akan digunakan sebagai kolom pemisah untuk sharding selama fase snapshot.
Lihat kolom Catatan.
STRING
Tidak ada
-
Wajib untuk tabel tanpa primary key. Kolom yang dipilih harus bertipe non-null (NOT NULL).
-
Opsional untuk tabel dengan primary key. Hanya satu kolom yang dapat dipilih dari primary key.
rds.region-id
ID wilayah instans Alibaba Cloud ApsaraDB RDS for MySQL.
Wajib saat menggunakan fitur membaca log arsip dari OSS.
STRING
Tidak ada
Untuk informasi lebih lanjut tentang ID wilayah, lihat Wilayah dan zona.
PentingKarena string GTID untuk CDC MySQL dihasilkan secara acak dan tidak meningkat secara monoton seperti offset file log biner, menemukan GTID dalam file memerlukan pengunduhan dan parsing semua log arsip dari OSS. Proses ini sangat intensif sumber daya dan memakan waktu, sehingga fitur yang bergantung pada offset GTID tidak layak. Oleh karena itu, fitur log arsip OSS hanya mendukung pemulaian dari timestamp tertentu atau offset file log biner tertentu. Fitur ini tidak mendukung pemulaian dari GTID tertentu, maupun skenario dengan alih bencana primer/sekunder dalam log arsip, karena alih bencana primer/sekunder MySQL bergantung pada GTID. Evaluasi fitur ini dengan hati-hati sebelum digunakan.
rds.access-key-id
ID AccessKey akun Alibaba Cloud ApsaraDB RDS for MySQL.
Wajib saat menggunakan fitur membaca log arsip dari OSS.
STRING
Tidak ada
Untuk informasi lebih lanjut, lihat Bagaimana cara melihat ID AccessKey dan Rahasia AccessKey?.
PentingUntuk mencegah Informasi AccessKey Anda bocor, gunakan fitur manajemen rahasia untuk menentukan ID AccessKey. Untuk informasi lebih lanjut, lihat Kelola variabel.
rds.access-key-secret
Rahasia AccessKey akun Alibaba Cloud ApsaraDB RDS for MySQL.
Wajib saat menggunakan fitur membaca log arsip dari OSS.
STRING
Tidak ada
Untuk informasi lebih lanjut, lihat Bagaimana cara melihat ID AccessKey dan Rahasia AccessKey?
PentingUntuk mencegah Informasi AccessKey Anda bocor, gunakan fitur manajemen rahasia untuk menentukan Rahasia AccessKey. Untuk informasi lebih lanjut, lihat Kelola variabel.
rds.db-instance-id
ID instans Alibaba Cloud ApsaraDB RDS for MySQL.
Wajib saat menggunakan fitur membaca log arsip dari OSS.
STRING
Tidak ada
Tidak ada.
rds.main-db-id
Nomor database utama instans Alibaba Cloud ApsaraDB RDS for MySQL.
Tidak
STRING
Tidak ada
-
Untuk informasi lebih lanjut tentang cara mendapatkan nomor database utama, lihat Cadangan log ApsaraDB RDS for MySQL.
-
Hanya didukung di VVR 8.0.7 dan versi yang lebih baru.
CatatanJika parameter ini tidak ditentukan, VVR 11.7 dan versi yang lebih baru secara otomatis mengkueri nomor database utama berdasarkan informasi koneksi ApsaraDB RDS for MySQL.
rds.download.timeout
Periode timeout untuk mengunduh satu log arsip dari OSS.
Tidak
DURATION
60s
Tidak ada.
rds.endpoint
Titik akhir layanan untuk mendapatkan informasi log biner OSS.
Tidak
STRING
Tidak ada
-
Untuk informasi lebih lanjut tentang nilai yang valid, lihat Titik akhir.
-
Hanya didukung di VVR 8.0.8 dan versi yang lebih baru.
scan.incremental.close-idle-reader.enabled
Menentukan apakah akan menutup pembaca menganggur setelah snapshot selesai.
Tidak
BOOLEAN
false
-
Hanya didukung di VVR 8.0.1 dan versi yang lebih baru.
-
Agar konfigurasi ini berlaku, Anda harus mengatur execution.checkpointing.checkpoints-after-tasks-finish.enabled ke true.
scan.read-changelog-as-append-only.enabled
Menentukan apakah akan mengonversi aliran data changelog menjadi aliran data append-only.
Tidak
BOOLEAN
false
Nilai yang valid:
-
true: Semua jenis pesan, termasuk INSERT, DELETE, UPDATE_BEFORE, dan UPDATE_AFTER, dikonversi menjadi pesan INSERT. Aktifkan opsi ini hanya dalam skenario khusus, seperti saat Anda perlu menyimpan pesan hapus dari tabel hulu.
-
false (default): Semua jenis pesan dikirim ke hilir sebagaimana adanya.
CatatanHanya didukung di VVR 8.0.8 dan versi yang lebih baru.
scan.only.deserialize.captured.tables.changelog.enabled
Dalam fase inkremental, menentukan apakah hanya akan mendeserialisasi event perubahan tabel yang ditentukan.
Tidak
BOOLEAN
-
Nilai default adalah false di versi VVR 8.x.
-
Nilai default adalah true di VVR 11.1 dan versi yang lebih baru.
Nilai yang valid:
-
true: Hanya mendeserialisasi data perubahan tabel target untuk mempercepat pembacaan log biner.
-
false (default): Mendeserialisasi data perubahan semua tabel.
Catatan-
Hanya didukung di VVR 8.0.7 dan versi yang lebih baru.
-
Saat menggunakan VVR 8.0.8 atau versi sebelumnya, Anda harus mengubah nama parameter menjadi debezium.scan.only.deserialize.captured.tables.changelog.enable.
scan.parse.online.schema.changes.enabled
Dalam fase inkremental, menentukan apakah akan mencoba mengurai event DDL perubahan tanpa kunci RDS.
Tidak
BOOLEAN
false
Nilai yang valid:
-
true: Mengurai event DDL perubahan tanpa kunci RDS.
-
false (default): Tidak mengurai event DDL perubahan tanpa kunci RDS.
Ini adalah fitur eksperimental. Sebelum melakukan perubahan tanpa kunci online, ambil snapshot pekerjaan Flink untuk pemulihan.
CatatanHanya didukung di VVR 11.1 dan versi yang lebih baru.
scan.incremental.snapshot.backfill.skip
Menentukan apakah akan melewati backfill selama fase pembacaan snapshot.
Tidak
BOOLEAN
false
Nilai yang valid:
-
true: Melewati backfill selama fase pembacaan snapshot.
-
false (default): Tidak melewati backfill selama fase pembacaan snapshot.
Backfill hanya berlaku selama kueri snapshot chunk tunggal dan tidak mencakup seluruh fase pembacaan penuh. Saat backfill dilewati, kueri snapshot setiap chunk membaca data tabel terbaru pada saat itu; pembaruan yang terjadi pada chunk setelah dibaca tidak digabungkan selama fase pembacaan penuh dan dibaca dari Binlog setelah memasuki fase inkremental. Misalnya, pembaruan pada chunk5 yang terjadi saat chunk5 sedang di-snapshot tercermin langsung dalam snapshot chunk5; jika chunk5 diperbarui setelah pembaca maju ke chunk80, pembaruan tersebut diterapkan nanti dari Binlog selama fase inkremental.
PentingSaat diaktifkan, perubahan yang terjadi selama atau setelah pemindaian chunk tetap dikirim dari Binlog dalam fase inkremental dan mungkin diduplikasi. Hanya semantik setidaknya-sekali yang dijamin. Aktifkan ini hanya saat sink hilir mendukung penulisan idempoten berdasarkan primary key.
CatatanHanya didukung di VVR 11.1 dan versi yang lebih baru.
scan.incremental.snapshot.unbounded-chunk-first.enabled
Menentukan apakah akan mengirimkan chunk tak terbatas terlebih dahulu selama fase pembacaan snapshot.
Tidak
BOOELEAN
false
Nilai yang valid:
-
true: Mengirimkan chunk tak terbatas terlebih dahulu selama fase pembacaan snapshot.
-
false (default): Tidak mengirimkan chunk tak terbatas terlebih dahulu selama fase pembacaan snapshot.
Ini adalah fitur eksperimental. Mengaktifkannya dapat mengurangi risiko error OOM pada Pengelola Tugas saat menyinkronkan chunk terakhir selama fase snapshot. Tambahkan parameter ini sebelum startup pertama pekerjaan.
CatatanHanya didukung di VVR 11.1 dan versi yang lebih baru.
binlog.session.network.timeout
Timeout baca/tulis jaringan untuk koneksi log biner.
Tidak
DURATION
10m
Jika diatur ke 0s, timeout default server MySQL digunakan.
CatatanHanya didukung di VVR 11.5 dan versi yang lebih baru.
scan.rate-limit.records-per-second
Membatasi jumlah maksimum catatan yang dikirim oleh sumber per detik.
Tidak
LONG
Tidak ada
Ini berlaku untuk skenario di mana pembacaan data perlu dibatasi. Batasan ini berlaku baik dalam fase penuh maupun inkremental.
Metrik
numRecordsOutPerSeconddari sumber mencerminkan jumlah catatan yang dikeluarkan oleh seluruh aliran data per detik. Anda dapat menyesuaikan parameter ini berdasarkan metrik tersebut.Dalam fase pembacaan data penuh, Anda biasanya perlu mengurangi jumlah baris yang dibaca dalam setiap batch. Anda dapat mengurangi nilai parameter
scan.incremental.snapshot.chunk.size.CatatanHanya didukung di VVR 11.5 dan versi yang lebih baru.
scan.binlog.tolerate.gtid-holes
Mengaktifkan parameter ini mengabaikan celah dalam urutan GTID, memungkinkan pekerjaan melewati event yang tidak berurutan dan terus berjalan.
Tidak
BOOLEAN
false
Sebelum mengaktifkan parameter ini, Anda harus memastikan bahwa offset startup pekerjaan belum kedaluwarsa. Jika pekerjaan dimulai dari offset GTID yang dihapus atau kedaluwarsa, mesin akan diam-diam melewatkan log yang hilang, yang akan menyebabkan kehilangan data.
CatatanParameter ini hanya didukung di VVR 11.6 dan versi yang lebih baru.
scan.filter-unchanged-row.enabled
Menentukan apakah akan menyaring event perubahan bidang yang tidak digunakan dalam SQL.
Tidak
BOOLEAN
false
Jika Anda mengatur parameter ini ke true, tabel sumber CDC hanya membandingkan kolom yang dirujuk dalam pernyataan SQL saat menerima event UPDATE. Jika nilai kolom yang dirujuk tidak berubah, event tersebut tidak dikirim ke hilir. Parameter ini berlaku dalam skenario JOIN multi-aliran. Jika tabel hulu memperbarui bidang yang tidak dirujuk dalam pernyataan SQL, event DELETE dan INSERT yang tidak perlu tidak dihasilkan. Hal ini mengurangi amplifikasi data dan jitter hasil pada operator hilir.
CatatanParameter ini hanya didukung di VVR 11.8 dan versi yang lebih baru.
scan.projection-pushdown.enabled
Menentukan apakah akan mengaktifkan projection pushdown.
Tidak
BOOLEAN
false
Jika Anda mengatur parameter ini ke true, tabel sumber CDC hanya mengurai dan mentransmisikan kolom yang dirujuk dalam pernyataan SQL. Kolom yang tidak dirujuk tidak diserialisasi atau ditransmisikan melalui jaringan. Hal ini mengurangi overhead I/O dan komputasi. Parameter ini bekerja lebih baik jika digunakan bersama dengan
scan.filter-unchanged-row.enabled. Projection pushdown pertama-tama mengurangi volume data, lalu baris yang tidak berubah disaring untuk lebih meringankan beban pemrosesan pada operator hilir.CatatanParameter ini hanya didukung di VVR 11.8 dan versi yang lebih baru.
-
-
Parameter khusus tabel dimensi
Parameter
Deskripsi
Wajib
Tipe data
Nilai default
Catatan
url
URL JDBC MySQL.
Tidak
STRING
Tidak ada
Format URL adalah:
jdbc:mysql://<endpoint>:<port>/<database_name>.lookup.max-retries
Jumlah maksimum percobaan ulang setelah pembacaan data gagal.
Tidak
INTEGER
3
Hanya didukung di VVR 6.0.7 dan versi yang lebih baru.
lookup.cache.strategy
Kebijakan cache.
Tidak
STRING
Tidak ada
Kebijakan cache yang didukung adalah None, LRU, dan ALL. Untuk informasi lebih lanjut tentang nilai-nilai tersebut, lihat Pernyataan JOIN tabel dimensi.
CatatanSaat Anda menggunakan kebijakan cache LRU, Anda juga harus mengonfigurasi parameter lookup.cache.max-rows.
lookup.cache.max-rows
Jumlah maksimum baris yang di-cache.
Tidak
INTEGER
100000
-
Jika Anda memilih kebijakan cache LRU, Anda harus mengatur ukuran cache.
-
Jika Anda memilih kebijakan cache ALL, Anda tidak perlu mengatur ukuran cache.
lookup.cache.ttl
Waktu hidup (TTL) cache.
Tidak
DURATION
10 s
Konfigurasi lookup.cache.ttl bergantung pada lookup.cache.strategy:
-
Jika lookup.cache.strategy diatur ke None, Anda tidak perlu mengonfigurasi lookup.cache.ttl. Artinya cache tidak kedaluwarsa.
-
Jika lookup.cache.strategy diatur ke LRU, lookup.cache.ttl adalah TTL cache. Secara default, cache tidak kedaluwarsa.
-
Jika lookup.cache.strategy diatur ke ALL, lookup.cache.ttl adalah waktu pemuatan cache. Secara default, cache tidak dimuat ulang.
Gunakan format waktu, seperti 1min atau 10s.
lookup.max-join-rows
Jumlah maksimum hasil yang dikembalikan saat catatan dari tabel utama cocok dengan catatan di tabel dimensi.
Tidak
INTEGER
1024
Tidak ada.
lookup.filter-push-down.enabled
Menentukan apakah akan mengaktifkan filter pushdown untuk tabel dimensi.
Tidak
BOOLEAN
false
Nilai yang valid:
-
true: Mengaktifkan filter pushdown untuk tabel dimensi. Saat memuat data dari tabel database MySQL, tabel dimensi menyaring data terlebih dahulu berdasarkan kondisi yang ditetapkan dalam pekerjaan SQL.
-
false (default): Menonaktifkan filter pushdown untuk tabel dimensi. Saat memuat data dari tabel database MySQL, tabel dimensi memuat semua data.
CatatanHanya didukung di VVR 8.0.7 dan versi yang lebih baru.
PentingPushdown tabel dimensi hanya boleh diaktifkan saat tabel Flink digunakan sebagai tabel dimensi. Tabel sumber MySQL tidak mendukung pengaktifan filter pushdown. Jika tabel Flink digunakan sebagai tabel sumber dan tabel dimensi, dan filter pushdown diaktifkan untuk tabel dimensi, Anda harus secara eksplisit mengatur item konfigurasi ini ke false untuk tabel sumber menggunakan Petunjuk SQL. Jika tidak, pekerjaan mungkin berjalan tidak normal.
lookup.cache.cache-empty
Menentukan apakah akan menyimpan hasil kueri kosong dalam cache.
Tidak
BOOLEAN
true
Hanya berlaku saat kebijakan cache adalah
LRU. Nilai yang valid:-
true (default): jika kueri tidak mengembalikan data, hasil kosong di-cache dan dikembalikan langsung untuk kueri berikutnya.
-
false: jika kueri tidak mengembalikan data, tidak ada hasil yang di-cache dan kueri berikutnya mencari data lagi.
CatatanParameter ini hanya didukung di VVR 11.9.0 dan versi yang lebih baru.
-
-
Hanya untuk tabel sink
Parameter
Deskripsi
Wajib
Tipe data
Nilai default
Catatan
url
URL JDBC MySQL.
Tidak
STRING
Tidak ada
Format URL adalah:
jdbc:mysql://<endpoint>:<port>/<database_name>.sink.max-retries
Jumlah maksimum percobaan ulang setelah penulisan data gagal.
Tidak
INTEGER
3
Tidak ada.
sink.buffer-flush.batch-size
Jumlah baris dalam satu penulisan batch.
Tidak
INTEGER
4096
Tidak ada.
sink.buffer-flush.max-rows
Jumlah baris data yang di-cache dalam memori.
Tidak
INTEGER
10000
Parameter ini hanya berlaku setelah primary key ditentukan.
sink.buffer-flush.interval
Interval untuk membersihkan cache. Jika data dalam cache tidak memenuhi kondisi output setelah waktu tunggu yang ditentukan, sistem secara otomatis mengeluarkan semua data dalam cache.
Tidak
DURATION
1s
Tidak ada.
sink.ignore-delete
Menentukan apakah akan mengabaikan operasi DELETE data.
Tidak
BOOLEAN
false
Saat aliran yang dihasilkan oleh Flink SQL mencakup catatan delete atau update-before, jika beberapa tugas output memperbarui bidang berbeda dari tabel yang sama secara bersamaan, ketidaksesuaian data dapat terjadi.
Misalnya, setelah catatan dihapus, tugas lain hanya memperbarui beberapa bidang. Bidang yang tidak diperbarui akan menjadi null atau nilai default, menyebabkan error data.
Dengan mengatur sink.ignore-delete ke true, Anda dapat mengabaikan operasi DELETE dan UPDATE_BEFORE hulu untuk menghindari masalah tersebut.
Catatan-
UPDATE_BEFORE adalah bagian dari mekanisme penarikan Flink, digunakan untuk "menarik kembali" nilai lama dalam operasi pembaruan.
-
Saat ignoreDelete = true, semua catatan tipe DELETE dan UPDATE_BEFORE dilewati. Hanya catatan INSERT dan UPDATE_AFTER yang diproses.
sink.ignore-delete-mode
Strategi untuk menangani catatan tipe hapus setelah operasi DELETE diabaikan.
Tidak
STRING
ALL
Nilai yang valid:
-
ALL: Mengabaikan catatan -D dan -U.
-
REAL_DELETE: Hanya mengabaikan catatan -D.
-
UPDATE_BEFORE: Hanya mengabaikan catatan -U.
Catatan-
Opsi ini hanya didukung di mesin Realtime Compute VVR 11.8 dan versi yang lebih baru.
-
Hanya berlaku saat sink.ignore-delete=true. Mengonfigurasinya sendiri menghasilkan error.
sink.ignore-null-when-update
Saat memperbarui data, menentukan apakah akan memperbarui bidang yang sesuai menjadi null atau melewatkan pembaruan untuk bidang tersebut jika nilai bidang data yang masuk adalah null.
Tidak
BOOLEAN
false
Nilai yang valid:
-
true: Tidak memperbarui bidang. Parameter ini hanya dapat diatur ke true saat primary key ditetapkan untuk tabel Flink. Saat diatur ke true:
-
Untuk VVR 8.0.6 dan versi sebelumnya, tabel sink tidak mendukung penulisan batch.
-
Untuk VVR 8.0.7 dan versi yang lebih baru, tabel sink mendukung penulisan batch.
Penulisan batch dapat secara signifikan meningkatkan efisiensi penulisan dan throughput keseluruhan, tetapi memperkenalkan latensi data dan risiko error OOM. Oleh karena itu, Anda harus membuat pertimbangan berdasarkan skenario bisnis Anda.
-
-
false: Memperbarui bidang menjadi null.
CatatanParameter ini hanya didukung di VVR 8.0.5 dan versi yang lebih baru.
sink.force-batch-on-non-primary-table
Menentukan apakah akan memaksa buffering catatan dan memasukkannya secara batch menggunakan JDBC Batch saat data ditulis ke tabel sink MySQL yang tidak memiliki primary key.
Tidak
BOOLEAN
false
Parameter ini hanya berlaku pada tabel yang tidak memiliki primary key. Jika Anda mengatur parameter ini ke true, event DELETE dan UPDATE_BEFORE diam-diam dibuang, dan event INSERT dan UPDATE_AFTER ditulis secara batch sebagai pernyataan INSERT. Kami menyarankan agar Anda mengaktifkan parameter ini hanya jika datanya append-only atau semantik sebelumnya dapat diterima oleh Anda.
Catatan-
Parameter ini hanya didukung di VVR 11.8 dan versi yang lebih baru.
-
Aktifkan parameter ini hanya jika datanya append-only atau semantik sebelumnya dapat diterima oleh Anda. Jika tidak, data mungkin menjadi tidak konsisten.
-
Pemetaan tipe
-
Tabel sumber CDC
Tipe bidang CDC MySQL
Tipe bidang Flink
TINYINT
TINYINT
SMALLINT
SMALLINT
TINYINT UNSIGNED
TINYINT UNSIGNED ZEROFILL
INT
INT
MEDIUMINT
SMALLINT UNSIGNED
SMALLINT UNSIGNED ZEROFILL
BIGINT
BIGINT
INT UNSIGNED
INT UNSIGNED ZEROFILL
MEDIUMINT UNSIGNED
MEDIUMINT UNSIGNED ZEROFILL
BIGINT UNSIGNED
DECIMAL(20, 0)
BIGINT UNSIGNED ZEROFILL
SERIAL
FLOAT [UNSIGNED] [ZEROFILL]
FLOAT
DOUBLE [UNSIGNED] [ZEROFILL]
DOUBLE
DOUBLE PRECISION [UNSIGNED] [ZEROFILL]
REAL [UNSIGNED] [ZEROFILL]
NUMERIC(p, s) [UNSIGNED] [ZEROFILL]
DECIMAL(p, s)
DECIMAL(p, s) [UNSIGNED] [ZEROFILL]
BOOLEAN
BOOLEAN
TINYINT(1)
DATE
DATE
TIME [(p)]
TIME [(p)] [WITHOUT TIME ZONE]
DATETIME [(p)]
TIMESTAMP [(p)] [WITHOUT TIME ZONE]
TIMESTAMP [(p)]
TIMESTAMP [(p)]
TIMESTAMP [(p)] WITH LOCAL TIME ZONE
CHAR(n)
STRING
VARCHAR(n)
TEXT
BINARY
BYTES
VARBINARY
BLOB
PentingJangan gunakan tipe TINYINT(1) di MySQL untuk menyimpan nilai selain 0 dan 1. Saat property-version=0, tabel sumber CDC MySQL memetakan TINYINT(1) ke tipe BOOLEAN di Flink secara default. Hal ini dapat menyebabkan ketidakakuratan data. Untuk menggunakan tipe TINYINT(1) guna menyimpan nilai selain 0 dan 1, lihat parameter konfigurasi catalog.table.treat-tinyint1-as-boolean.
-
Tabel dimensi dan tabel sink
Tipe bidang MySQL
Tipe bidang Flink
TINYINT
TINYINT
SMALLINT
SMALLINT
TINYINT UNSIGNED
INT
INT
MEDIUMINT
SMALLINT UNSIGNED
BIGINT
BIGINT
INT UNSIGNED
BIGINT UNSIGNED
DECIMAL(20, 0)
FLOAT
FLOAT
DOUBLE
DOUBLE
DOUBLE PRECISION
NUMERIC(p, s)
DECIMAL(p, s)
Catatandi mana p <= 38.
DECIMAL(p, s)
BOOLEAN
BOOLEAN
TINYINT(1)
DATE
DATE
TIME [(p)]
TIME [(p)] [WITHOUT TIME ZONE]
DATETIME [(p)]
TIMESTAMP [(p)] [WITHOUT TIME ZONE]
TIMESTAMP [(p)]
CHAR(n)
CHAR(n)
VARCHAR(n)
VARCHAR(n)
BIT(n)
BINARY(⌈n/8⌉)
BINARY(n)
BINARY(n)
VARBINARY(N)
VARBINARY(N)
TINYTEXT
STRING
TEXT
MEDIUMTEXT
LONGTEXT
TINYBLOB
BYTES
PentingFlink hanya mendukung catatan tipe BLOB MySQL yang kurang dari atau sama dengan 2.147.483.647 (2^31 - 1) byte.
BLOB
MEDIUMBLOB
LONGBLOB
Contoh penggunaan
-
Tabel sumber CDC
CREATE TEMPORARY TABLE mysqlcdc_source ( order_id INT, order_date TIMESTAMP(0), customer_name STRING, price DECIMAL(10, 5), product_id INT, order_status BOOLEAN, PRIMARY KEY(order_id) NOT ENFORCED ) WITH ( 'connector' = 'mysql', 'hostname' = '<yourHostname>', 'port' = '3306', 'username' = '<yourUsername>', 'password' = '<yourPassword>', 'database-name' = '<yourDatabaseName>', 'table-name' = '<yourTableName>' ); CREATE TEMPORARY TABLE blackhole_sink( order_id INT, customer_name STRING ) WITH ( 'connector' = 'blackhole' ); INSERT INTO blackhole_sink SELECT order_id, customer_name FROM mysqlcdc_source; -
Tabel dimensi
CREATE TEMPORARY TABLE datagen_source( a INT, b BIGINT, c STRING, `proctime` AS PROCTIME() ) WITH ( 'connector' = 'datagen' ); CREATE TEMPORARY TABLE mysql_dim ( a INT, b VARCHAR, c VARCHAR ) WITH ( 'connector' = 'mysql', 'hostname' = '<yourHostname>', 'port' = '3306', 'username' = '<yourUsername>', 'password' = '<yourPassword>', 'database-name' = '<yourDatabaseName>', 'table-name' = '<yourTableName>' ); CREATE TEMPORARY TABLE blackhole_sink( a INT, b STRING ) WITH ( 'connector' = 'blackhole' ); INSERT INTO blackhole_sink SELECT T.a, H.b FROM datagen_source AS T JOIN mysql_dim FOR SYSTEM_TIME AS OF T.`proctime` AS H ON T.a = H.a; -
Tabel Sink
CREATE TEMPORARY TABLE datagen_source ( `name` VARCHAR, `age` INT ) WITH ( 'connector' = 'datagen' ); CREATE TEMPORARY TABLE mysql_sink ( `name` VARCHAR, `age` INT ) WITH ( 'connector' = 'mysql', 'hostname' = '<yourHostname>', 'port' = '3306', 'username' = '<yourUsername>', 'password' = '<yourPassword>', 'database-name' = '<yourDatabaseName>', 'table-name' = '<yourTableName>' ); INSERT INTO mysql_sink SELECT * FROM datagen_source; -
Sumber data ingestion data
source: type: mysql name: MySQL Source hostname: ${mysql.hostname} port: ${mysql.port} username: ${mysql.username} password: ${mysql.password} tables: ${mysql.source.table} server-id: 7601-7604 sink: type: values name: Values Sink print.enabled: true sink.print.logger: true
Tentang tabel sumber CDC MySQL
-
Cara kerja
Saat tabel sumber CDC MySQL dimulai, tabel tersebut memindai seluruh tabel, membagi tabel menjadi beberapa chunk berdasarkan primary key, dan mencatat offset log biner saat ini. Tabel sumber kemudian menggunakan algoritma snapshot inkremental untuk membaca data dari setiap chunk menggunakan pernyataan SELECT. Pekerjaan secara berkala melakukan checkpoint untuk mencatat chunk yang telah selesai. Jika terjadi failover, pekerjaan melanjutkan membaca data dari chunk yang belum selesai. Setelah semua chunk dibaca, pekerjaan mulai membaca catatan perubahan inkremental dari offset log biner yang sebelumnya dicatat. Pekerjaan Flink terus melakukan checkpoint berkala untuk mencatat offset log biner. Jika pekerjaan gagal, pekerjaan melanjutkan pemrosesan dari offset log biner terakhir yang dicatat, yang mencapai semantik tepat-sekali.
Untuk penjelasan lebih rinci tentang algoritma snapshot inkremental, lihat Konektor CDC MySQL.
-
Metadata
Metadata berguna dalam skenario di mana data dari database dan tabel yang di-shard digabung dan disinkronkan. Hal ini karena setelah penggabungan, bisnis sering ingin membedakan database dan tabel sumber untuk setiap catatan data. Kolom metadata dapat mengakses informasi nama database dan tabel dari tabel sumber. Oleh karena itu, Anda dapat dengan mudah menggabungkan beberapa tabel yang di-shard menjadi satu tabel tujuan menggunakan kolom metadata.
Sumber CDC MySQL mendukung sintaks kolom metadata. Anda dapat mengakses metadata berikut melalui kolom metadata.
Kunci metadata
Tipe metadata
Deskripsi
database_name
STRING NOT NULL
Nama database yang berisi baris tersebut.
table_name
STRING NOT NULL
Nama tabel yang berisi baris tersebut.
op_ts
TIMESTAMP_LTZ(3) NOT NULL
Waktu baris tersebut diubah di database. Jika catatan berasal dari data historis tabel daripada log biner, nilai ini selalu 0.
CatatanBidang ini akurat hanya hingga detik.
op_type
STRING NOT NULL
Jenis perubahan baris tersebut.
-
+I: Pesan INSERT
-
-D: Pesan DELETE
-
-U: Pesan UPDATE_BEFORE
-
+U: Pesan UPDATE_AFTER
CatatanHanya didukung di VVR 8.0.7 dan versi yang lebih baru.
query_log
STRING NOT NULL
Anda dapat membaca catatan log kueri MySQL untuk baris ini.
CatatanMySQL perlu mengaktifkan parameter binlog_rows_query_log_events untuk mencatat log kueri.
Contoh kode berikut menunjukkan cara menggabungkan dan menyinkronkan beberapa tabel orders dari beberapa database yang di-shard dalam instans MySQL ke tabel holo_orders di Hologres.
CREATE TEMPORARY TABLE mysql_orders ( db_name STRING METADATA FROM 'database_name' VIRTUAL, -- Baca nama database. table_name STRING METADATA FROM 'table_name' VIRTUAL, -- Baca nama tabel. operation_ts TIMESTAMP_LTZ(3) METADATA FROM 'op_ts' VIRTUAL, -- Baca waktu perubahan. op_type STRING METADATA FROM 'op_type' VIRTUAL, -- Baca jenis perubahan. order_id INT, order_date TIMESTAMP(0), customer_name STRING, price DECIMAL(10, 5), product_id INT, order_status BOOLEAN, PRIMARY KEY(order_id) NOT ENFORCED ) WITH ( 'connector' = 'mysql-cdc', 'hostname' = 'localhost', 'port' = '3306', 'username' = 'flinkuser', 'password' = 'flinkpw', 'database-name' = 'mydb_.*', -- Ekspresi reguler untuk mencocokkan beberapa database yang di-shard. 'table-name' = 'orders_.*' -- Ekspresi reguler untuk mencocokkan beberapa tabel yang di-shard. ); INSERT INTO holo_orders SELECT * FROM mysql_orders;Berdasarkan kode di atas, jika parameter `scan.read-changelog-as-append-only.enabled` diatur ke true dalam klausa WITH, hasil output bervariasi tergantung pada pengaturan primary key tabel hilir:
-
Jika primary key tabel hilir adalah `order_id`, hasil output hanya berisi perubahan terakhir untuk setiap primary key di tabel hulu. Untuk data yang perubahan terakhirnya untuk primary key adalah operasi hapus, Anda dapat melihat catatan di tabel hilir dengan primary key yang sama dan `op_type` -D.
-
Jika primary key tabel hilir adalah `order_id`, `operation_ts`, dan `op_type`, hasil output berisi perubahan lengkap untuk setiap primary key di tabel hulu.
-
-
Dukungan ekspresi reguler
Tabel sumber CDC MySQL mendukung penggunaan ekspresi reguler dalam nama tabel atau nama database untuk mencocokkan beberapa tabel atau database. Contoh kode berikut menunjukkan cara menentukan beberapa tabel menggunakan ekspresi reguler.
CREATE TABLE products ( db_name STRING METADATA FROM 'database_name' VIRTUAL, table_name STRING METADATA FROM 'table_name' VIRTUAL, operation_ts TIMESTAMP_LTZ(3) METADATA FROM 'op_ts' VIRTUAL, order_id INT, order_date TIMESTAMP(0), customer_name STRING, price DECIMAL(10, 5), product_id INT, order_status BOOLEAN, PRIMARY KEY(order_id) NOT ENFORCED ) WITH ( 'connector' = 'mysql-cdc', 'hostname' = 'localhost', 'port' = '3306', 'username' = 'root', 'password' = '123456', 'database-name' = '(^(test).*|^(tpc).*|txc|.*[p$]|t{2})', -- Ekspresi reguler untuk mencocokkan beberapa database. 'table-name' = '(t[5-8]|tt)' -- Ekspresi reguler untuk mencocokkan beberapa tabel. );Ekspresi reguler dalam contoh dijelaskan sebagai berikut:
-
`^(test).*` adalah contoh pencocokan prefiks. Ekspresi ini dapat mencocokkan nama database yang dimulai dengan "test", seperti "test1" atau "test2".
-
`.*[p$]` adalah contoh pencocokan sufiks. Ekspresi ini dapat mencocokkan nama database yang diakhiri dengan "p", seperti "cdcp" atau "edcp".
-
`txc` adalah pencocokan spesifik. Ekspresi ini dapat mencocokkan nama database yang persis "txc".
Saat CDC MySQL mencocokkan nama tabel yang memenuhi syarat penuh, CDC MySQL menggunakan pola `database-name.table-name` untuk mengidentifikasi tabel secara unik. Misalnya, pola `(^(test).*|^(tpc).*|txc|.*[p$]|t{2}).(t[ 5-8]|tt)` dapat mencocokkan tabel seperti `txc.tt` dan `test2.test5` dalam database.
PentingDalam konfigurasi pekerjaan SQL, parameter `table-name` dan `database-name` tidak mendukung penggunaan koma (,) untuk menentukan beberapa tabel atau database.
-
Untuk mencocokkan beberapa tabel atau menggunakan beberapa ekspresi reguler, hubungkan dengan tanda garis vertikal (|) dan sertakan dalam tanda kurung. Misalnya, untuk membaca tabel `user` dan `product`, Anda dapat mengatur `table-name` ke
(user|product). -
Jika ekspresi reguler berisi koma, Anda harus menulis ulang menggunakan operator garis vertikal (|). Misalnya, ekspresi reguler
mytable_\d{1, 2}harus ditulis ulang menjadi setara(mytable_\d{1}|mytable_\d{2})untuk menghindari penggunaan koma.
-
-
Kontrol konkurensi
Konektor MySQL mendukung pembacaan data penuh multithreaded, yang dapat meningkatkan efisiensi pemuatan data. Bersamaan dengan fitur tuning otomatis Autopilot di konsol Realtime Compute for Apache Flink, konektor dapat secara otomatis melakukan skala-masuk selama fase inkremental setelah pembacaan multithreaded selesai untuk menghemat sumber daya komputasi.
Di konsol pengembangan Realtime Compute for Apache Flink, Anda dapat mengatur konkurensi pekerjaan dalam mode dasar atau mode ahli di halaman Konfigurasi Sumber Daya.
-
Konkurensi yang diatur dalam mode dasar adalah konkurensi global untuk seluruh pekerjaan.
Misalnya, saat parallelism diatur ke
8dalam mode dasar,server-iddalam klausa WITH SQL harus dikonfigurasi sebagai rentang kontinu (seperti'404-412'). -
Mode ahli mendukung pengaturan konkurensi untuk VERTEX tertentu sesuai kebutuhan.
Untuk informasi lebih lanjut tentang konfigurasi sumber daya, lihat Konfigurasi informasi penerapan untuk pekerjaan.
PentingBaik dalam mode dasar maupun mode ahli, saat Anda mengatur konkurensi, rentang ID server yang dideklarasikan dalam tabel harus lebih besar dari atau sama dengan konkurensi pekerjaan. Misalnya, jika rentang ID server adalah `5404-5412`, terdapat sembilan ID server unik. Oleh karena itu, konkurensi pekerjaan dapat diatur hingga maksimum 9. Pekerjaan berbeda untuk instans MySQL yang sama tidak boleh memiliki rentang ID server yang tumpang tindih. Artinya, setiap pekerjaan harus secara eksplisit dikonfigurasi dengan ID server atau rentang ID server yang berbeda.
-
-
Skala-masuk otomatis Autopilot
Fase data penuh mengakumulasi sejumlah besar data historis. Untuk meningkatkan efisiensi pembacaan, data historis biasanya dibaca secara paralel. Dalam fase log biner inkremental, karena jumlah data log biner kecil dan untuk memastikan urutan global, pembacaan single-threaded biasanya sudah cukup. Persyaratan sumber daya yang berbeda dari fase penuh dan inkremental dapat diseimbangkan untuk kinerja dan sumber daya menggunakan fitur tuning otomatis.
Tuning otomatis memantau trafik setiap tugas Sumber CDC MySQL. Saat memasuki fase log biner, jika hanya satu tugas yang bertanggung jawab atas pembacaan log biner dan tugas lainnya menganggur, tuning otomatis secara otomatis mengurangi jumlah CU dan konkurensi sumber. Untuk mengaktifkan tuning otomatis, atur mode tuning otomatis ke Active di halaman O&M pekerjaan.
CatatanInterval pemicu minimum default untuk mengurangi konkurensi adalah 24 jam. Untuk informasi lebih lanjut tentang parameter dan detail tuning otomatis, lihat Konfigurasi tuning otomatis.
-
Mode startup
Gunakan item konfigurasi `scan.startup.mode` untuk menentukan mode startup tabel sumber CDC MySQL. Opsi-opsinya meliputi:
-
initial (default): Saat startup pertama atau startup tanpa status, melakukan pembacaan penuh tabel database lalu beralih ke mode inkremental untuk membaca log biner.
-
earliest-offset: Melewati fase snapshot dan mulai membaca dari offset log biner yang tersedia paling awal.
-
latest-offset: Melewati fase snapshot dan mulai membaca dari akhir log biner. Dalam mode ini, tabel sumber hanya dapat membaca perubahan data yang terjadi setelah pekerjaan dimulai.
-
specific-offset: Melewati fase snapshot dan mulai membaca dari offset log biner tertentu. Offset dapat ditentukan oleh nama file log biner dan posisi, atau oleh set GTID.
-
timestamp: Melewati fase snapshot dan mulai membaca event log biner dari timestamp tertentu.
Startup tanpa status tidak menggunakan kembali status apa pun. Konektor sumber memperlakukannya sebagai startup pertama, sehingga scan.startup.mode berlaku kembali. Untuk informasi lebih lanjut tentang mode startup penerapan, lihat Mulai penerapan.
Contoh penggunaan:
CREATE TABLE mysql_source (...) WITH ( 'connector' = 'mysql-cdc', 'scan.startup.mode' = 'earliest-offset', -- Mulai dari offset paling awal. 'scan.startup.mode' = 'latest-offset', -- Mulai dari offset terbaru. 'scan.startup.mode' = 'specific-offset', -- Mulai dari offset tertentu. 'scan.startup.mode' = 'timestamp', -- Mulai dari timestamp tertentu. 'scan.startup.specific-offset.file' = 'mysql-bin.000003', -- Tentukan nama file log biner dalam mode specific-offset. 'scan.startup.specific-offset.pos' = '4', -- Tentukan posisi log biner dalam mode specific-offset. 'scan.startup.specific-offset.gtid-set' = '24DA167-0C0C-11E8-8442-00059A3C7B00:1-19', -- Tentukan set GTID dalam mode specific-offset. 'scan.startup.timestamp-millis' = '1667232000000' -- Tentukan timestamp startup dalam mode timestamp. ... )Penting-
Sumber MySQL mencetak offset saat ini ke log pada level INFO selama checkpoint. Awalan log adalah
Binlog offset on checkpoint {checkpoint-id}. Log ini dapat membantu Anda memulai pekerjaan dari offset checkpoint tertentu. -
Jika tabel yang dibaca telah mengalami perubahan skema, memulai dari `earliest-offset`, `specific-offset`, atau `timestamp` dapat menyebabkan error. Hal ini karena pembaca Debezium secara internal menyimpan skema tabel terbaru, dan data awal dengan skema yang tidak cocok tidak dapat diurai dengan benar.
-
-
Tentang tabel sumber CDC tanpa primary key
-
Menggunakan tabel tanpa primary key memerlukan pengaturan `scan.incremental.snapshot.chunk.key-column`, dan hanya kolom non-null yang dapat dipilih.
-
Semantik pemrosesan untuk tabel sumber CDC tanpa primary key ditentukan oleh perilaku kolom yang ditentukan oleh `scan.incremental.snapshot.chunk.key-column`:
-
Jika kolom yang ditentukan tidak diperbarui, semantik tepat-sekali dapat dijamin.
-
Jika kolom yang ditentukan diperbarui, hanya semantik setidaknya-sekali yang dapat dijamin. Namun, Anda dapat memastikan kebenaran data dengan menggabungkannya dengan hilir, menentukan primary key hilir, dan menggunakan operasi idempoten.
-
-
-
Baca log cadangan Alibaba Cloud ApsaraDB RDS for MySQL
Tabel sumber CDC MySQL mendukung pembacaan log cadangan Alibaba Cloud ApsaraDB RDS for MySQL. Hal ini berguna dalam skenario di mana fase data penuh memakan waktu lama dan file log biner lokal telah dihapus secara otomatis, tetapi file cadangan yang diunggah secara otomatis atau manual masih ada.
Contoh penggunaan:
CREATE TABLE mysql_source (...) WITH ( 'connector' = 'mysql-cdc', 'rds.region-id' = 'cn-beijing', 'rds.access-key-id' = 'xxxxxxxxx', 'rds.access-key-secret' = 'xxxxxxxxx', 'rds.db-instance-id' = 'rm-xxxxxxxxxxxxxxxxx', 'rds.main-db-id' = '12345678', 'rds.download.timeout' = '60s' ... ) -
Aktifkan penggunaan ulang sumber CDC
Dalam pekerjaan yang sama, beberapa tabel sumber CDC MySQL memulai beberapa klien log biner. Jika semua tabel sumber berada dalam instans yang sama, hal ini meningkatkan beban pada database. Untuk informasi lebih lanjut, lihat FAQ CDC MySQL.
Solusi
VVR 8.0.7 dan versi yang lebih baru mendukung penggunaan ulang sumber CDC MySQL. Fitur ini menggabungkan tabel sumber CDC MySQL yang dapat digabungkan. Penggabungan terjadi saat konfigurasi tabel sumber identik, kecuali untuk nama database, nama tabel, dan
server-id. Mesin secara otomatis menggabungkan sumber CDC MySQL dalam pekerjaan yang sama.Prosedur
-
Gunakan perintah
SETdalam pekerjaan SQL Anda:SET 'table.optimizer.source-merge.enabled' = 'true'; # (Untuk VVR 8.0.8 dan 8.0.9) Atur juga item ini: SET 'sql-gateway.exec-plan.enabled' = 'false';VVR 11.1 dan versi yang lebih baru memiliki penggunaan ulang diaktifkan secara default.
-
Mulai pekerjaan tanpa status. Karena memodifikasi konfigurasi penggunaan ulang sumber mengubah topologi pekerjaan, Anda harus memulai pekerjaan tanpa status. Jika tidak, pekerjaan mungkin gagal dimulai atau Anda mungkin kehilangan data. Jika sumber digabungkan, Anda dapat melihat node
MergetableSourceScandalam topologi.
Penting-
Setelah Anda mengaktifkan penggunaan ulang, jangan nonaktifkan operator chaining. Jika Anda mengatur
pipeline.operator-chainingkefalse, hal ini meningkatkan overhead serialisasi dan deserialisasi data. Semakin banyak sumber yang digabungkan, semakin besar overhead-nya. -
Di VVR 8.0.7, menonaktifkan operator chaining menyebabkan masalah serialisasi.
-
Mempercepat pembacaan log biner
Saat Anda menggunakan konektor MySQL sebagai tabel sumber atau sumber data ingestion data, konektor tersebut mengurai file log biner untuk menghasilkan berbagai pesan perubahan selama fase inkremental. File log biner mencatat semua perubahan tabel dalam format biner. Anda dapat mempercepat penguraian file log biner dengan cara-cara berikut.
-
Aktifkan penguraian paralel dan filter penguraian (Fitur ini memerlukan Realtime Compute for Apache Flink dengan Ververica Runtime (VVR) 8.0.7 atau versi yang lebih baru. Fitur ini tidak tersedia di edisi komunitas konektor CDC MySQL.)
-
Aktifkan opsi
scan.only.deserialize.captured.tables.changelog.enableduntuk mengurai event perubahan hanya untuk tabel yang ditentukan. -
Aktifkan opsi
scan.parallel-deserialize-changelog.enableduntuk menggunakan beberapa thread guna mengurai file log biner dan mengirimkan event ke antrian konsumen secara berurutan. Saat Anda mengaktifkan opsi ini, Anda biasanya perlu meningkatkanCPU TaskManagerjuga.
-
-
Optimalkan parameter Debezium
debezium.max.queue.size: 162580 debezium.max.batch.size: 40960 debezium.poll.interval.ms: 50-
debezium.max.queue.size: Jumlah maksimum catatan yang dapat ditampung oleh antrian pemblokiran. Saat Debezium membaca aliran event dari database, Debezium menempatkan event dalam antrian pemblokiran sebelum menuliskannya ke hilir. Nilai default adalah 8192. -
debezium.max.batch.size: Jumlah maksimum event yang diproses konektor dalam setiap iterasi. Nilai default adalah 2048. -
debezium.poll.interval.ms: Jumlah milidetik yang harus ditunggu konektor sebelum meminta event perubahan baru. Nilai default adalah 1000 milidetik, atau 1 detik.
-
Contoh penggunaan:
CREATE TABLE mysql_source (...) WITH (
'connector' = 'mysql-cdc',
-- Konfigurasi Debezium
'debezium.max.queue.size' = '162580',
'debezium.max.batch.size' = '40960',
'debezium.poll.interval.ms' = '50',
-- Aktifkan filter penguraian
'scan.only.deserialize.captured.tables.changelog.enabled' = 'true', -- Hanya uraikan event perubahan tabel yang ditentukan.
...
)
source:
type: mysql
name: MySQL Source
hostname: ${mysql.hostname}
port: ${mysql.port}
username: ${mysql.username}
password: ${mysql.password}
tables: ${mysql.source.table}
server-id: 7601-7604
# Konfigurasi Debezium
debezium.max.queue.size: 162580
debezium.max.batch.size: 40960
debezium.poll.interval.ms: 50
# Aktifkan filter penguraian
scan.only.deserialize.captured.tables.changelog.enabled: true
Kapasitas konsumsi log biner Edisi Perusahaan CDC MySQL adalah 85 MB/detik, sekitar dua kali lipat dari versi komunitas open source. Saat kecepatan pembuatan file log biner melebihi 85 MB/detik (yaitu, satu file 512 MB setiap 6 detik), latensi pekerjaan Flink terus meningkat. Latensi pemrosesan secara bertahap berkurang setelah kecepatan pembuatan file log biner melambat. Jika file log biner berisi transaksi besar, latensi pemrosesan mungkin meningkat sementara. Latensi berkurang setelah log untuk transaksi tersebut dibaca.
Diagnosis latensi data untuk mengoptimalkan throughput pekerjaan
Jika Anda mengalami latensi data selama fase inkremental, analisis masalah dengan mengikuti langkah-langkah berikut:
-
Periksa metrik
currentFetchEventTimeLagdancurrentEmitEventTimeLagdi halaman Ikhtisar. MetrikcurrentFetchEventTimeLagmewakili latensi dalam membaca data dari log biner. MetrikcurrentEmitEventTimeLagmewakili latensi dalam membaca data untuk tabel yang relevan dengan pekerjaan dari log biner.Skenario
Deskripsi
currentFetchEventTimeLagrendah, sedangkancurrentEmitEventTimeLagtinggi dan jarang diperbarui.currentFetchEventTimeLagyang rendah menunjukkan bahwa menarik log biner dari database efisien. Namun, log biner berisi sedikit data untuk tabel yang perlu dibaca oleh pekerjaan. Oleh karena itu,currentEmitEventTimeLagjarang diperbarui. Ini adalah perilaku yang diharapkan.Kedua
currentFetchEventTimeLagdancurrentEmitEventTimeLagtinggi.Hal ini menunjukkan bahwa tabel sumber memiliki kinerja baca yang buruk. Anda dapat melanjutkan ke langkah-langkah selanjutnya dalam bagian ini untuk optimasi.
-
Tekanan balik dapat mengurangi laju sumber mengirim data ke operator hilir. Anda mungkin mengamati bahwa sourceIdleTime meningkat secara berkala, dan kedua currentFetchEventTimeLag dan currentEmitEventTimeLag terus bertambah. Untuk mengatasi hal ini, tingkatkan parallelisme node tempat tekanan balik berasal.
-
Periksa metrik TM CPU Usage di halaman CPU dan metrik TM GC Time di halaman JVM untuk menentukan apakah sumber daya CPU atau memori tidak mencukupi. Anda dapat meningkatkan sumber daya pekerjaan untuk mengoptimalkan kinerja baca. Anda juga dapat mengaktifkan parameter mini-batch untuk meningkatkan throughput. Untuk informasi lebih lanjut, lihat Teknik Optimasi SQL Flink Berkinerja Tinggi.
-
Jika operator SinkUpsertMaterializer dengan state besar ada dalam pekerjaan, hal ini dapat memengaruhi kinerja baca. Pertimbangkan untuk meningkatkan parallelisme pekerjaan atau menghindari operator SinkUpsertMaterializer. Untuk informasi lebih lanjut, lihat Hindari penggunaan SinkUpsertMaterializer. Menghapus operator SinkUpsertMaterializer dari pekerjaan yang ada memerlukan restart tanpa status. Hal ini karena topologi pekerjaan berubah, dan memulai dari state yang ada dapat menyebabkan pekerjaan gagal atau kehilangan data.
Tentukan ID server untuk menghindari konflik binlog
Setiap klien yang menyinkronkan data dari database memiliki ID unik yang disebut ID server. Jika pekerjaan berbeda menggunakan ID server yang sama, konflik dapat terjadi dan menyebabkan kegagalan pekerjaan. Kami menyarankan agar Anda memberikan ID server berbeda untuk setiap sumber data CDC MySQL.
-
Cara mengonfigurasi ID server
Anda dapat menentukan ID server dalam pernyataan DDL tabel Flink atau dengan menggunakan Petunjuk SQL.
Kami menyarankan menggunakan Petunjuk SQL untuk mengonfigurasi ID server daripada menentukannya dalam klausa WITH DDL tabel. Untuk informasi lebih lanjut, lihat Petunjuk SQL.
-
Konfigurasi ID server untuk skenario berbeda
-
Snapshot inkremental dinonaktifkan atau parallelisme adalah 1
Jika snapshot inkremental dinonaktifkan atau parallelisme adalah 1, Anda dapat menentukan satu ID server.
SELECT * FROM source_table /*+ OPTIONS('server-id'='123456') */ ; -
Snapshot inkremental diaktifkan dan parallelisme lebih besar dari 1
Saat snapshot inkremental diaktifkan dan parallelisme lebih besar dari 1, Anda harus menentukan rentang ID server. Jumlah ID server yang tersedia dalam rentang harus setidaknya sama dengan parallelisme. Misalnya, jika parallelisme adalah 3, Anda dapat menggunakan konfigurasi berikut:
SELECT * FROM source_table /*+ OPTIONS('server-id'='123456-123458') */ ; -
Pekerjaan SQL Flink yang berisi beberapa tabel sumber CDC MySQL
Jika pekerjaan SQL Flink berisi beberapa tabel sumber CDC MySQL dan penggunaan ulang sumber dinonaktifkan, Anda harus memberikan ID server berbeda untuk setiap tabel sumber CDC. Demikian pula, jika snapshot inkremental diaktifkan dan parallelisme lebih besar dari 1, Anda harus menentukan rentang ID server.
select * from source_table1 /*+ OPTIONS('server-id'='123456-123457') */ left join source_table2 /*+ OPTIONS('server-id'='123458-123459') */ on source_table1.id=source_table2.id;
-
Tentukan parameter chunk untuk mengoptimalkan penggunaan memori
Saat tabel sumber CDC MySQL dimulai, tabel tersebut melakukan pemindaian tabel penuh, membagi tabel menjadi beberapa chunk berdasarkan primary key, dan mencatat posisi log biner saat ini. Pekerjaan kemudian menggunakan algoritma snapshot inkremental untuk membaca data dari setiap chunk secara berurutan menggunakan pernyataan SELECT. Pekerjaan secara berkala melakukan checkpoint untuk mencatat chunk yang telah selesai. Jika terjadi failover, pekerjaan melanjutkan membaca dari chunk pertama yang belum selesai. Setelah semua chunk dibaca, pekerjaan beralih ke membaca perubahan inkremental dari posisi log biner yang sebelumnya dicatat. Pekerjaan Flink melakukan checkpoint berkala untuk menyimpan posisi log biner. Jika terjadi failover, pekerjaan melanjutkan pemrosesan dari posisi terakhir yang disimpan, sehingga mencapai semantik tepat-sekali.
Untuk detail lebih lanjut tentang algoritma snapshot inkremental, lihat Konektor CDC MySQL.
Untuk tabel dengan primary key kolom tunggal, chunk dibagi berdasarkan kunci tersebut secara default. Untuk tabel dengan primary key gabungan, kolom pertama dari primary key digunakan untuk pemisahan secara default. Ververica Runtime (VVR) 6.0.7 dan versi yang lebih baru mendukung pembacaan tabel sumber tanpa primary key. Anda harus mengatur parameter scan.incremental.snapshot.chunk.key-column untuk menentukan kolom non-null untuk pemisahan.
Optimasi parameter chunk
Data dan metadata chunk disimpan dalam memori, yang kadang-kadang dapat menyebabkan error kehabisan memori (OOM). Anda dapat menyesuaikan parameter berdasarkan komponen mana yang mengalami error OOM:
-
JobManager
JobManager menyimpan metadata untuk semua chunk. Jumlah chunk yang berlebihan dapat menyebabkan error OOM. Untuk mengatasi hal ini, tingkatkan nilai
scan.incremental.snapshot.chunk.sizeuntuk mengurangi jumlah chunk. Atau, Anda dapat meningkatkan memori heap JobManager dengan mengaturjobmanager.memory.heap.sizedalam konfigurasi runtime Anda. Untuk informasi lebih lanjut, lihat Konfigurasi Parameter Flink. -
TaskManager
-
TaskManager membaca data untuk setiap chunk. Jika chunk berisi terlalu banyak baris, error OOM dapat terjadi. Untuk mengatasi hal ini, kurangi nilai
scan.incremental.snapshot.chunk.sizeuntuk mengurangi jumlah baris per chunk. Anda juga dapat meningkatkan memori heap TaskManager dengan meningkatkan nilaiMemori TaskManagerdalam konfigurasi runtime Anda. -
Di VVR 8.0.8 dan versi sebelumnya, chunk terakhir mungkin berisi sejumlah besar data, yang dapat menyebabkan TaskManager mengalami error OOM. Kami menyarankan untuk meningkatkan ke VVR 8.0.9 atau versi yang lebih baru untuk menghindari masalah ini.
-
Untuk tabel sumber CDC MySQL dengan primary key gabungan, chunk dibagi berdasarkan kolom pertama kunci secara default. Jika data sangat miring, dengan banyak baris yang memiliki nilai yang sama dalam kolom tersebut, chunk untuk nilai tersebut dapat menjadi sangat besar dan menyebabkan error OOM di TaskManager. Anda dapat mengatur
scan.incremental.snapshot.chunk.key-columnuntuk menentukan kolom berbeda dari primary key untuk pemisahan.
-
Mempercepat pembacaan dalam fase snapshot
Selama fase snapshot, tabel sumber MySQL membaca data snapshot melalui koneksi JDBC. Gunakan metode berikut untuk mempercepat pembacaan selama fase ini.
-
Tingkatkan parallelisme sumber untuk mempercepat pembacaan selama fase snapshot.
-
Tingkatkan nilai
scan.incremental.snapshot.chunk.sizeuntuk mengambil lebih banyak data dalam satu chunk. -
Jika tabel hasil hilir memiliki primary key dan mendukung penulisan idempoten, Anda dapat mengaktifkan
scan.incremental.snapshot.backfill.skipuntuk melewati pembacaan log biner untuk bagian backfill. Hal ini mempercepat pemrosesan selama fase snapshot.
Aktifkan penggunaan ulang sumber untuk mengurangi koneksi binlog
Saat pekerjaan mencakup beberapa tabel sumber MySQL, Anda dapat mengaktifkan penggunaan ulang sumber untuk mengurangi beban database dengan berbagi satu koneksi log biner. Fitur ini hanya tersedia di Realtime Compute for Apache Flink dan tidak didukung di edisi komunitas konektor CDC MySQL.
Aktifkan fitur penggunaan ulang sumber dalam pekerjaan SQL dengan menggunakan perintah SET:
SET 'table.optimizer.source-merge.enabled' = 'true';
Kami menyarankan mengaktifkan penggunaan ulang sumber hanya untuk pekerjaan baru. Jika Anda mengaktifkan penggunaan ulang sumber untuk pekerjaan yang ada, Anda harus melakukan restart tanpa status. Hal ini karena penggunaan ulang sumber mengubah topologi pekerjaan, dan memulai dari status yang ada dapat menyebabkan pekerjaan gagal atau kehilangan data.
Setelah Anda mengaktifkan penggunaan ulang sumber, tabel sumber MySQL dengan parameter konfigurasi yang sama digabungkan. Jika semua tabel sumber dalam pekerjaan Anda memiliki konfigurasi yang sama, jumlah koneksi log biner dihitung sebagai berikut:
-
Selama fase snapshot, jumlah koneksi log biner sama dengan parallelisme sumber.
-
Selama fase inkremental, jumlah koneksi log biner adalah 1.
-
Di VVR 8.0.8 dan 8.0.9, Anda juga harus mengatur
SET 'sql-gateway.exec-plan.enabled' = 'false';saat mengaktifkan penggunaan ulang sumber CDC. -
Setelah mengaktifkan penggunaan ulang sumber CDC, jangan mengatur opsi pekerjaan
pipeline.operator-chainingke false. Memutus rantai operator menambahkan overhead serialisasi dan deserialisasi untuk data yang dikirim dari sumber ke operator hilir. Semakin banyak sumber yang digabungkan, semakin besar overhead-nya. -
Di Ververica Runtime (VVR) 8.0.7, mengatur
pipeline.operator-chainingke false menyebabkan masalah serialisasi.
Baca binlog arsip dari OSS
Saat Anda menggunakan instans ApsaraDB RDS for MySQL sebagai sumber data, Anda dapat membaca cadangan log yang disimpan di OSS. Jika file yang sesuai dengan timestamp atau posisi log biner yang ditentukan disimpan di OSS, Flink secara otomatis menarik file log dari OSS ke kluster. Jika file disimpan secara lokal di database, Flink secara otomatis beralih ke pembacaan melalui koneksi database. Fitur ini hanya tersedia di Realtime Compute for Apache Flink dan tidak didukung di edisi komunitas konektor CDC MySQL.
Untuk mengaktifkan pembacaan dari cadangan log OSS, Anda harus mengonfigurasi parameter koneksi ApsaraDB RDS for MySQL. Contoh:
CREATE TABLE mysql_source (...) WITH (
'connector' = 'mysql-cdc',
'rds.region-id' = 'cn-beijing',
'rds.access-key-id' = 'your_access_key_id',
'rds.access-key-secret' = 'your_access_key_secret',
'rds.db-instance-id' = 'rm-xxxxxxxx', // ID instans database.
'rds.main-db-id' = '12345678', // ID database utama.
'rds.endpoint' = 'rds.aliyuncs.com'
...
)
FAQ
Untuk informasi lebih lanjut tentang masalah yang mungkin Anda temui saat menggunakan tabel sumber CDC, lihat FAQ CDC.