1. Kirish
Tibbiyot tizimi MSA o'tish loyihasida duch kelgan muammo ma'lumotlarning ikki qismga bo'linishi edi. Yangi MSA tizimi (PostgreSQL) va mavjud meros tizimi (Oracle) bir vaqtda ishlashiga to'g'ri keldi, va ikkala tizim birgalikda xizmat ko'rsatganida ma'lumotlarning bir xillikligini real vaqtda saqlash talab etildi.
Jadval sinxronizatsiyasi o'nlab daqiqalar kechikishlarga sabab bo'lib, tibbiyot sohasida mos kelmaydi, DB trigger usuli esa meros sifatida Oracle uchun operatsion yukni oshirdi va ilovalarni ikki marta yozish tranzaksiya atomligini ta'minlashda qiyinchilik tug'dirdi. Bir nechta usullarni ko'rib chiqqach, manba DB ichidagi tranzaksiya jurnalini to'g'ridan-to'g'ri o'qib, asinxron tarzda tarqatish uchun CDC (Change Data Capture) usulini tanlashga qaror qilindi.
2. Arxitektura: Debezium va Maxsus sinxronizatsiya ilovasi
Debezium - PostgreSQL ning WAL (Write-Ahead Log) ni to'g'ridan-to'g'ri obuna qilib, INSERT/UPDATE/DELETE hodisalarini real vaqt rejimida Kafka ga chiqaradigan ochiq manba CDC platformasidir. Manba DB ga triger yoki kod o'zgartirishlarsiz WAL jurnalini o'qish usuli tufayli meros sistemalariga tegmaslik va konnektor qayta ishlasa ham oxirgi qayd etilgan jurnal joyidan (LSN) davom etishi mumkin, bu loyiha talablariga juda mos kelgan.
[Rasm 1] Debezium rasmiy arxitekturasi — manba: debezium.io/documentation/reference/3.5 (Apache License 2.0)
|
ajratish |
texnologiya |
rol |
|---|---|---|
|
Manba DB |
PostgreSQL |
Ma'lumotlarni o'zgartirish manbai (WAL asosidagi CDC) |
|
CDC dvigatori |
Debezium 3.x |
WAL aniqlash → Kafka voqeani e'lon qilish |
|
Voqea avtobusi |
Apache Kafka |
kamida kamida yetkazib berish kafolatlari (takroriy chiqish mumkin → Consumer idempotentlikni talab qiladi) |
|
Sinxronizatsiya ilovasi |
Data-Sync (Spring Boot) |
Voqeani iste'mol qilish, Oracle aks ettirish, moslik xeshini saqlash |
|
Target DB |
Oracle |
So'nggi sinxronizatsiya maqsadi |
Standart Sink Connector o'rniga maxsus Spring Boot dasturini (Data-Sync) to'g'ridan-to'g'ri ishlab chiqishning uchta asosiy sababi bor edi.
Schemalarni o'zgartirish - Murasar Oracle bilan kompozit PK·standart bo'lmagan ustun nomlari·turli o'zgarishlar (timestamptz → TIMESTAMP WITH LOCAL TIME ZONE va boshqalar) faqat standart Connector sozlamalari bilan muvofiqlashtirilishi qiyin edi.
Xato ishlov berish - Xatolik turlari bo'yicha qayta urinish davri va xabardorlik usullarini boshqacha olish kerak edi, buni amalga oshirish uchun moslashtirilgan kodning moslashuvchanligi talab qilindi.
Moslikni tekshirish - Sinxronizatsiya tugagandan so'ng ma'lumotlar xeshini asinkron saqlab, ikkita tizim o'rtasida moslikni muntazam tekshirish talab qilingan edi.
3. Mustahkamlikni tasdiqlash: nosozlikka qarshi sinov
Loyihalar tugallangandan so'ng, haqiqiy ishga tushirishdan oldin tizimning nosozlik holatlarida ma'lumotlarni yo'qotmasligini tekshirmoqchi edim. Rivojlantirish muhitidagi Kubernetes klasterida senariylar bo'yicha mustaqil ravishda o'tkazildi va har doim PostgreSQL ga 20,000 ta ma'lumot kiritilgandan so'ng, Oracle gacha yo'qotishlarsiz yuklanishini tasdiqladik.
|
Senariy |
Nogiron shartlari |
Qayta tiklash mexanizmi |
Natija |
|---|---|---|---|
|
Kafka Partition Leader muammosi |
O'tkazish jarayonida o'qish brokeri majburiy to'xtatildi |
Kafka Controller ISR ichida boshqa brokerni o'qish uchun tanladi, Debezium avtomatik qayta ulanish |
✓ Yo'qolish yo'q |
|
Kafka Klasteri to'liq nosozligi |
Umumiy broker Podlarni o'chirish va qayta tarqatish |
Kafka Connect offset mavzusi (PVC saqlash) va PostgreSQL Replikatsiya sloti oxirgi LSN dan WAL ni davom ettirishga yordam beradi |
✓ Yo'qotish yo'q |
|
Debezium Connector nosozligi |
CDC ishlov berish paytida Connector majburiy tugatildi |
Replication Slotda yozilgan oxirgi LSN dan avtomatik ravishda WAL o'qishni davom ettirish |
✓ yo'qotish yo'q |
|
Kafka klasteri to'liq qayta taqsimlangandan so'ng ham ma'lumot yo'qotilishi bo'lmaganligi Kafka Connect offset mavzusi va PostgreSQL Replikatsiya Slotining birgalikda ishlashi tufaylidir. Offset mavzusi oxirgi qayta ishlangan Kafka joylashuvini, Replika sloti esa WALning LSN joylashuvini saqlab qolishga imkon berdi. Biroq, at-least-once xususiyatiga ko'ra qayta ishlash vaqtida takroriy hodisalar sodir bo'lishi mumkin, shuning uchun Data-Syncda UPSERT asosidagi idempotentlikni amalga oshirganimiz natijada ma'lumotlarning to'g'riligini saqlab qoldi. |
|---|
4. Xulosa: cheklovlar va o'rganilgan saboqlar, va kelajakda
◆ Dastlabki loyihaning cheklari
Ma'lumotlarni sinxronlashtirish uchun zarur bo'lgan ustun ma'lumotlarini Data-Sync ichki metadata jadvalida to'g'ridan-to'g'ri saqlash usulining cheklovlari aniq edi. Ma'lum bir xizmatga bir ustun qo'shilganda, Data-Sync ham o'zgartirilishi kerak bo'lgan tuzilma paydo bo'ldi va MSA'da maqsad qilingan xizmatning mustaqil bo'lishi ma'lumotlarni sinxronlashtirish qatlamida buzildi. Ushbu muammoni hal qilish uchun Confluent Schema Registry va Avro formatini joriy etish ko'rib chiqilmoqda. Debezium 3.x'da allaqachon rasmiy qo'llab-quvvatlanadigan funkcional bo'lib, uni qo'llasangiz, Debezium sxemani hodisalar bilan birga Schema Registry'ga avtomatik ravishda ro'yxatdan o'tkazadi va Data-Sync dinamik ravishda talqin qilishi mumkin bo'ladi, shunday qilib har bir xizmat Data-Sync'dan mustaqil ravishda sxemani o'zgartirish imkoniyatiga ega bo'ladi.
◆ Debezium 3.xning asosiy o'zgarishlari (2024~2025)
|
versiya |
Asosiy o'zgarish |
Boshqaruv nuqtai nazaridan ma'no |
|---|---|---|
|
3.1 (2025.04) |
Management Platform rasmiy chiqishi (Kubernetes UI) |
curl orqali Podga to'g'ridan-to'g'ri ulanish usuli → GUI bilan almashtirilishi mumkin |
|
3.4 (2025.12) |
PostgreSQL 17 Failover Slot · PG 18 qo'llab-quvvatlash · Kafka 4.1 · OpenLineage integratsiyasi |
DB failover paytida Slot avtomatik o'tkazish · pg_replication_slotsni monitoring qilish zarur |
|
AI birlashtirish |
LLM·vektor DB bilan integratsiya qilingan AI modulini qo'shish (Debezium Server Sink) |
CDC ma'lumotlarni ko'chirish vositasidan AI quvurlari qavatiga o'zgarayotgan |
|
Ushbu usulning eng katta afzalligi eski tizimlarni o'zgartirmasdan ma'lumotlar oqimini nazorat qilish imkoniyatidir. MSA o'tkazish kabi ikki tizim birga yashashi kerak bo'lgan holatlar, shuningdek, keshni yangilash, qidiruv indekslash, tadbirga asoslangan arxitektura kabi turli kontekstlarda qo'llanilishi mumkin bo'lgan yondashuv ekanligini o'yladim. Ushbu loyiha CDC bilan birinchi bor tanishayotganlar yoki shunga o'xshash ma'lumotni sinkronizatsiya qilish muammolari haqida o'ylayotganlarga biroz bo'lsa-da yordam berishini umid qilaman. |
|---|
Taqdim etilgan adabiyotlar
[1] Debezium rasmiy hujjati, debezium.io/documentation/reference/3.4
[2] Debezium 3.1~3.4 chiqish eslatmalari, debezium.io/blog
[3] Confluent Schema Registry, docs.confluent.io/platform/current/schema-registry
Juno