FAQ tentang konektor CDC di Realtime Compute for Apache Flink, mencakup MySQL CDC, MongoDB CDC, dan PostgreSQL CDC.
Indeks cepat
Temukan masalah Anda berdasarkan gejala:
| Gejala | Bagian |
|---|---|
| Konektor berhenti setelah data penuh, tidak pernah beralih ke mode inkremental | MySQL CDC: transisi dari penuh ke inkremental |
| Data inkremental hilang untuk tabel tertentu | MySQL CDC: data inkremental tidak tersinkronisasi |
| Bidang timestamp menunjukkan offset 8 jam | MySQL CDC: offset timestamp |
| Beban database tinggi akibat beberapa penerapan CDC | MySQL CDC: beban DB tinggi |
| Bandwidth tiba-tiba tinggi meski pembaruan kecil | MySQL CDC: bandwidth tinggi |
| Penerapan gagal saat restart; binlog telah dipurge | Error: binlog tidak tersedia lagi |
| Penerapan gagal saat restart; error SSL | Error: SSL peer shut down |
| Log WAL tidak dilepas; penggunaan disk tinggi | PostgreSQL CDC: penggunaan disk WAL |
| Data TOAST hilang dari pembaruan | PostgreSQL CDC: data TOAST hilang |
| Konektor MongoDB tidak dapat melanjutkan setelah restart | MongoDB CDC: melanjutkan dari checkpoint |
| Autentikasi gagal meskipun kredensial benar | MongoDB CDC: kegagalan autentikasi |
| Slot replikasi masih aktif setelah penerapan berakhir | Error: slot replikasi aktif |
before bernilai null pada event UPDATE/DELETE |
Kesalahan: bidang null sebelumnya |
Umum
Bisakah saya mengonfigurasi penerapan agar dibatalkan alih-alih direstart saat terjadi kegagalan?
Tetapkan strategi restart dalam konfigurasi penerapan. Contoh berikut membatasi jumlah restart menjadi dua kali dengan interval 10 detik, lalu membatalkan penerapan jika kedua upaya tersebut gagal.
restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 2
restart-strategy.fixed-delay.delay: 10 s
Tabel sumber MySQL CDC dan Hologres CDC tidak mendukung fungsi jendela. Bagaimana cara menerapkan agregasi tingkat menit?
Gunakan DATE_FORMAT untuk mengonversi timestamp menjadi string tingkat menit, lalu lakukan GROUP BY berdasarkan string tersebut. Contoh berikut menghitung jumlah pesanan dan pendapatan per toko setiap menit:
SELECT
shop_id,
DATE_FORMAT(order_ts, 'yyyy-MM-dd HH:mm') AS window,
COUNT(*) AS order_count,
SUM(price) AS amount
FROM order_mysql_cdc
GROUP BY shop_id, window
Bisakah tabel MySQL CDC digunakan sebagai tabel dimensi atau tabel sink?
Tidak. Tabel MySQL CDC hanya dapat digunakan sebagai tabel sumber — ia membaca data penuh dan inkremental dari MySQL. Gunakan tabel MySQL biasa (bukan CDC) untuk kasus penggunaan dimensi atau sink.
MySQL CDC
Mengapa konektor MySQL CDC berhenti setelah membaca data penuh dan tidak pernah beralih ke mode inkremental?
Hal ini biasanya disebabkan oleh salah satu dari empat hal berikut:
-
Instans ApsaraDB RDS for MySQL V5.6 secondary atau read-only: Instans ini tidak menulis data ke file binary log, sehingga konektor tidak memiliki data inkremental untuk dibaca. Gunakan instans yang mendukung penulisan atau upgrade ke versi di atas V5.6.
-
Kompresi transaksi binary log diaktifkan: Tabel sumber MySQL CDC tidak mendukung kompresi transaksi binary log. Nonaktifkan fitur ini pada kluster MySQL yang dikelola sendiri.
-
Out-of-memory (OOM) selama pembacaan data penuh: Jika shard terakhir terlalu besar, error OOM menyebabkan penerapan ditangguhkan setelah failover. Tingkatkan parallelism untuk mempercepat pembacaan data penuh.
-
Interval checkpoint terlalu panjang: Setelah semua subtugas paralel selesai membaca data penuh, konektor menunggu satu checkpoint sebelum beralih ke mode inkremental. Interval checkpoint 20 menit berarti penundaan 20 menit. Tetapkan interval checkpointing yang lebih pendek sesuai kebutuhan Anda.
Bagaimana cara memastikan bahwa sinkronisasi data penuh telah selesai?
Dua metode:
-
Metrik `currentEmitEventTimeLag`: Di tab Metrics pada halaman Deployments, periksa metrik ini. Nilai ≤ 0 berarti sinkronisasi penuh masih berlangsung; nilai > 0 berarti konektor telah selesai melakukan sinkronisasi penuh dan mulai membaca data binary log.

-
Log TaskManager: Cari
BinlogSplitReader is createddalam log TaskManager. Pesan ini mengonfirmasi bahwa pembacaan data penuh telah selesai.4123 2022-01-12 05:12:52,157 [pool-6757-thread-1] INFO io.debezium.jdbc.JdbcConnection [] - Connection gracefully close... 4124 2022-01-12 05:12:52,158 [Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO org.apache.flink.connector.base.source.reader.SourceReaderBase [] - Adding split(s) to reader: [MySqlBinlogSplit{splitId='binlog-split', offset={ts_sec=0, file=mysql-bin.008066, pos=459422339, gtids=c32c3579-5c0d-11ec-889a-00163e368abf:1-311125098, row=0, event=0}, endOffset={ts_sec=0, file=, pos=-9223372036854775808, row=0, event=0}}] 4125 2022-01-12 05:12:52,158 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher [] - Starting split fetcher_138? 4126 2022-01-12 05:12:52,159 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] INFO com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader [] - BinlogSplitReader is created. 4127 2022-01-12 05:12:56,853 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with job vertex id 6698b6cdb93164bb0e3bb97f2a17fcd7 (1/4)#0] WARN io.debezium.relational.history.DatabaseHistoryMetrics [] - Unable to register the MBean 'debezium.mysql:type=connector-metrics,context=schema-history,server=mysql_binlog_source': debezium.mysql:type=connector-metrics, context=schema-history,server=mysql_binlog_source 4128 2022-01-12 05:12:56,860 [Source Data Fetcher for Source: TableSourceScan(table=[[vvp, default, ods_ex_trade_detail_spot_mysql_cdc ... with jobBaris 4126 menunjukkan
BinlogSplitReader is created, yang mengindikasikan bahwa pembacaan data penuh telah selesai dan penerapan telah memasuki fase pembacaan binary log inkremental. Log WARN pada baris 4127 (Unable to register the MBean) bersifat normal dan tidak memengaruhi sinkronisasi data.
Apakah posisi awal berubah saat saya me-restart penerapan?
Hal ini bergantung pada Starting Strategy yang Anda pilih di kotak dialog Deployment Starting Configuration:
-
NONE: Konektor membaca ulang dari posisi awal yang dikonfigurasi.
-
Latest State: Konektor melanjutkan dari posisi binary log tempat penerapan terakhir dibatalkan.
Sebagai contoh, jika penerapan dikonfigurasi untuk memulai dari {file=mysql-bin.01, position=40} tetapi dibatalkan pada posisi 210, maka Latest State akan melanjutkan dari 210 dan NONE akan memulai ulang dari 40.
Pastikan file binary log yang diperlukan masih ada di server sebelum melakukan restart. Jika file tersebut telah kedaluwarsa dan dihapus, proses restart akan gagal.
Bagaimana cara kerja konektor MySQL CDC, dan bagaimana dampaknya terhadap database?
Saat scan.startup.mode diatur ke initial (nilai default), konektor:
-
Terhubung melalui JDBC dan menjalankan pernyataan
SELECTuntuk membaca data penuh, serta mencatat posisi binary log saat ini. -
Setelah selesai membaca data penuh, beralih ke klien binlog untuk membaca perubahan inkremental dari posisi yang telah dicatat.
Pembacaan data penuh meningkatkan beban kueri karena pernyataan SELECT. Selama pembacaan inkremental, setiap tabel sumber mempertahankan satu koneksi binlog. Jika Anda memiliki banyak tabel sumber, periksa batas koneksi:
show variables like '%max_connections%';
Bagaimana cara melewati fase snapshot dan hanya membaca data perubahan?
Tetapkan scan.startup.mode dalam klausa WITH ke salah satu nilai berikut: earliest-offset, latest-offset, specific-offset, atau timestamp. Untuk detailnya, lihat bagian "Parameter dalam klausa WITH" di Membuat tabel sumber MySQL CDC.
Bagaimana MySQL CDC menentukan posisi binlog saat scan.startup.mode = timestamp?
Dengan mode startup timestamp, MySQL CDC menentukan posisi konsumsi awal sebagai berikut:
-
Memindai semua file binlog dan menemukan file pertama yang waktu modifikasi terakhirnya lebih besar atau sama dengan timestamp yang ditentukan.
-
Membaca event binlog dari awal file tersebut.
-
Melewatkan event yang timestamp-nya lebih awal dari timestamp yang ditentukan.
-
Memulai konsumsi dari event pertama yang timestamp-nya lebih besar atau sama dengan timestamp yang ditentukan.
Kasus batas:
-
Jika timestamp yang ditentukan berada di masa depan, konsumsi dimulai dari posisi terbaru yang tersedia, setara dengan
latest-offset. -
Jika binlog yang sesuai dengan timestamp yang ditentukan telah dipurge, konsumsi dimulai dari posisi paling awal yang tersedia, setara dengan
earliest-offset.
Bagaimana konektor menangani tabel MySQL yang di-shard?
Gunakan parameter table-name dengan ekspresi reguler untuk mencocokkan semua shard. Misalnya, untuk memantau semua tabel dengan awalan user_:
'table-name' = 'user_.*'
Jika semua tabel di seluruh shard memiliki skema yang sama, gunakan database-name dengan regex sebagai gantinya.
Apa yang harus saya lakukan jika koma dalam regex table-name menyebabkan error parsing?
Debezium menggunakan koma sebagai pembatas, sehingga pola seperti t_process_wi_history_\d{1,2} gagal.
13-vvr-4.0.13-1-SNAPSHOT.jar:1.13-vvr-4.0.13-1-SNAPSHOT]
Caused by: java.util.regex.PatternSyntaxException: Unclosed counted closure near index 35
zhangtest.t_process_wi_history_\d{1
at java.util.regex.Pattern.error(Pattern.java:1969) ~[?:1.8.0_302]
at java.util.regex.Pattern.closure(Pattern.java:3155) ~[?:1.8.0_302]
Gunakan alternasi sebagai gantinya:
'table-name' = '(t_process_wi_history_\d{1}|t_process_wi_history_\d{2})'
Beberapa penerapan MySQL CDC menyebabkan beban database tinggi. Apa yang bisa saya lakukan?
Dua pendekatan:
-
Alihkan ke Kafka: Sinkronkan tabel sumber MySQL CDC ke tabel sink ApsaraMQ for Kafka. Penerapan lain kemudian mengonsumsi dari Kafka alih-alih membaca binary log secara langsung. Lihat Sinkronkan data dari semua tabel dalam database MySQL ke Kafka.
-
Gabungkan penerapan dengan server ID yang sama: Jika beberapa penerapan
CREATE TABLE ASmemiliki konfigurasi yang sama, tetapkan server ID yang sama untuk menggunakan kembali sumber data. Lihat Contoh 4: eksekusi beberapa pernyataan CREATE TABLE AS.
Pembaruan kecil menyebabkan penggunaan bandwidth yang tidak biasa tinggi. Mengapa?
File binary log berisi perubahan untuk semua database dan tabel dalam instans MySQL — bukan hanya yang dipantau oleh penerapan Anda. Jika instans Anda memiliki tiga tabel, binary log membawa perubahan dari ketiganya meskipun penerapan Anda hanya melacak satu.
Perbaiki hal ini dengan menggunakan kembali tabel sumber MySQL CDC sehingga beberapa penerapan berbagi satu koneksi binlog. Lihat bagian "Pengaktifan penggunaan kembali tabel sumber MySQL CDC" di Konektor MySQL.
Bidang timestamp menunjukkan offset 8 jam dibandingkan zona waktu server MySQL. Mengapa?
Dua kemungkinan penyebab:
-
Parameter
server-time-zonedalam penerapan CDC tidak sesuai dengan zona waktu aktual server MySQL. Perbaruiserver-time-zoneagar sesuai. -
Deserialisasi kustom (
MyDeserializer implements DebeziumDeserializationSchema) tidak mengaturserverTimeZone. AturserverTimeZoneberdasarkan caraRowDataDebeziumDeserializeSchemamengurai dataTIMESTAMP:private TimestampData convertToTimestamp(Object dbzObj, Schema schema) { if (dbzObj instanceof Long) { switch (schema.name()) { case Timestamp.SCHEMA_NAME: return TimestampData.fromEpochMillis((Long) dbzObj); case MicroTimestamp.SCHEMA_NAME: long micro = (long) dbzObj; return TimestampData.fromEpochMillis(micro / 1000, (int) (micro % 1000 * 1000)); case NanoTimestamp.SCHEMA_NAME: long nano = (long) dbzObj; return TimestampData.fromEpochMillis(nano / 1000_000, (int) (nano % 1000_000)); } } LocalDateTime localDateTime = TemporalConversions.toLocalDateTime(dbzObj, serverTimeZone); return TimestampData.fromLocalDateTime(localDateTime); }
Bisakah konektor MySQL CDC mendengarkan database sekunder?
Ya. Tambahkan konfigurasi berikut ke database sekunder agar data yang disinkronkan dari primary ditulis ke binary log sekunder:
log-slave-updates = 1
Jika mode Global Transaction Identifier (GTID) diaktifkan di primary, aktifkan juga di sekunder:
gtid_mode = on
enforce_gtid_consistency = on
Bagaimana cara menangkap event DDL?
Gunakan API DataStream dengan MySqlSource dan atur includeSchemaChanges(true):
MySqlSource<xxx> mySqlSource =
MySqlSource.<xxx>builder()
.hostname(...)
.port(...)
.databaseList("<databaseName>")
.tableList("<databaseName>.<tableName>")
.username(...)
.password(...)
.serverId(...)
.deserializer(...)
.includeSchemaChanges(true) // Tangkap event DDL
.build();
// Tambahkan logika pemrosesan downstream
Apakah MySQL CDC mendukung sinkronisasi semua tabel dalam sebuah database sekaligus?
Ya. Gunakan pernyataan CREATE TABLE AS atau CREATE DATABASE AS. Lihat Pernyataan CREATE TABLE AS atau Pernyataan CREATE DATABASE AS.
Instans ApsaraDB RDS for MySQL V5.6 tidak menulis perubahan inkremental ke file binary log, sehingga konektor tidak dapat membaca data inkremental dari instans tersebut.
Data inkremental dari tabel tertentu tidak tersinkronisasi. Mengapa?
Filter binary log di server MySQL mungkin mengecualikan database tersebut. Jalankan perintah berikut untuk memeriksa:
show master status;
Periksa kolom Binlog_Ignore_DB dan Binlog_Do_DB dalam output:
+------------------+----------+--------------+------------------+----------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------+
| mysql-bin.000006 | 4594 | | | xxx:1-15 |
+------------------+----------+--------------+------------------+----------------------+
Bagaimana cara mengonfigurasi tableList saat menggunakan API DataStream untuk MySQL CDC?
Nilai tableList harus mencakup nama database dan nama tabel, dalam format yourDatabaseName.yourTableName.
MongoDB CDC
Bisakah konektor melanjutkan dari checkpoint jika penerapan gagal selama pembacaan data penuh?
Ya. Tetapkan 'scan.incremental.snapshot.enabled' = 'true' dalam klausa WITH untuk mengaktifkan pemulihan berbasis checkpoint selama pembacaan data penuh.
Apakah MongoDB CDC mendukung pembacaan data inkremental saja?
Secara default, konektor membaca data penuh dan inkremental. Untuk melewati data penuh dan hanya membaca perubahan inkremental, atur 'scan.startup.mode' = 'latest-offset' dalam klausa WITH.
Bisakah saya berlangganan hanya koleksi tertentu?
Tidak. Konektor berlangganan pada tingkat database. Tetapkan 'database' = 'mgdb' dan 'collection' = '' dalam klausa WITH untuk berlangganan semua koleksi dalam database.
Apakah MongoDB CDC mendukung pembacaan konkuren?
Ya, selama fase snapshot awal. Tetapkan scan.incremental.snapshot.enabled ke true untuk mengaktifkan pembacaan konkuren.
Versi MongoDB apa saja yang didukung?
MongoDB 3.6 dan yang lebih baru (change streams diperkenalkan di 3.6). MongoDB 4.0 atau yang lebih baru direkomendasikan. Pada versi sebelum 3.6, konektor mengembalikan error "Unrecognized pipeline stage name: '$changeStream'".
Arsitektur MongoDB apa saja yang didukung?
Konektor memerlukan replica set atau kluster sharded — change streams hanya berfungsi dalam mode ini. Untuk pengujian lokal, ubah MongoDB menjadi replica set satu node menggunakan rs.initiate(). Tanpa ini, konektor mengembalikan "The $changestage is only supported on replica sets".
Apakah MongoDB CDC mendukung parameter Debezium?
Tidak. Konektor MongoDB CDC dikembangkan secara independen dalam Flink CDC dan tidak bergantung pada Debezium.
Autentikasi gagal meskipun kredensial benar. Mengapa?
Kredensial pengguna dibatasi pada database tertentu. Tambahkan 'connection.options' = 'authSource=<database_the_user_belongs_to>' ke klausa WITH.
Bisakah konektor melanjutkan dari checkpoint setelah penerapan di-restart?
Ya. Checkpoint menyimpan token resume untuk change streams. Saat penerapan di-restart, konektor membaca token resume dan melanjutkan dari posisi yang sesuai dalam koleksi oplog.rs.
Jika token resume tidak lagi ada di oplog.rs — koleksi berkapasitas tetap yang berputar saat penuh — tingkatkan ukuran oplog untuk mencegah rotasi prematur. Lihat Ubah Ukuran Oplog Anggota Replica Set yang Dikelola Sendiri.
Apakah MongoDB CDC mendukung pesan UPDATE_BEFORE (gambar sebelum pembaruan)?
Hal ini bergantung pada versi MongoDB:
-
MongoDB 6.0 dan yang lebih baru dengan pre-image/post-image diaktifkan: Tetapkan
'scan.full-changelog' = 'true'.MongoDBSourcemenghasilkan pesanUPDATE_BEFOREsecara langsung. -
MongoDB sebelum 6.0: Koleksi
oplog.rsmencakup tipeINSERT,UPDATE,REPLACE, danDELETEtetapi tidakUPDATE_BEFORE. Saat menggunakanMongoDBTableSourcedengan mode SQL, planner Flink secara otomatis menerapkan operatorChangelogNormalizeuntuk menghasilkan pesanUPDATE_BEFORE— tetapi operator ini menyimpan semua state kunci dan menambahkan overhead. Jika Anda menggunakan API DataStream denganMongoDBSource(tanpa optimasi planner Flink),ChangelogNormalizetidak diterapkan secara otomatis. Anda dapat mengelola state sendiri, atau gunakanMongoDBTableSourcedan konversi ke aliran changelog:tEnv.executeSql("CREATE TABLE orders ( ... ) WITH ( 'connector'='mongodb-cdc', ... )"); Table table = tEnv.from("orders").select($("*")); tEnv.toChangelogStream(table) .print() .setParallelism(1); env.execute();
PostgreSQL CDC
Bagaimana cara menyaring nilai tanggal yang tidak valid?
Tambahkan salah satu berikut ke klausa WITH:
-
'debezium.event.deserialization.failure.handling.mode' = 'warn': Lewati catatan yang tidak valid dan catat sebagai peringatan. -
'debezium.event.deserialization.failure.handling.mode' = 'ignore': Lewati catatan yang tidak valid tanpa pemberitahuan.
Data TOAST hilang dari pembaruan. Mengapa?
Perilaku ini bergantung pada pengaturan REPLICA IDENTITY tabel:
-
`REPLICA IDENTITY FULL`: Nilai kolom TOAST muncul di bidang
beforedanafterpada event perubahan, sama seperti kolom lainnya. -
`REPLICA IDENTITY DEFAULT` (default): Kolom TOAST yang tidak berubah dihilangkan dari event
UPDATE. Saat menggunakan'debezium.schema.refresh.mode' = 'columns_diff_exclude_unchanged_toast', pluginwal2jsonmenghilangkan data TOAST yang tidak berubah — sehingga kolom tersebut hanya muncul di log WAL saat identitas replika adalahFULL.
Untuk memperbaiki data TOAST yang hilang, atur identitas replika ke FULL:
ALTER TABLE your_table_name REPLICA IDENTITY FULL;
Log WAL tidak dilepas dan penggunaan disk tinggi. Mengapa?
Konektor PostgreSQL CDC hanya memperbarui nomor urutan log (LSN) di slot replikasi saat checkpoint Flink selesai. Jika penggunaan disk tinggi, periksa:
-
Apakah checkpoint diaktifkan untuk penerapan.
-
Apakah ada slot replikasi yang tidak digunakan atau memiliki lag sinkronisasi besar.
Apa yang terjadi saat presisi DECIMAL melebihi presisi kolom yang dideklarasikan?
Nilainya dikembalikan sebagai null. Untuk mempertahankan nilai aslinya, atur 'debezium.decimal.handling.mode' = 'string' agar data DECIMAL dibaca sebagai string.
Bagaimana cara mengonfigurasi tableList saat menggunakan API DataStream untuk PostgreSQL CDC?
Nilai tableList harus mencakup nama skema dan nama tabel, dalam format my_schema.my_table.
Paket dan dependensi
Mengapa saya tidak bisa mengunduh flink-sql-connector-mysql-cdc-2.2-SNAPSHOT.jar?
Versi SNAPSHOT sesuai dengan cabang pengembangan dan tidak dipublikasikan ke repositori Maven central. Kompilasi dari kode sumber untuk menggunakan versi SNAPSHOT, atau gunakan rilis stabil seperti flink-sql-connector-mysql-cdc-2.1.0.jar, yang tersedia di repositori Maven central.
Apa perbedaan antara flink-sql-connector-xxx.jar dan flink-connector-xxx.jar?
-
`flink-sql-connector-xxx`: JAR fat yang mencakup kode konektor dan semua dependensi yang di-shade. Tambahkan ke direktori
libuntuk penerapan SQL. -
`flink-connector-xxx`: Hanya berisi kode konektor, tanpa dependensi. Gunakan untuk penerapan DataStream dan kelola dependensi pihak ketiga sendiri, termasuk menyelesaikan konflik dengan operasi
excludedanshade.
Mengapa saya tidak dapat menemukan paket konektor Flink CDC 2.x di repositori Maven?
Mulai dari Flink CDC 2.0.0, group ID berubah dari com.alibaba.ververica menjadi com.ververica. Jalur Maven untuk paket 2.x adalah /com/ververica/.
Bidang numerik dikembalikan sebagai string saat menggunakan JsonDebeziumDeserializationSchema. Bagaimana cara memperbaikinya?
Konfigurasikan properti penanganan numerik Debezium saat membuat sumber:
Properties properties = new Properties();
properties.setProperty("bigint.unsigned.handling.mode", "long");
properties.setProperty("decimal.handling.mode", "double");
MySqlSource.<String>builder()
.hostname(config.getHostname())
// ...
.debeziumProperties(properties);
Untuk detail tentang cara Debezium mengonversi tipe numerik, lihat Konektor Debezium untuk MySQL.
Pesan error
"Replication slot 'xxxx' is active"
Setelah penerapan PostgreSQL CDC berakhir, slot replikasinya mungkin tidak dilepas secara otomatis. Lepaskan secara manual:
select pg_drop_replication_slot('rep_slot');
Jika slot dipegang oleh proses aktif, hentikan proses tersebut terlebih dahulu:
select pg_terminate_backend(162564);
select pg_drop_replication_slot('rep_slot');
Atau, tambahkan 'debezium.slot.drop.on.stop' = 'true' ke konfigurasi sumber PostgreSQL agar slot dihapus otomatis saat penerapan dibatalkan.
Mengaktifkan pembersihan slot otomatis menyebabkan log WAL diklaim kembali. Saat penerapan di-restart, data hilang dan semantik at-least-once tidak dapat dijamin.
"binlog probably contains events generated with statement or mixed based replication format"
Tabel sumber MySQL CDC hanya mendukung binary log dalam format ROW. Jika formatnya STATEMENT atau MIXED, konektor gagal.
-
Periksa format saat ini:
show variables like "binlog_format"; -- Untuk memeriksa pengaturan global: show global variables like "binlog_format"; -
Ubah format ke ROW. Lihat Menyetel format binary log.
-
Restart penerapan.
"Encountered change event for table xxx.xxx whose schema isn't known to this connector"
Tiga penyebab umum:
-
Izin tidak mencukupi: Akun tidak memiliki akses ke semua database yang digunakan dalam penerapan. Berikan izin yang diperlukan. Lihat Mengonfigurasi database MySQL.
-
`debezium.snapshot.mode` diatur ke `never`: Membaca dari awal binary log berarti skema tabel yang tercatat di sana mungkin tidak sesuai dengan skema saat ini. Hindari pengaturan ini. Untuk mentolerir ketidaksesuaian skema, tambahkan
'debezium.inconsistent.schema.handling.mode' = 'warn'. -
Sintaks DDL tidak didukung: Debezium tidak dapat menginterpretasikan ekspresi tertentu seperti
DEFAULT (now()). Periksa log WARNio.debezium.connector.mysql.MySqlSchemauntuk mengidentifikasi pernyataan bermasalah.
"The connector is trying to read binlog starting at GTIDs ..., but this is no longer available on the server"
File binary log yang dibutuhkan konektor telah dihapus. Penyebab umum dan solusinya:
<table> <thead> <tr> <th><b>Penyebab</b></th> <th><b>Solusi</b></th> </tr> </thead> <tbody> <tr> <td>Periode retensi binary log terlalu singkat</td> <td>Tingkatkan periode retensi, misalnya menjadi 7 hari: <code>set global expire_logs_days=7;</code></td> </tr> <tr> <td>Penerapan mengonsumsi binlog terlalu lambat (tekanan balik pada operator downstream)</td> <td>Optimalkan konfigurasi resource untuk mengurangi tekanan balik</td> </tr> <tr> <td>ApsaraDB RDS for MySQL: log disimpan maksimal 18 jam dan hingga 30% dari kapasitas penyimpanan</td> <td>Sesuaikan kebijakan kedaluwarsa binary log untuk RDS</td> </tr> <tr> <td>Instans ApsaraDB RDS for MySQL read-only: binlog lokal disimpan minimal 10 detik sebelum diunggah ke Object Storage Service (OSS)</td> <td>Hindari penggunaan instans read-only (hostname diawali <code>rr</code>) untuk CDC; gunakan instans biasa (hostname diawali <code>rm</code>)</td> </tr> <tr> <td>Migrasi data internal pada instans RDS</td> <td>Restart penerapan untuk membaca ulang data</td> </tr> </tbody> </table>
"EventDataDeserializationException: Failed to deserialize data of EventHeaderV4"
Server MySQL menutup koneksi binlog yang idle. Parameter net_write_timeout mengontrol timeout ini (default: 60 detik). Koneksi yang tidak aktif karena tekanan balik atau masalah jaringan akan terputus.
-
Tambahkan
'debezium.connect.keep.alive.interval.ms' = '40000'ke konfigurasi tabel sumber MySQL CDC, atau tingkatkannet_write_timeoutdi database. Lihat Optimalkan parameter instans. -
Jika error disebabkan oleh tekanan balik, sesuaikan konfigurasi resource penerapan.
-
Ververica Runtime (VVR) 8.0.7 dan yang lebih baru secara otomatis mencoba ulang saat terjadi error akibat tekanan balik.
"The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs"
Pembacaan data penuh memakan waktu sangat lama sehingga posisi GTID yang dicatat di awal sinkronisasi penuh telah dihapus dari server saat konektor beralih ke pembacaan inkremental.
Tingkatkan periode retensi binary log atau ukuran file maksimum:
mysql> show variables like 'expire_logs_days';
mysql> set global expire_logs_days=7;
"Bidang 'before' pada pesan UPDATE/DELETE bernilai null"
REPLICA IDENTITY tabel PostgreSQL tidak diatur ke FULL. Jalankan:
ALTER TABLE yourTableName REPLICA IDENTITY FULL;
Jika error tetap muncul setelah penerapan di-restart, tambahkan pernyataan tersebut ke kode penerapan.
"Can't find any matched tables, please check your configured database-name and table-name"
Dua kemungkinan penyebab:
-
Nama tabel tidak ada di database. Verifikasi nama tabel yang dikonfigurasi.
-
Akun tidak memiliki izin pada database tertentu dalam penerapan. Berikan izin yang diperlukan untuk semua database.
"Primary key diperlukan saat mengaktifkan 'scan.incremental.snapshot.enabled'"
Error ini terjadi di VVR 4.0.x saat tabel sumber MySQL CDC dibuat tanpa primary key dalam klausa DDL WITH. Tambahkan definisi primary key ke pernyataan DDL.
"java.io.EOFException: SSL peer shut down incorrectly" {#javaioeofe-xception-ssl-peer-shut-down-incorrectly}
MySQL 8.0.27 mengaktifkan koneksi SSL secara default, tetapi driver JDBC tidak dapat terhubung melalui SSL dengan konfigurasi default.
Jika menggunakan VVR 6.0.2 atau yang lebih baru, tambahkan
'jdbc.properties.useSSL' = 'false'ke klausaWITH.Jika tabel hanya digunakan sebagai tabel dimensi, atur konektor ke
rdsdan tambahkancharacterEncoding=utf-8&useSSL=falseke URL:'url' = 'jdbc:mysql://***.***.***.***:3306/test?characterEncoding=utf-8&useSSL=false'
"A slave with the same server_uuid/server_id as this slave has connected to the master"
Setiap subtugas paralel tabel sumber MySQL CDC harus memiliki server ID unik. Jika subtugas paralel dalam penerapan yang sama — atau lintas beberapa penerapan — menggunakan server ID yang sama, error ini terjadi.
Tentukan server ID yang unik secara global untuk setiap subtugas paralel. Untuk detailnya, lihat bagian "Peringatan" di Membuat tabel sumber MySQL CDC.
"NullPointerException" setelah menambahkan kolom selama pembacaan data penuh
Penerapan mencatat skema tabel saat startup dan menyimpannya di checkpoint. Menambahkan kolom saat pembacaan data penuh sedang berlangsung menyebabkan ketidaksesuaian skema, yang memicu NullPointerException.
Batalkan penerapan, hapus tabel downstream, dan restart penerapan tanpa state.
"Mysql8.0 Public Key Retrieval is not allowed"
Pengguna MySQL dikonfigurasi dengan autentikasi kata sandi SHA256, yang memerlukan TLS. Ubah pengguna ke autentikasi kata sandi native:
ALTER USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
FLUSH PRIVILEGES;"sub account not auth permission"
Saat menggunakan ApsaraDB RDS for MySQL sebagai sumber CDC, Pengguna RAM tidak memiliki izin untuk mengunduh file binary log dari Object Storage Service (OSS). Berikan izin yang diperlukan. Lihat Memberikan izin kepada Pengguna RAM untuk mengunduh file backup dengan izin read-only.
"DELETE command denied to user 'userName'@'\*.\*.\*.\*' for table 'table_name'"
Saat klausa WHERE menyaring aliran data CDC, Realtime Compute for Apache Flink mengeluarkan catatan BEFORE UPDATE dan AFTER UPDATE untuk setiap operasi UPDATE. Sink downstream memperlakukan catatan BEFORE UPDATE sebagai DELETE. Berikan izin DELETE kepada pengguna database yang melakukan operasi pada tabel hasil.