Temu Duga Kejuruteraan Data: Mereka Bentuk Paip Tangkapan Data Perubahan (CDC)

Masalah dan Skop

Sebuah syarikat mempunyai 20 pangkalan data OLTP PostgreSQL, 200 jadual untuk diselaraskan, dan 8 TB data semasa. Sumber-sumber ini menghasilkan purata 20,000 perubahan baris terkomit sesaat dan 60,000 pada waktu puncak. Perubahan yang dikodkan adalah kira-kira 1 KB secara purata. Data mesti sampai ke gudang data analitik atau lakehouse, dengan kependaman p99 dari komit transaksi sumber hingga data terurus (curated) boleh ditanya di bawah dua minit. Penyelarasan awal mesti selesai dalam tempoh 72 jam tanpa menghentikan penulisan aplikasi, dan beban kerja snapshot berserta CDC mesti menyebabkan regresi p99 penulisan sumber kurang daripada 5%.

Paip ini mesti mengendalikan insert, update, delete, dan perubahan nilai kunci utama (primary key). Ia mesti mengekalkan susunan perubahan bagi sesuatu baris dalam satu sumber, menggunakan penghantaran sekurang-kurangnya sekali (at-least-once), menyokong evolusi skema dan main semula mengikut jadual atau julat kunci utama, pulih daripada kegagalan sumber dan sinki (sink), serta menyediakan penyesuaian yang dapat membuktikan ketepatan. Strim perubahan tahan lasak (durable) mengekalkan peristiwa mentah selama tujuh hari, manakala storan objek berkos lebih rendah menyimpan sejarah yang lebih panjang. Bilangan pangkalan data, daya pemprosesan (throughput), saiz, kependaman, dan had sumber adalah andaian temu duga, bukan jaminan prestasi untuk produk sebenar.

Walaupun reka bentuk ini mengandungi broker dan pelbagai komponen, kemahiran terasnya adalah kejuruteraan data: menggabungkan snapshot tersimpan kepada strim perubahan tanpa batas tanpa lompang (gap), mentakrifkan kedudukan boleh pulih dan sempadan kedap kuasa (idempotency), serta membuktikan bahawa destinasi tidak kehilangan data atau salah secara senyap.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah mentakrifkan ketepatan sebelum melukis komponen. Jawapan yang lemah bermula dengan "Debezium ditambah Kafka." Jawapan yang kukuh menyatakan invarian: perubahan yang telah dikomit tidak boleh hilang, satu baris mesti menumpu mengikut susunan sumber, peristiwa yang dimainkan semula tidak boleh mengubah keadaan akhir, pemadaman mesti sampai ke sasaran, sempadan snapshot-ke-strim tidak boleh mempunyai lompang, dan kedudukan pemulihan yang tidak pasti mesti gagal-tutup (fail closed) dan bukannya meneruskan secara senyap.

Isyarat kedua ialah memahami bahawa snapshot awal bukanlah "eksport semua jadual, kemudian aktifkan CDC." Operasi penulisan berterusan semasa eksport 8 TB. Jika penangkapan WAL hanya bermula selepas eksport, perubahan perantaraan mungkin telah hilang. Reka bentuk yang boleh dipercayai menetapkan kedudukan log boleh pulih dan mekanisme pengekalan sebelum atau semasa ia memperoleh snapshot yang konsisten, kemudian menstrim perubahan terkomit dari kedudukan yang sepadan. Penyambung (connector) boleh membungkus prosedur ini, tetapi calon masih perlu menjelaskan mengapa serahan tersebut tidak mempunyai lompang.

Isyarat ketiga ialah membawa penghantaran sekurang-kurangnya sekali merentasi sinki. Penyambung boleh ranap selepas memancarkan peristiwa secara tahan lasak tetapi sebelum merekodkan ofset sumbernya. Satu kelompok (batch) gudang data boleh dikomit sementara perakuannya (acknowledgement) hilang. "Tepat sekali (exactly once) dalam broker" tidak secara automatik merangkumi gudang data luaran. Jawapan yang kukuh melampirkan identiti sumber, kedudukan sumber, dan susunan transaksi pada setiap peristiwa, kemudian menggunakan peristiwa hanya apabila versinya lebih baharu daripada versi yang telah direkodkan untuk baris tersebut.

Isyarat keempat ialah mengenali risiko dua hala replication slot PostgreSQL. Slot membolehkan penyambung menyambung semula dari LSN, tetapi ia juga mengekalkan WAL semasa penyambung ketinggalan. Tanpa amaran bait dikekalkan dan ruang cakera, gangguan sinki akhirnya boleh memenuhi storan sumber. Jika slot digugurkan dan dicipta semula, slot baharu tidak dapat menghasilkan semula kedudukan lama. Paip mesti berhenti, menyesuaikan, atau mengambil snapshot semula dan bukannya meneruskan "dari sekarang" dan mendakwa tiada apa yang hilang.

Akhir sekali, jawapan mesti merangkumi semantik data sebenar. Peristiwa pemadaman perniagaan berbeza daripada tombstone yang digunakan untuk pemadatan log (log compaction). Perubahan nilai kunci utama biasanya muncul sebagai pemadaman untuk kunci lama dan penciptaan untuk kunci baharu. LSN daripada pangkalan data berasingan tidak boleh dibandingkan. Jika pengguna memerlukan keterlihatan atomik untuk setiap baris dalam transaksi berbilang baris, reka bentuk mesti menggunakan metadata sempadan transaksi dan menerima penimbalan tambahan, kependaman, dan kerumitan pemulihan.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah destinasi memerlukan keadaan semasa, sejarah perubahan penuh, atau kedua-duanya? Keadaan semasa sesuai dengan operasi MERGE kunci utama. Audit dan main semula juga memerlukan lapisan perubahan mentah yang tidak boleh diubah (immutable). Keadaan akhir sahaja tidak dapat membina semula sejarah.
• Di manakah jam kependaman dua minit bermula dan berakhir? Masalah ini mengukur dari komit transaksi sumber hingga data terurus boleh ditanya. Keperluan yang berhenti apabila peristiwa mentah memasuki broker adalah jauh lebih mudah.
• Adakah transaksi berbilang jadual mesti kelihatan secara atomik? Pilihan lalai di sini ialah susunan mengikut baris dengan keterlihatan separa yang singkat dalam gudang data. Pengguna kewangan yang memerlukan keatomikan keseluruhan transaksi memerlukan pemasangan BEGIN/END.
• Adakah setiap jadual mempunyai kunci utama yang stabil? Tanpa kunci utama, mencari dan menyahduplikasi peristiwa UPDATE dan DELETE adalah lebih sukar. Tambah kunci perniagaan atau terima identiti baris penuh, kunci pengganti (surrogate keys), dan kos storan yang lebih tinggi secara eksplisit.
• Adakah failover sumber mengekalkan logical replication slot? Jika tidak, pemulihan memerlukan jeda penulisan terkawal, pengesahan LSN terakhir, penciptaan semula slot, dan penyesuaian. Failover utama tidak boleh dianggap sebagai penyambungan semula biasa.
• Perubahan skema manakah yang boleh diluluskan secara automatik? Reka bentuk ini secara automatik menerima perubahan yang serasi seperti penambahan lajur boleh-batal (nullable). Pengguguran, penamaan semula, pengecilan jenis jenis data, dan perubahan kunci utama menggunakan migrasi terkawal.
• Mana satukah yang lebih sukar, tarikh akhir snapshot 72 jam atau belanjawan sumber 5%? Membaca 8 TB dalam masa 72 jam memerlukan kira-kira 30.9 MB/s daya pemprosesan berkesan agregat. Jika ujian beban menunjukkan ini melanggar belanjawan sumber, lanjutkan tarikh akhir, gunakan replika yang sah secara semantik, atau kurangkan skop secara berfasa.
• Berapa lamakah strim dalam talian mesti menyerap gangguan destinasi? Reka bentuk ini menampung gangguan puncak selama 30 minit secara dalam talian. Strim tahan lasak tujuh hari dan arkib objek mengendalikan main semula yang lebih lama.

Jawapan 30 Saat

"Saya akan mentakrifkan ketepatan terlebih dahulu: snapshot dan strim tidak mempunyai lompang, sesuatu baris menumpu mengikut kedudukan sumber, main semula adalah selamat, pemadaman disebarkan, dan sejarah replication slot yang hilang akan gagal-tutup. Setiap sumber PostgreSQL menggunakan penyahkodan logikal ke atas WAL, mengambil snapshot yang konsisten, dan menyambung semula daripada LSN yang sepadan. Peristiwa dipisahkan (partitioned) mengikut sumber, jadual, dan kunci utama ke dalam strim tahan lasak. Lapisan mentah kekal tidak boleh diubah, manakala sinki terurus melakukan operasi MERGE yang kedap kuasa mengikut kunci utama dan versi sumber. Keserasian skema diperiksa sebelum penggunaan, dan pemadaman serta perubahan kunci dinyatakan secara eksplisit. Saya akan memantau kesegaran bersegmen, kelengahan LSN, WAL yang dikekalkan, kemajuan snapshot, dan perbezaan penyesuaian, kemudian menyuntik ranapan penyambung, kehilangan slot, perubahan skema, dan gangguan sinki."

Perincian Langkah demi Langkah

Langkah 1: Saizkan penimbal, snapshot, dan belanjawan pemulihan

Beban purata ialah:

20,000 events/s × 1 KB ≈ 20 MB/s
20,000 × 86,400 = 1,728,000,000 events/day
20 MB/s × 86,400 ≈ 1.728 TB/day

Kemasukan puncak adalah kira-kira 60 MB/s. Jika destinasi terhenti selama 30 minit pada waktu puncak, tunggakan mentah adalah kira-kira:

60 MB/s × 1,800 seconds = 108 GB

Tujuh hari pada kadar purata ialah kira-kira 12.096 TB data mentah sebelum replikasi, indeks, dan overhed pengekodan. Saizkan broker, storan objek, dan rangkaian untuk trafik puncak dan pengejaran (catch-up), bukan sekadar purata 20 MB/s. Jika pengguna yang dipulihkan hanya dapat menyamai kadar input langsung, ia tidak akan dapat menghapuskan tunggakan 108 GB; reka bentuk memerlukan kapasiti penggunaan lebihan atau kelonggaran sementara bagi kependaman lapisan terurus.

Menyelesaikan snapshot 8 TB dalam 72 jam memerlukan sekurang-kurangnya:

8 TB ÷ 72 hours ≈ 30.9 MB/s

Itu adalah had bawah yang tidak termasuk amplifikasi imbasan, pensirilan, percubaan semula rangkaian, dan penulisan sasaran. Lakukan penandaarasan snapshot berketul (chunked) pada data berbentuk pengeluaran, kemudian hadkan kadar mengikut I/O sumber, kelakuan cache, kelengahan replikasi, dan p99. Jika tarikh akhir bertembung dengan belanjawan sumber 5%, ubah tarikh akhir atau laluan sumber dan bukannya membebani OLTP.

Langkah 2: Pastikan setiap komponen menjawab keperluan ketepatan atau kapasiti

Aliran data utama ialah:

PostgreSQL WAL / logical slot
  → source connector
  → durable change stream keyed by source + table + primary key
  → immutable raw archive
  → schema validation and light normalization
  → sink staging tables
  → idempotent MERGE / DELETE into curated tables
  → warehouse and lakehouse consumers

Berikan setiap pangkalan data sumber pengecam sumber, penyambung, dan replication slot tersendiri supaya satu domain kegagalan tidak menghentikan semua sumber. Strim tahan lasak menyerap lonjakan, mengasingkan pengguna, dan menyokong main semula jangka pendek. Storan objek mengekalkan sejarah yang lebih panjang. Pastikan lapisan pemprosesan CDC terhad kepada pengesahan skema, penormalan, dan penghalaan; carian luaran yang tidak boleh dimainkan semula dalam laluan utama menyukarkan pemulihan. Tulis ke gudang data melalui jadual pementasan (staging) dan kelompok MERGE atomik kecil untuk mengimbangi SLA dua minit dengan penulisan kolumnar yang cekap.

Gunakan pengekodan stabil (source_id, table_id, primary_key) sebagai kunci partisi supaya perubahan bagi satu baris sampai ke satu partisi tersusun. Ini tidak menyediakan susunan global, dan susunan global sememangnya tidak diperlukan. 20 pangkalan data sumber mempunyai jujukan LSN berasingan yang nilai numeriknya tidak mempunyai makna merentas sumber.

Langkah 3: Lakukan snapshot awal secara dalam talian (write-online)

Jujukan logikalnya ialah:

1. Wujudkan logical replication slot supaya WAL yang diperlukan tidak boleh dituntut semula sebelum penyambung menggunakannya.
2. Dapatkan snapshot yang konsisten dan kedudukan log sumber yang sepadan.
3. Baca snapshot dalam ketulan jadual dan kunci utama, memancarkan baris semasa sebagai peristiwa READ.
4. Strim rekod INSERT, UPDATE, dan DELETE terkomit dari kedudukan yang dikaitkan dengan snapshot.
5. Biarkan sinki menumpu mengikut versi sumber, membenarkan main semula sempadan semasa pemulihan tetapi tidak sekali-kali membenarkan selang masa yang hilang.

Penyambung mungkin melaksanakan snapshot konsisten penuh atau tetingkap snapshot berperingkat (incremental). Jawapan tidak sepatutnya mereka cipta protokol "rekod LSN, kemudian jalankan pernyataan SELECT biasa" kerana pengasingan, transaksi panjang, dan penulisan serentak menjadikannya sangat rumit. Bergantung pada semantik penyambung yang disahkan dan uji satu kunci utama yang dikemas kini, dipadam, dan dicipta semula berulang kali semasa ketulan snapshot-nya sedang berjalan.

Ketul mengikut julat kunci utama dan kekalkan kemajuan. Ketulan yang lebih kecil mengurangkan transaksi panjang, gangguan cache, dan kerja semula akibat kegagalan; ketulan yang terlalu kecil menambah overhed pertanyaan dan penjadualan. Hadkan kadar setiap sumber secara bebas, wujudkan keyakinan hujung ke hujung dengan jadual kecil dahulu, kemudian proses jadual besar. Penyambung mesti terus mengalirkan WAL semasa snapshot atau WAL yang dikekalkan akan berkembang. Jika penyambung yang dipilih tidak menyokong perubahan skema semasa snapshot berperingkat, bekukan DDL untuk jadual tersebut atau jedakan snapshot-nya.

Langkah 4: Takrifkan peristiwa, susunan, dan penggunaan kedap kuasa

Peristiwa yang dinormalkan merangkumi sekurang-kurangnya:

ChangeEvent {
  event_id
  source_id
  table_id
  primary_key
  operation          // READ | CREATE | UPDATE | DELETE
  before
  after
  source_lsn
  transaction_id
  transaction_order
  source_commit_time
  schema_version
  captured_at
}

Dalam satu sumber, source_lsn berserta susunan transaksi menetapkan susunan peristiwa. Kunci versi mesti mengandungi source_id kerana LSN daripada pangkalan data berbeza tidak berkongsi sistem koordinat. Bagi setiap (source_id, table_id, primary_key), sasaran menyimpan versi sumber terakhir yang digunakan. Sinki memperakui versi yang sama atau lebih lama tanpa mengubah baris. Versi yang lebih baharu mengemas kini kedua-dua baris perniagaan dan versi yang digunakan dalam satu transaksi sasaran.

Ini menjadikan tetingkap kegagalan utama sekurang-kurangnya sekali boleh diurus:

• Peristiwa sampai ke strim tahan lasak tetapi ofset sumbernya tidak direkodkan: pemulihan memancarkannya semula, dan sinki mengabaikan versi yang sama.
• MERGE sasaran dikomit tetapi perakuan hilang: kelompok dimainkan semula dan menumpu kepada keadaan yang sama.
• Pengguna ranap di tengah-tengah kelompok: baris terkomit dimainkan semula dengan selamat dan baris yang belum dikomit diproses semula.

Jika destinasi memerlukan keatomikan transaksi berbilang baris, aktifkan metadata sempadan transaksi dan timbal mengikut transaction_id sehingga END, kemudian komit transaksi lengkap bersama-sama. Transaksi besar menggunakan lebih banyak memori dan meningkatkan kependaman ekor (tail latency), serta logik tamat masa atau pemulihan mesti menentukan sama ada sesuatu transaksi telah selesai. Gudang data analitik biasa yang memerlukan ketekalan akhirnya (eventual consistency) pada peringkat baris tidak sepatutnya menerima kerumitan ini tanpa keperluan sebenar.

Langkah 5: Kendalikan pemadaman, perubahan kunci, dan evolusi skema dengan betul

Peristiwa DELETE mesti membawa maklumat kunci yang mencukupi untuk lapisan terurus memadam baris secara kekal (hard-delete), menetapkan is_deleted, atau mengekalkan sejarah. Tombstone yang mengikuti pemadaman terutamanya menyokong pemadatan log. Ia tidak boleh menggantikan peristiwa pemadaman perniagaan, dan perisian tengah (middleware) tidak boleh membuang pemadaman sebelum ia sampai ke sasaran.

Apabila nilai kunci utama berubah, semantik CDC biasa memancarkan pemadaman untuk kunci lama dan penciptaan untuk kunci baharu. Sinki mesti menggunakan kedua-duanya atau kunci lama kekal sebagai baris hantu. Menukar definisi kunci utama adalah lebih berisiko daripada menukar nilai. Gunakan tetingkap baca sahaja atau jeda penulisan, kosongkan penyambung, kemas kini skema, dan kemudian sambung semula kerana bentuk kunci peristiwa boleh menjadi tidak konsisten semasa peralihan.

Gunakan dasar keserasian yang jelas:

• Penambahan lajur boleh-batal: daftarkan versi baharu, biarkan pengguna lama mengabaikan medan yang tidak diketahui, kembangkan jadual terurus sebelum membolehkan penulisan.
• Lajur digugurkan atau dinamakan semula: perkenalkan dan isi medan baharu, migrasikan setiap pengguna, kemudian alih keluar medan lama.
• Jenis data diperluaskan: tingkat taraf selepas semakan keserasian sasaran. Jenis data yang dikecilkan atau perubahan semantik mengkuarantin peristiwa yang tidak serasi.
• Perubahan kunci utama: kendalikan sebagai migrasi berasingan dan bukannya evolusi automatik senyap.

Peristiwa yang tidak serasi memasuki kuarantin dan mencetuskan amaran. Ofset utama boleh maju hanya selepas peristiwa disimpan secara tahan lasak, boleh dimainkan semula, dan diberikan pemilik pemulihan yang jelas. Melangkau skema yang salah secara senyap mewujudkan lompang data yang tidak kelihatan.

Langkah 6: Rawat pemulihan, main semula, dan penyesuaian sebagai laluan normal

Pemulihan penyambung memerlukan kedua-dua ofset yang dikekalkan dan replication slot yang masih mengandungi sejarah yang sepadan. Pantau restart_lsn, confirmed_flush_lsn, kedudukan WAL semasa, bait yang dikekalkan, kadar pertumbuhan, dan masa sehingga kehabisan cakera. Gangguan destinasi sepatutnya terkumpul dalam strim tahan lasak dan bukannya menghentikan perakuan penyambung sehingga mengekalkan WAL tanpa batas pada sumber.

Jika slot hilang, ofset yang disimpan berada di belakang kedudukan slot yang tersedia, atau WAL yang diperlukan telah tiada, gagal-tutup. Hentikan penerbitan terurus untuk sumber tersebut, rekodkan kedudukan dipercayai terakhir, ambil snapshot semula jadual yang terjejas, dan sesuaikan mengikut julat. Slot yang baru dicipta hanya menangkap perubahan selepas penciptaannya dan tidak dapat membuktikan bahawa selang masa sebelumnya adalah lengkap.

Main semula mempunyai replay_job_id tersendiri, skop jadual dan kunci utama, serta sempadan masa sumber. Ia membaca lapisan mentah yang tidak boleh diubah ke dalam pementasan. Data langsung dan main semula menggunakan peraturan MERGE versi sumber yang sama supaya pengisian semula yang lebih lama tidak boleh menulis ganti keadaan yang lebih baharu. Apabila logik transformasi berubah, bina versi terurus atau jadual bayangan (shadow table) baharu terlebih dahulu; membandingkan dan membatalkan (rollback) adalah lebih selamat daripada menulis ganti pengeluaran serta-merta.

Penyesuaian merangkumi sekurang-kurangnya empat lapisan:

1. Kesinambungan dari kedudukan komit sumber ke penyambung, strim tahan lasak, dan kedudukan sasaran yang digunakan.
2. Kiraan baris, kiraan pemadaman, dan checksum mengikut jadual, tarikh, dan baldi kunci utama.
3. Perbandingan sampel kunci utama antara keadaan semasa sumber dan keadaan terkini destinasi.
4. Transaksi kenari (canary) berkala yang boleh dikenal pasti untuk mengesahkan keterlihatan INSERT, UPDATE, dan DELETE dalam SLA.

Pecahkan kependaman hujung ke hujung kepada komit sumber ke penangkapan, penangkapan ke strim, strim ke pementasan, dan pementasan ke terurus. Pantau juga kadar peristiwa setiap sumber, kelengahan LSN, WAL slot yang dikekalkan, kemajuan ketulan snapshot, versi pendua atau lapuk, kuarantin skema, kegagalan MERGE sasaran, delta penyesuaian, dan anggaran masa pengejaran.

Langkah 7: Terangkan sempadan alternatif

Pengundian (polling) mengikut updated_at adalah mudah untuk jadual penulisan rendah dengan kesegaran peringkat minit dan imbasan semula yang boleh diterima. Ia menambah beban pertanyaan, mudah terlepas pemadaman kekal, dan masih perlu mengendalikan cap masa yang sama serta kejituan jam. Pencetus (triggers) boleh menulis pemadaman ke dalam jadual audit, tetapi ia menambah beban kerja dan gandingan operasi pada laluan penulisan sumber. CDC berasaskan log ialah pilihan lalai yang lebih baik untuk beban kerja OLTP yang sibuk dalam masalah ini.

Corak outbox menyelesaikan masalah yang berbeza: perkhidmatan menulis keadaan perniagaan dan peristiwa domain dalam satu transaksi pangkalan data, mengelakkan komit pangkalan data yang berjaya diikuti oleh penghantaran mesej yang gagal. Ia sesuai untuk peristiwa perniagaan terpilih. Ia tidak secara automatik menggantikan penyelarasan peringkat baris generik untuk 200 jadual. Kedua-duanya boleh wujud bersama: integrasi perkhidmatan menggunakan outbox, manakala analitik dan audit menggunakan CDC.

Contoh Jawapan yang Kukuh

"Saya akan bermula dengan jaminan. Setiap perubahan terkomit yang masih wujud dalam WAL atau strim tahan lasak mestilah boleh dipulihkan. Sesuatu baris menumpu mengikut kedudukan sumber, main semula tidak mengubah keadaan akhirnya, dan pemadaman sampai ke sasaran. Jika replication slot dan kedudukan sejarah tidak lagi utuh, penerbitan terhenti dan data yang terjejas diambil snapshot semula; penyambung tidak boleh memulakan semula secara senyap pada kedudukan terbaharu.

Pada beban purata, kemasukan adalah kira-kira 20 MB/s, 1.728 bilion peristiwa dan 1.728 TB sehari. Waktu puncak ialah 60 MB/s, jadi gangguan sasaran selama 30 minit mewujudkan kira-kira 108 GB tunggakan. Pengekalan mentah selama tujuh hari adalah kira-kira 12.096 TB. Snapshot 8 TB memerlukan sekurang-kurangnya 30.9 MB/s bacaan berkesan untuk selesai dalam tempoh 72 jam, jadi saya akan menandaarasnya dan mengehadkan kadar setiap sumber mengikut p99, I/O, dan WAL yang dikekalkan.

Setiap sumber PostgreSQL mendapat slot logikal dan penyambung bebas. Penyambung mengambil snapshot yang konsisten dan kemudian menyambung semula perubahan terkomit daripada LSN yang sepadan. Peristiwa dipisahkan mengikut sumber, jadual, dan kunci utama ke dalam strim tahan lasak dan disalin ke dalam lapisan mentah yang tidak boleh diubah. Pemprosesan ringan mengesahkan skema dan menormalkan sampul (envelope). Gudang data memuatkan jadual pementasan, kemudian melakukan operasi MERGE atau DELETE yang kedap kuasa mengikut kunci utama dan versi sumber. LSN tidak sekali-kali dibandingkan merentas pangkalan data; susunan transaksi menambah LSN dalam sesuatu transaksi.

Snapshot dipecahkan kepada ketulan mengikut julat kunci utama, kemajuan dikekalkan, dan beban sumber dihadkan secara dinamik. WAL dialirkan semasa snapshot berjalan, dan peraturan versi sumber sasaran menyerap main semula pemulihan di sempadan. Peristiwa mengandungi operasi, nilai sebelum dan selepas, LSN sumber, identiti dan susunan transaksi, serta versi skema. Sinki hanya menggunakan versi yang lebih baharu, jadi main semula penyambung, perakuan sasaran yang hilang, dan ranapan pengguna semuanya menumpu dengan selamat.

Peristiwa pemadaman kekal utuh melalui lapisan terurus; tombstone hanya untuk pemadatan. Perubahan nilai kunci utama digunakan sebagai pemadaman kunci lama ditambah penciptaan kunci baharu. Penambahan lajur boleh-batal boleh berevolusi secara serasi, manakala pengguguran, penamaan semula, jenis data yang dikecilkan, dan perubahan kunci menggunakan migrasi terkawal. Rekod yang tidak serasi dikuarantin dan boleh dimainkan semula dan bukannya dilangkau secara senyap.

Secara operasi, saya akan memantau kependaman bersegmen, kelengahan LSN setiap sumber, WAL slot yang dikekalkan dan ruang cakera, kemajuan snapshot, kuarantin skema, kegagalan sasaran, dan delta penyesuaian. Kehilangan slot akan gagal-tutup dan mencetuskan snapshot semula skop yang terjejas. Akhir sekali, saya akan menyuntik penulisan serentak semasa snapshot, penghantaran pendua, pemadaman, perubahan kunci, ranapan penyambung, perakuan sinki yang hilang, gangguan sinki 30 minit, kehilangan slot, dan perubahan skema yang merosakkan. Kiraan baris, checksum baldi-kunci, sampel baris, dan transaksi kenari akan membuktikan bahawa tiada perubahan yang hilang dan tiada peristiwa lapuk menulis ganti keadaan yang lebih baharu."

Kesilapan Lazim

• Mengeksport setiap jadual dan hanya mengaktifkan CDC selepas itu → WAL dari selang masa eksport boleh hilang, meninggalkan lompang snapshot-ke-strim → Tetapkan pengekalan log dan kedudukan snapshot yang konsisten sebelum menstrim dari titik yang sepadan.
• Hanya menyebut "gunakan Debezium dan Kafka" → Nama produk tidak mentakrifkan kependaman, susunan, pemulihan, atau kedap kuasa sinki → Nyatakan invarian ketepatan dan kapasiti terlebih dahulu, kemudian petakan setiap komponen kepadanya.
• Membandingkan LSN daripada pangkalan data berbeza sebagai satu versi global → Setiap sumber mempunyai koordinat log bebas → Sertakan source_id dalam versi dan bandingkan kedudukan hanya di dalam satu jujukan sumber.
• Menganggap broker exactly-once menjadikan gudang data exactly-once → MERGE luaran boleh berada di luar transaksi broker dan dimainkan semula selepas perakuan yang hilang → Gunakan perubahan secara kedap kuasa mengikut kunci utama dan versi sumber.
• Menunggu penyambung yang terhenti tanpa had masa → Slotnya boleh mengekalkan WAL sehingga storan sumber penuh → Pantau bait yang dikekalkan dan masa sehingga kehabisan, asingkan gangguan sinki dengan strim tahan lasak, dan tetapkan ambang henti-rugi (stop-loss).
• Mencipta semula slot yang hilang dan meneruskan pada kedudukan terbaharu → Slot baharu tidak mempunyai sejarah terdahulu dan boleh menyembunyikan data yang hilang → Gagal-tutup, ambil snapshot semula, dan sesuaikan skop yang terjejas.
• Menganggap tombstone sebagai satu-satunya isyarat pemadaman → Penanda pemadatan tidak boleh menggantikan DELETE perniagaan yang membawa kunci baris → Kekalkan peristiwa pemadaman dan pilih pemadaman kekal, pemadaman lembut (soft delete), atau sejarah di destinasi.
• Menerima setiap perubahan skema secara automatik → Pengguguran, pengecilan jenis data, dan perubahan kunci boleh merosakkan pengguna atau kunci peristiwa → Takrifkan matriks keserasian, kuarantin rekod yang tidak serasi, dan laksanakan migrasi yang merosakkan secara berperingkat.
• Hanya mengoptimumkan untuk tarikh akhir snapshot 72 jam → Imbasan besar boleh merosakkan p99 sumber, kelakuan cache, dan replikasi → Tanda aras had bawah 30.9 MB/s, hadkan kadar secara dinamik, dan lindungi belanjawan sumber.
• Hanya membandingkan jumlah kiraan baris → Kemas kini yang salah guna, pemadaman yang terlepas, dan ralat yang saling mengimbangi boleh kekal tersembunyi → Bandingkan kiraan dan checksum mengikut baldi kunci, buat pensampelan baris, dan suntik kenari.

Soalan Susulan

Susulan 1: Bagaimanakah anda membuktikan bahawa kemas kini dan pemadaman semasa snapshot tidak membenarkan nilai snapshot lama menulis ganti keadaan baharu?

Gunakan semantik snapshot konsisten dan serahan log yang disahkan milik penyambung dan bukannya meneka pemasaan aplikasi. Sinki menyimpan versi sumber bagi setiap baris dan hanya menerima versi yang lebih baharu, jadi READ yang dimainkan semula tidak boleh menulis ganti UPDATE atau DELETE yang lebih baharu. Semasa ujian, kemas kini, padam, dan cipta semula satu kunci berulang kali di sekitar ketulan snapshot-nya, kemudian sahkan kesaksamaan akhir sumber-ke-sasaran dan kesinambungan kedudukan sumber.

Susulan 2: Bagaimanakah anda menganggarkan masa pemulihan selepas gangguan gudang data selama 30 minit?

Tunggakan puncak adalah kira-kira 108 GB. Masa pemulihan bergantung pada daya pemprosesan yang dipulihkan tolak kemasukan langsung yang berterusan. Jika trafik langsung kembali kepada purata 20 MB/s dan pengguna mengekalkan 80 MB/s, kadar pengejaran bersih ialah kira-kira 60 MB/s, menjadikan masa pengaliran teori kira-kira 30 minit sebelum amplifikasi MERGE dan margin keselamatan. Jika pemprosesan hanya menyamai kemasukan langsung, tunggakan tidak akan berkurangan.

Susulan 3: Apakah yang berubah jika semua baris dalam satu transaksi sumber mesti kelihatan bersama-sama?

Aktifkan metadata sempadan transaksi, kumpulkan peristiwa mengikut ID transaksi, dan komit transaksi ke pementasan dan penerbitan hanya selepas sempadan END yang lengkap. Kekalkan transaksi besar ke cakera, takrifkan tamat masa dan laluan pemulihan, dan sambung semula daripada keadaan pemasangan yang tahan lasak. Ini meningkatkan kependaman ekor dan kos keadaan, jadi sahkan terlebih dahulu bahawa ketidakkonsistenan merentas jadual yang singkat benar-benar tidak boleh diterima oleh pengguna.

Susulan 4: Jika replication slot hilang tetapi strim tahan lasak masih mempunyai 7 hari data, adakah anda mesti menjalankan snapshot penuh?

Cari lompang yang mungkin berlaku terlebih dahulu. Jika strim tahan lasak terbukti mengandungi setiap perubahan selepas LSN dipercayai terakhir, main semula dan penyesuaian boleh memulihkan kesinambungan tanpa snapshot penuh. Jika slot hilang sebelum peristiwa sampai ke strim, atau sempadan lompang tidak dapat dibuktikan, ambil snapshot semula jadual atau julat kunci utama yang terjejas. Keputusan mengikut kesinambungan yang dapat dibuktikan, bukan kos kerja semula.

Susulan 5: Mengapa tidak menggantikan keseluruhan reka bentuk dengan outbox?

Outbox sangat baik apabila perkhidmatan secara eksplisit menerbitkan peristiwa domain seperti pesanan-dicipta atau pembayaran-selesai dan menulis peristiwa tersebut dalam transaksi yang sama dengan keadaan perniagaan. Ia memerlukan penglibatan aplikasi dan hanya mengandungi fakta terpilih. Masalah ini menyelaraskan insert, update, dan delete merentasi 200 jadual untuk analitik, jadi CDC peringkat baris generik tetap diperlukan. Kedua-dua corak boleh wujud bersama untuk pengguna yang berbeza.