سوالات متداول

DeBezium مجموعه ای از سرویس های توزیع شده است که تغییرات سطح ردیف را در پایگاه داده های شما ضبط می کند تا برنامه های شما بتوانند آن تغییرات را ببینند و پاسخ دهند. سوابق DeBezium در یک معامله ، تمام تغییرات سطح ردیف را که به هر جدول پایگاه داده انجام می شود ، وارد می کند. هر برنامه به سادگی گزارش های معامله مورد علاقه خود را می خواند و همه وقایع را به همان ترتیب که در آن رخ داده است می بینند.

نام "debezium" از کجا آمده است؟

این نام ترکیبی از "DBS" است ، همانطور که در مخفف چندین پایگاه داده ، و پسوند "-ium" که در نام بسیاری از عناصر جدول تناوبی استفاده می شود. آن را سریع بگویید: "DBS-ium". اگر کمک کند ، ما آن را مانند "dee-bee-zee-uhm" می گوییم.

تغییر داده های تغییر چیست؟

تغییر ضبط داده ها ، یا CDC ، یک اصطلاح قدیمی برای سیستمی است که تغییرات در داده ها را نظارت و ضبط می کند تا سایر نرم افزارها بتوانند به آن تغییرات پاسخ دهند. انبارهای داده ها اغلب از CDC داخلی پشتیبانی می کردند ، زیرا با تغییر داده ها در پایگاه داده های بالادست OLTP ، انبارهای داده باید به روز بمانند.

DeBezium در اصل یک پلت فرم ضبط داده تغییر منبع باز مدرن است که در نهایت از نظارت بر انواع سیستم های پایگاه داده پشتیبانی می کند.

چه پایگاه داده ای می تواند DeBezium را کنترل کند؟

آخرین نسخه DeBezium شامل پشتیبانی از نظارت بر سرورهای پایگاه داده MySQL ، مجموعه های ماکت MongoDB یا خوشه های Sharded ، سرورهای PostgreSQL و پایگاه داده های سرور SQL است. علاوه بر این ، اتصالات DeBezium در حال پیشرفت برای سرورهای اوراکل (بر اساس Xstream) و پایگاه داده های کاساندرا وجود دارد که به عنوان نسخه های پیش نمایش (جوجه کشی) از Debezium 1. 0 منتشر می شوند.

توجه داشته باشید که نظارت بر PostgreSQL نیاز به نصب یک پسوند ("افزونه رمزگشایی منطقی") در سرور PostgreSQL دارد. Debezium با DecoderBufs (که توسط جامعه Debezium نگهداری می شود) ، Wal2Json و Pgoutput (که توسط انجمن Postgres نگهداری می شود) کار می کند.

اگر پایگاه داده شما در یک سرویس ابری (مدیریت شده) میزبانی شده باشد ، باید یکی از این افزونه ها نصب شود (یا باید خودتان بتوانید آن را نصب کنید). در غیر این صورت ، شما قادر به نظارت بر پایگاه داده خود با Debezium نخواهید بود. pgoutput بخشی از Postgres 10 و بعد است. این که آیا می توان آن را فعال کرد بستگی به پیکربندی پایگاه داده خاص دارد (به عنوان مثال نمی تواند دستگاه خودپرداز را فعال کند. در سرویس مدیریت شده Google در زمان نوشتن ، آوریل 2020). در آمازون RDS و همچنین با پایگاه داده Azure برای PostgreSQL ، می توان از Pgoutput استفاده کرد. علاوه بر این Wal2Json نصب شده است. هر دو را می توان با Debezium استفاده کرد. می توانید در مورد تعهدات دقیق Wal2Json مستقر در آمازون RDS در اسناد RDS برای Postgres اطلاعات کسب کنید.

پشتیبانی از سایر DBMSE در نسخه های بعدی اضافه می شود. نقشه راه ما را ببینید.

برخی از کاربردهای Debezium چیست؟

استفاده اصلی از DeBezium این است که برنامه ها را تقریباً بلافاصله پاسخ دهند هر زمان که داده های موجود در پایگاه داده ها تغییر کنند. برنامه ها می توانند با درج ، به روزرسانی و حذف رویدادها هر کاری انجام دهند. آنها ممکن است از این رویدادها استفاده کنند تا بدانند چه زمانی باید ورودی ها را از حافظه نهان خارج کنند. آنها ممکن است شاخص های جستجو را با داده ها به روز کنند. آنها ممکن است یک فروشگاه داده مشتق شده را با همان اطلاعات یا با اطلاعات محاسبه شده از داده های در حال تغییر ، مانند جداسازی مسئولیت پرس و جو (CQR) به روز کنند. آنها ممکن است یک اعلان فشار را به یک یا چند دستگاه تلفن همراه ارسال کنند. آنها ممکن است تغییرات را جمع کنند و جریانی از تکه ها را برای اشخاص ایجاد کنند. آنها ممکن است برای تشکیل یک پرونده حسابرسی ذخیره شوند. آنها ممکن است نمایش داده های جریان را به عنوان مثال هدایت کنند. با جریان Apache Flink یا Kafka. آنها ممکن است برای انتشار داده ها بین میکروسرویس ، به عنوان مثال استفاده شود. با استفاده از الگوی Outbox.

در این ارائه از QCON San Francisco 2019 می توانید در مورد موارد استفاده CDC اطلاعات بیشتری کسب کنید.

چرا Debezium یک سیستم توزیع شده است؟

Debezium برای تحمل گسل ها و ناکامی ها معماری است و تنها راه مؤثر برای انجام این کار با یک سیستم توزیع شده است. DeBezium فرآیندهای نظارت یا اتصالات را در چندین دستگاه توزیع می کند تا در صورت بروز هرگونه اشتباه ، اتصالات دوباره راه اندازی شوند. این رویدادها در چندین دستگاه ضبط و تکرار می شوند تا خطر از دست دادن اطلاعات به حداقل برسد.

آیا برنامه من می تواند مستقیماً یک پایگاه داده را کنترل کند؟

آره. اگرچه ما به اکثر مردم توصیه می کنیم از پلتفرم کامل Debezium استفاده کنند، اما برای یک برنامه کاربردی امکان دارد یک رابط Debezium را تعبیه کند تا بتواند پایگاه داده را نظارت کند و به رویدادها پاسخ دهد. این روش در واقع با قطعات متحرک اندک بسیار ساده تر است، اما محدودتر است و تحمل خرابی ها بسیار کمتر است. اگر برنامه شما حداقل یک بار به ضمانت تحویل همه پیام ها نیاز دارد، لطفاً از سیستم کامل توزیع شده استفاده کنید.

پلت فرم Debezium چگونه به نظر می رسد؟

یک سیستم در حال اجرا Debezium از چندین قطعه تشکیل شده است. خوشه ای از کارگزاران آپاچی کافکا، لاگ های تراکنش دائمی، تکراری و پارتیشن بندی شده را فراهم می کند که در آن Debezium همه رویدادها را ثبت می کند و برنامه ها از آن همه رویدادها را مصرف می کنند. تعداد کارگزاران کافکا تا حد زیادی به حجم رویدادها، تعداد جداول پایگاه داده تحت نظارت و تعداد برنامه هایی که رویدادها را مصرف می کنند بستگی دارد. کافکا برای مدیریت مسئولیت‌های هر کارگزار به مجموعه کوچکی از گره‌های Zookeeper متکی است.

هر کانکتور Debezium یک کلاستر/سرور پایگاه داده را نظارت می کند، و کانکتورها پیکربندی شده و در مجموعه ای از سرویس های Kafka Connect مستقر می شوند که اطمینان حاصل می کنند که هر کانکتور همیشه در حال اجرا است، حتی زمانی که نمونه های سرویس Kafka Connect از خوشه خارج شده و به آن می پیوندند. هر خوشه خدمات کافکا کانکت (با نام مستعار، گروه) مستقل است، بنابراین برای هر گروه در یک سازمان ممکن است خوشه های خود را مدیریت کند.

همه کانکتورها رویدادهای خود (و اطلاعات دیگر) را در آپاچی کافکا ضبط می‌کنند، آپاچی کافکا، رویدادها را تکرار می‌کند، و رویدادها را برای هر جدول در موضوعات جداگانه تقسیم می‌کند. چندین خوشه خدمات Kafka Connect می توانند یک خوشه واحد از کارگزاران کافکا را به اشتراک بگذارند، اما تعداد کارگزاران کافکا تا حد زیادی به حجم رویدادها، تعداد جداول پایگاه داده تحت نظارت و تعداد برنامه هایی که رویدادها را مصرف می کنند بستگی دارد.

برنامه ها مستقیماً به کافکا متصل می شوند و رویدادها را در موضوعات مناسب مصرف می کنند.

چند پایگاه داده قابل نظارت است؟

Debezium می تواند هر تعداد پایگاه داده را نظارت کند. تعداد کانکتورهایی که می توانند در یک خوشه از خدمات کافکا کانکت مستقر شوند به حجم و سرعت رویدادها بستگی دارد. با این حال، Debezium از چندین خوشه خدمات Kafka Connect و در صورت نیاز از چندین خوشه Kafka نیز پشتیبانی می کند.

چگونه Debezium بر پایگاه داده های منبع تأثیر می گذارد؟

قبل از اینکه DeBezium بتواند آنها را کنترل کند ، بیشتر بانکهای اطلاعاتی باید پیکربندی شوند. به عنوان مثال ، یک سرور MySQL باید برای استفاده از binlog سطح ردیف پیکربندی شود و یک کاربر ممتاز باشد که Binlog را بخواند. اتصال DeBezium باید با اطلاعات صحیح از جمله کاربر ممتاز پیکربندی شود. برای جزئیات بیشتر به مستندات اتصال خاص مراجعه کنید.

اتصالات DeBezium هیچ اطلاعاتی را در پایگاه داده های بالادست ذخیره نمی کنند. با این حال ، اجرای یک کانکتور ممکن است بار اضافی را در پایگاه داده منبع قرار دهد.

چگونه وقایع برای یک پایگاه داده سازماندهی می شود؟

بیشتر کانکتورها تمام رویدادها را برای یک جدول پایگاه داده واحد در یک موضوع واحد ثبت می کنند. علاوه بر این ، تمام وقایع موجود در یک موضوع کاملاً سفارش داده شده است ، به این معنی که ترتیب همه این رویدادها حفظ می شود.(حتی اگر وقایع در حین خرابی کپی شوند ، نتیجه نهایی پس از اعمال همه رویدادها یکسان خواهد بود.)

به عنوان مثال ، یک کانکتور MySQL که یک سرور/خوشه MySQL را کنترل می کند (با نام منطقی "dbservera") تمام تغییرات را در جدول "آدرس" در پایگاه داده "مشتریان" در موضوع به نام dbservera. customers. addresses ثبت می کند. به همین ترتیب ، تمام تغییرات در جدول "PaymentMethods" در همان پایگاه داده در موضوعی به نام dbservera. customers. paymentmethods ثبت می شود.

چرا وقایع اینقدر بزرگ هستند؟

DeBezium برای نظارت بر بانکهای اطلاعاتی بالادست و تولید برای هر تغییر سطح ردیف یک یا چند رویداد مربوطه که کاملاً توصیف می کنند ، طراحی شده است. اما اتصالات Debezium به طور مداوم کار می کنند ، و وقایع آن حتی با ساختار جداول در پایگاه داده های بالادست با گذشت زمان تغییر می کند. اگر فقط مجبور باشد با یک رویداد واحد در یک زمان مقابله کند ، به جای اینکه بخواهد وضعیت را در کل تاریخ جریان رویداد ردیابی کند ، نوشتن آن نیز بسیار ساده تر است.

این بدان معناست که هر رویداد باید کاملاً خود را توصیف کند: کلید و ارزش یک رویداد حاوی یک بار با اطلاعات واقعی و یک طرح است که ساختار اطلاعات را کاملاً توصیف می کند. مصرف برنامه های کاربردی می تواند هر رویداد را پردازش کند ، از طرحواره برای درک ساختار اطلاعات در آن رویداد استفاده کند و سپس بارگذاری بار رویداد را به درستی پردازش کند. کاربرد مصرف کننده می تواند از این واقعیت استفاده کند که این طرح برای بسیاری از وقایع پشت سر هم یکسان باقی خواهد ماند و تنها در صورت تغییر طرحواره ممکن است برنامه مصرف کننده نیاز به انجام کار کمی بیشتر برای ساختار تغییر یافته داشته باشد.

در همین حال ، خدمات Kafka Connect رویدادهای اتصال را سریال می کند و آنها را در کافکا ضبط می کند. مبدل JSON بسیار عمومی و بسیار ساده است ، اما چاره ای جز سریال سازی کل اطلاعات رویداد ندارد. بنابراین ، وقایع نمایش داده شده در JSON در واقع کلامی و بزرگ هستند.

با این حال ، یک جایگزین وجود دارد: استفاده از یک رجیستری طرحواره. به این ترتیب ، اطلاعات واقعی طرحواره توسط رجیستری مدیریت می شود ، در حالی که رویدادهای تغییر واقعی فقط شامل شناسه طرح مربوطه در رجیستری است. این منجر به نمایش بسیار کارآمدتر از وقایع ارسال شده به کافکا می شود. از ثبت های شمای می توان با قالب های مختلفی مانند JSON یا AVRO استفاده کرد. استفاده از AVRO به عنوان قالب پیام از مزیت اضافی برخوردار است که بارهای بار به یک فرم باینری بسیار جمع و جور سریال می شوند.

با استفاده از این رویکرد ، یک مبدل Kafka Connect و رجیستری طرحواره با هم همکاری می کنند تا تاریخ هر طرح را با گذشت زمان ردیابی کنند. در همین حال ، در مصرف کننده ، همان مبدل شکل باینری جمع و جور این رویداد را رمزگشایی می کند ، شناسه نسخه طرحواره ای را که توسط آن پیام استفاده می شود ، می خواند ، اگر هنوز ندیده است که نسخه Schema این طرح را از رجیستری طرحواره بارگیری می کند ، و در آخراز آن طرحواره برای رمزگشایی بار این رویداد استفاده می کند. باز هم ، بسیاری از وقایع به صورت توالی همان طرحواره (و نسخه طرحواره) را به اشتراک می گذارند ، بنابراین بیشتر اوقات مبدل می تواند به سادگی رویداد جمع و جور خام را در همان طرح و بار مورد انتظار مصرف کننده رمزگشایی کند.

چگونه می توانم از یک رجیستری طرحواره استفاده کنم؟

گزینه های مربوط به ثبت نام شامل APICURIO API و رجیستری Schema و رجیستری طرحواره Confluent است. هر دو با مبدل هایی برای ذخیره/به دست آوردن طرح های JSON و AVRO در و از طریق رجیستری همراه هستند.

اگر در حال اعزام اتصالات DeBezium به یک سرویس Kafka Connect Worker هستید ، به سادگی اطمینان حاصل کنید که کوزه های مبدل رجیستری شما در دسترس هستند و سرویس کارگر را برای استفاده از مبدل مناسب پیکربندی می کنید. به عنوان مثال ، شما باید مبدل را به رجیستری طرحواره Apicurio خود نشان دهید. سپس ، به سادگی اتصالات DeBezium (یا واقعاً هر اتصالات دیگر Kafka Connect) را به سرویس کارگر خود مستقر کنید. برای توضیحات مفصل در مورد نحوه استفاده از مبدل AVRO با ثبت های Apicurio و Confluent ، به سریال سازی Avro مراجعه کنید.

مثال آموزش در GitHub نحوه استفاده از رجیستری طرحواره و مبدل های همراه با Debezium را به تفصیل نشان می دهد.

تصاویر Docker ما برای Kafka Connect شامل مبدل Avro به عنوان یک گزینه است.

چه اتفاقی می افتد که یک برنامه متوقف شود یا خراب شود؟

برای مصرف رویدادهای تغییر برای یک پایگاه داده ، یک برنامه یک مصرف کننده کافکا ایجاد می کند که به کارگزاران کافکا متصل می شود و تمام رویدادها را برای موضوعات مرتبط با آن بانک اطلاعاتی مصرف می کند. مصرف کننده پیکربندی شده است تا به طور دوره ای موقعیت خود (با نام مستعار ، افست) را در هر موضوع ثبت کند. هنگامی که یک برنامه با لطف متوقف می شود و مصرف کننده را می بندد ، مصرف کننده جبران خسارات آخرین رویداد را در هر موضوع ثبت می کند. هنگامی که برنامه در هر زمان دیگری مجدداً راه اندازی می شود ، مصرف کننده آن را به دنبال آن جبران می کند و شروع به خواندن رویدادهای بعدی در هر موضوع می کند. بنابراین ، تحت سناریوهای عملیاتی عادی ، برنامه هر رویداد را دقیقاً یک بار می بیند.

اگر برنامه به طور غیر منتظره ای خراب شود ، پس از راه اندازی مجدد ، مصرف کننده برنامه آخرین جبران های ضبط شده برای هر موضوع را جستجو می کند و از آخرین جبران برای هر موضوع شروع به مصرف می کند. در بیشتر موارد ، این برنامه برخی از همان رویدادهایی را که قبل از تصادف مشاهده کرده است مشاهده می کند (اما پس از آن که جبران آن را ثبت کرد) ، و پس از آن اتفاقاتی که هنوز ندیده بود ، مشاهده می شود. بنابراین ، برنامه حداقل یک بار هر رویداد را مشاهده می کند. این برنامه می تواند تعداد رویدادهایی را که بیش از یک بار با ضبط جبران خسارات مشاهده می شود ، کاهش دهد ، اگرچه انجام این کار بر عملکرد و توان مشتری تأثیر منفی خواهد گذاشت.

توجه داشته باشید که یک مصرف کننده Kafka می تواند برای اتصال و شروع خواندن با جدیدترین افست در هر موضوع تنظیم شود. این می تواند منجر به وقایع از دست رفته شود ، اگرچه این برای برخی موارد استفاده کاملاً قابل قبول است.

چه اتفاقی می افتد که Debezium متوقف شود یا خراب شود؟

رفتار Debezium بسته به اینکه کدام مؤلفه ها متوقف یا خراب شوند متفاوت است. اگر کارگزار کافکا به اندازه کافی متوقف شود یا خراب شود به گونه ای که هر پارتیشن هر موضوع توسط حداقل تعداد ماکت های درون همزمان قرار داشته باشد ، اتصالات می نویسند که به آن مباحث می نویسند و برنامه های مصرف کننده که از آن مباحث می خوانند به سادگی مسدود می شوندکارگزاران کافکا را می توان دوباره راه اندازی کرد یا کارگزاران جدیدی که به صورت آنلاین آورده شده اند. بنابراین ، حداقل تعداد ماکت های همگام سازی تأثیر بسیار زیادی در در دسترس بودن دارد و به دلایل سازگاری همیشه باید حداقل 1 باشد (اگر نه 3).

سرویس Kafka Connect پیکربندی شده است تا به طور دوره ای موقعیت و جبران های هر کانکتور را ثبت کند. اگر یکی از نمونه های سرویس Kafka Connect در خوشه خود با لطف متوقف شود ، کلیه اتصالات که در آن فرآیند اجرا می شوند با لطف متوقف می شوند (به این معنی که همه موقعیت ها و جبران ها ضبط می شوند) و همان اتصالات در سایر موارد سرویس Kafka Connect در سایر موارد مجدداً راه اندازی می شوند. همان خوشههنگامی که این اتصالات مجدداً راه اندازی می شوند ، آنها دقیقاً در جایی که از آنجا خارج شده اند ، ضبط رویدادها را ادامه می دهند و هیچ اتفاقی کپی ضبط نمی شود.

هنگامی که یکی از اتصالات که در یک خوشه سرویس Kafka Connect اجرا می شود ، با لطف متوقف می شود ، کار فعلی خود را به پایان می رساند و آخرین موقعیت ها و جبران های موجود در کافکا را ثبت می کند. برنامه های پایین دست از مباحث مصرف می کنند تا زمانی که رویدادهای جدید اضافه شوند ، منتظر بمانند.

اگر هر یک از نمونه های سرویس Kafka Connect در خوشه های خود به طور غیر منتظره ای خراب شود ، تمام اتصالات موجود در فرآیند سقوط شده در سایر نمونه های سرویس Kafka Connect در همان خوشه مجدداً راه اندازی می شوند. با این حال ، هنگامی که این اتصالات مجدداً راه اندازی می شوند ، آنها شروع به ضبط رویدادها از پایگاه داده می کنند که از موقعیت/جبران آخرین بار توسط کانکتور قبل از خراب شدن شروع می شود. این بدان معناست که اتصالات تازه بازگرداندن احتمالاً ممکن است برخی از همان رویدادهایی را که قبلاً قبل از تصادف ضبط کرده بودند ، ثبت کنند و این نسخه ها همیشه برای برنامه های مصرف کننده پایین دست قابل مشاهده خواهند بود.

چه اتفاقی می افتد که یک پایگاه داده نظارت شده متوقف شود یا خراب شود؟

هنگامی که یک سرور پایگاه داده تحت نظارت Debezium متوقف یا خراب می شود ، اتصال DeBezium احتمالاً سعی در برقراری مجدد ارتباطات خواهد داشت. DeBezium به طور دوره ای موقعیت ها و جبران های اتصال را در کافکا ثبت می کند ، بنابراین پس از برقراری ارتباط ، اتصال باید از آخرین موقعیت ضبط شده و جبران آن ادامه دهد.

چرا مصرف برنامه ها باید از رویدادهای تکراری انتظار داشته باشند؟

هنگامی که همه سیستم ها به صورت اسمی در حال اجرا هستند یا وقتی برخی از سیستم ها به طرز فجیعی خاموش می شوند ، مصرف برنامه ها می توانند انتظار داشته باشند که هر رویداد را دقیقاً یک بار ببینند. با این حال ، هنگامی که همه چیز اشتباه پیش می رود ، همیشه مصرف برنامه ها حداقل یک بار امکان پذیر است.

هنگامی که سیستم های Debezium سقوط می کنند ، آنها همیشه قادر به ثبت آخرین موقعیت/جبران نیستند. هنگامی که آنها دوباره شروع به کار می کنند ، آنها با شروع از جایی که آخرین بار شناخته شده بودند ، بهبود می یابند ، بنابراین برنامه مصرف کننده همیشه هر رویدادی را مشاهده می کند ، اما احتمالاً حداقل برخی از پیام ها را که در هنگام بهبودی کپی شده اند ، مشاهده می کنند.

علاوه بر این ، خرابی شبکه ممکن است باعث شود اتصالات DeBezium تأیید نامه ها را دریافت نکنند ، و در نتیجه یک رویداد یک یا چند بار ثبت می شود (تا زمان دریافت تأیید).

چه چیزی باعث ایجاد EventDatadeserializationException S با اتصال MySQL می شود؟

هنگامی که شما در حدود 1 دقیقه پس از شروع اتصال ، به استثنائات متناوب deserialization می پردازید ، با یک علت اصلی Eofexception یا java.net. socketexception: تنظیم مجدد اتصال:

سپس به روزرسانی این خصوصیات جهانی MySQL Server مانند این ، آن را برطرف می کند: < Span> هنگامی که سیستم های DeBezium خراب می شوند ، همیشه قادر به ثبت آخرین موقعیت/جبران نیستند. هنگامی که آنها دوباره شروع به کار می کنند ، آنها با شروع از جایی که آخرین بار شناخته شده بودند ، بهبود می یابند ، بنابراین برنامه مصرف کننده همیشه هر رویدادی را مشاهده می کند ، اما احتمالاً حداقل برخی از پیام ها را که در هنگام بهبودی کپی شده اند ، مشاهده می کنند.