Change Data Capture ו-Debezium: לשדר כל שינוי במסד כאירוע

מאת צוות מדיה דיל · 27.06.2026 · טכנולוגיה · 4 דק׳

קריאת WAL ו-binlog, Debezium connectors, Kafka topics, Outbox Pattern, cache invalidation וסנכרון מיקרו-שירותים בזמן אמת.

לסנכרן שני מערכות בזמן אמת אפשר בשתי דרכים גרועות: לגרום לכל שירות לכתוב פעמיים (למסד שלו ולתור הודעות) ולסכן חוסר עקביות ברגע שאחת הכתיבות נכשלת, או להריץ polling תקופתי שמפספס עדכונים בין הריצות ומעמיס על המסד. Change Data Capture פותר את זה בלי לגעת בקוד האפליקציה בכלל: הוא קורא ישירות מה-transaction log של מסד הנתונים — ה-WAL ב-Postgres, ה-binlog ב-MySQL — ומשדר כל שינוי כאירוע ברגע שהוא נכתב. כל שירות שצריך לדעת על השינוי פשוט מאזין לזרם הזה, בלי לתאם עם השירות שביצע את הכתיבה המקורית ובלי לדרוש ממנו שינוי קוד כלשהו.

למה קריאה מה-transaction log ולא מהאפליקציה

כל מסד נתונים טרנזקציוני כותב לפני כל שינוי רשומה ל-Write-Ahead Log, בין אם השינוי הגיע מ-ORM, מסקריפט ידני או מ-migration. CDC מתחבר לזרם הזה כ-consumer, בלי להוסיף אף שורת קוד לאפליקציה ובלי עומס נוסף על הכתיבות עצמן — הקריאה קורית באופן אסינכרוני מהלוג שכבר נכתב ממילא. זה גם מבטיח שלא מפספסים שום שינוי, כי הלוג הוא רצף מלא ומסודר של כל מה שקרה במסד, כולל שינויים שבוצעו על ידי סקריפט חד-פעמי או job תחזוקה שמעולם לא עבר דרך שכבת ה-API הרגילה של האפליקציה.

Debezium ותפקיד ה-Connector

Debezium הוא הפתרון הפופולרי ביותר ל-CDC בקוד פתוח: הוא רץ כ-connector בתוך Kafka Connect, מתחבר למסד המקור דרך פרוטוקול replication הייעודי שלו (logical decoding ב-Postgres, למשל), והופך כל INSERT, UPDATE ו-DELETE לרשומת אירוע במבנה קבוע עם ה-before וה-after של השורה. כל טבלה מקבלת topic משלה ב-Kafka, וצרכנים במורד הזרם מגיבים לשינוי כמעט ברגע שהוא קרה במסד המקור. Debezium גם דואג ל-snapshot ראשוני של הטבלה בזמן שהוא מתחבר לראשונה, כך שצרכן חדש מקבל מיד את כל המצב הקיים ולא רק שינויים מרגע ההתחברות ואילך.

Outbox Pattern למניעת חוסר עקביות

הבעיה הקלאסית בשליחת אירועים היא dual write: לכתוב גם למסד וגם לתור בשתי פעולות נפרדות, וקריסה בין השתיים משאירה אי-התאמה. עם CDC אפשר לפתור זאת עם Outbox Pattern — האפליקציה כותבת את האירוע לטבלת outbox באותה טרנזקציה שהיא כותבת את השינוי העסקי, ו-Debezium קורא משם ומשדר, כך שהכתיבה למסד היא מקור האמת היחיד וההודעה תמיד עקבית איתה.

שימושים: סנכרון, cache invalidation ו-Search Index

מעבר לסנכרון בין מיקרו-שירותים, CDC מזין תבניות נפוצות נוספות: החזרת cache שהתיישן ברגע שהרשומה במסד השתנתה, עדכון אינדקס חיפוש כמו Elasticsearch בלי job תקופתי, והזנת מחסן נתונים אנליטי כמעט בזמן אמת במקום ETL לילי. בכל המקרים האלה המסד המקורי לא מודע כלל לצרכנים במורד הזרם — אפשר להוסיף ולהסיר אותם בלי לשנות שורת קוד בשירות המקור, וגם להוסיף צרכן חדש בעתיד בלי לתאם עם הצוות שאחראי על מסד המקור.

מגבלות ונקודות כאב

CDC דורש הרשאות replication ברמת המסד, מה שלא תמיד זמין בסביבות מנוהלות מסוימות, ותקלה ב-connector יכולה לגרום ל-WAL לתפוח כי המסד לא ישחרר אותו עד שהוא נקרא. Schema evolution — הוספת עמודה, שינוי טיפוס — דורש תיאום כי הצרכנים במורד הזרם מצפים למבנה קבוע, ולכן שילוב עם schema registry הוא כמעט חובה בפריסות רציניות. גם סדר הפעולות בשינוי סכמה חשוב: הוספת עמודה חדשה כ-nullable לא שוברת צרכנים קיימים, בעוד ששינוי טיפוס עמודה קיימת עלול לגרום לצרכן ישן לפרש את הנתון בצורה שגויה עד שהוא מתעדכן.

רוצים לסנכרן מערכות בזמן אמת בלי לגעת בקוד הקיים? נשמח לעזור לכם בוואטסאפ.

תגיות: Change Data Capture · Debezium · WAL · Kafka · Outbox Pattern · סנכרון מערכות

← חזרה לבלוג · צור קשר