Logical replication — storage bloklarini aynan ko‘chirish o‘rniga database logidan jadval darajasidagi insert, update va delete kabi mantiqiy o‘zgarishlarni ajratib, subscriberga yetkazish usuli. U tanlangan jadvallarni uzatish, boshqa versiya yoki schema tuzilishiga moslashish imkonini beradi, ammo schema va identity boshqaruvini operator zimmasiga ko‘proq yuklaydi.
Oqim tuzilishi
Publisher write-ahead log yoki binlogni decode qilib, o‘zgarishni table, column va row identity bilan ifodalaydi. Subscription dastlabki snapshotni ko‘chirishi, keyin snapshot olingan nuqtadan change streamni davom ettirishi mumkin. Transaction chegarasi va commit tartibi saqlanishi mahsulot hamda konfiguratsiyaga bog‘liq.
Subscriber odatda o‘z local storage formatida yozadi. Shu sabab physical replicationdan farqli ravishda butun database clusterining byte-for-byte nusxasi talab etilmaydi.
Row identity
Update va delete subscriberda qaysi satrga tegishli ekanini aniqlashi kerak. Primary key eng qulay replica identitydir. Key bo‘lmasa tizim unique index, to‘liq oldingi row yoki umuman update uzatmaslik kabi cheklovga ega bo‘lishi mumkin. Katta rowning barcha ustunlarini identity sifatida yuborish log hajmini oshiradi.
Sequence, large object, materialized view va ayrim generated qiymatlar odatiy row streamga kirmasligi mumkin. Ular alohida sinxronlanadi yoki targetda qayta yaratiladi.
Schema muvofiqligi
Ko‘p logical replication tizimi DDLni avtomatik ko‘chirmaydi. Publisherga yangi column qo‘shishdan oldin subscriber schema mos holatga keltiriladi. Column turi, collation, default va constraint farqi apply xatosi yoki ma’no o‘zgarishiga sabab bo‘ladi. Migration ketma-ketligi oldindan sinovdan o‘tkaziladi.
Tanlab uzatish
Publication faqat kerakli jadvallarni, ba’zan row filter yoki column subsetni tanlaydi. Bu service decomposition, analytics ombori, online migration va data distributionda foydali. Filtrlangan nusxa to‘liq backup emas; foreign key bilan bog‘liq satrlar tushib qolsa target invariantlari buzilishi mumkin.
Conflict va monitoring
Bir tomonlama modelda subscriberga bevosita yozish conflict tug‘diradi. Multi-writer topologiyada bir xil key, update tartibi va delete bilan qayta yaratish uchun aniq resolution siyosati kerak. “Oxirgi yozuvchi yutadi” clock farqi va yo‘qolgan update xavfini keltiradi.
Monitoring decode lag, transport lag, apply lag, replication slot hajmi va failed transactionni ajratadi. Uzoq to‘xtagan subscriber publisher log diskini to‘ldirishi mumkin. Initial snapshot tugaganini va barcha jadvallar bir xil cutover positionga yetganini tekshirmasdan traffic ko‘chirilmaydi.
Online migration
Yangi databasega ko‘chishda avval schema va initial snapshot tayyorlanadi, so‘ng change stream targetni sourcega yaqinlashtiradi. Cutover oldidan write traffic qisqa to‘xtatiladi yoki dual-write qat’iy idempotency bilan boshqariladi. Target oxirgi source positionni apply qilgach endpoint ko‘chiriladi. Row countning tengligi yetarli tekshiruv emas; checksum, business invariant va sampled query natijalari solishtiriladi.
Reverse replication yoki rollback yo‘li oldindan loyihalanmasa yangi targetga tushgan yozuvlarni eski sourcega qaytarish qiyin. Shu sabab migration point-of-no-return belgilanadi. Triggerlar subscriberda yana side effect yaratishi mumkin; apply session triggerlarni o‘chiradimi yoki ularni bir marta bajarish kerakmi aniq sozlanadi. Audit bu jarayonda origin transaction IDni saqlaydi.
Logical streamdagi sensitive ustunlar targetga kerak bo‘lmasa publicationdan chiqariladi yoki ishonchli transformda maskalanadi. Transport encryption yetarli emas: subscriber IAM, retention va backup siyosati ham yangi data nusxasiga mos bo‘lishi kerak.
Bog‘liq tushunchalar
Physical replication, Change data capture, Publication, Subscription, Replica identity, Write-ahead log, Schema migration, Replication slot