Write-Ahead Log (WAL) — database data page’larini doimiy storage’da o‘zgartirishdan oldin shu o‘zgarishni qayta tiklashga yetarli log yozuvini barqaror saqlash usuli. “Log avval yoziladi” qoidasi crash’dan keyin committed transactionlarni redo qilish va tugallanmagan holatni boshqarish imkonini beradi.
Asosiy qoida
Transaction data page’ni memory bufferda o‘zgartiradi. Page diskdagi asosiy data file’ga yozilishidan oldin tegishli WAL record durable logga flush qilinadi. Commit muvaffaqiyatli deb javob berishdan oldin transaction commit recordi ham talab qilingan durability darajasida saqlanadi.
Shu tartib data page diskka qisman yoki kechroq yozilsa ham log orqali yangi holatni qayta qo‘llashga imkon beradi. Database har commitda barcha o‘zgargan data page’larni yozishi shart emas; ketma-ket WAL write random page write’dan samaraliroq bo‘ladi.
LSN va segmentlar
Logdagi pozitsiya Log Sequence Number kabi monoton identifikator bilan belgilanadi. Data page oxirgi qo‘llangan log pozitsiyasini saqlashi mumkin. Recovery page LSN bilan WAL recordni solishtirib, kerakli redo’ni aniqlaydi.
WAL odatda segment fayllarga bo‘linadi va aylanma lifecycle bilan boshqariladi. Checkpointdan hamda replica/backup ehtiyojidan eski segmentlar recycle yoki archive qilinadi. Replication slot yoki archive nosozligi eski WALni ushlab, diskni to‘ldirishi mumkin.
Crash recovery
Server to‘satdan to‘xtagach database oxirgi checkpointdan boshlab WALni o‘qiydi. Committed, ammo data page’ga hali yozilmagan o‘zgarishlar redo qilinadi. MVCC va engine dizayni tugallanmagan transactionlarni ko‘rinmas qiladi yoki undo mexanizmi bilan bekor qiladi.
WAL physical, logical yoki aralash ma’lumot saqlashi mumkin. PostgreSQL WAL asosan physical page-level o‘zgarishlarni qayd etadi; logical decoding undan row-level change stream hosil qiladi. MySQL InnoDB redo log va binary log boshqa vazifalarni bo‘lib bajaradi. Atamalar mahsulotlar orasida aynan bir xil emas.
Replication va backup
Streaming replication primary WAL recordlarini standbyga yuboradi, standby ularni replay qiladi. Replication lag logning yuborilishi, yozilishi, flush va replay bosqichlarida o‘lchanishi mumkin. Synchronous replication commitni standby acknowledgementiga bog‘lab data loss oynasini kamaytiradi, evaziga latency va availabilityga ta’sir qiladi.
Base backup bilan keyingi archived WAL segmentlari birga point-in-time recovery imkonini beradi. Faqat WAL fayllari to‘liq cluster metadata va boshlang‘ich data nusxasisiz yetarli bo‘lmasligi mumkin. Timeline, encryption key va retention birga boshqariladi.
Performance va durability
WAL write latency transaction commit latency’siga ta’sir qiladi. Group commit bir nechta transactionning flush talabini birlashtiradi. Fast storage, battery-backed cache va to‘g‘ri filesystem/barrier semantikasi muhim. Qurilma flushni yolg‘on tasdiqlasa database durability kafolati buziladi.
fsync yoki synchronous commitni o‘chirish performance berishi mumkin, ammo crash’da yaqindagi committed deb ko‘ringan transaction yo‘qolishi ehtimolini o‘zgartiradi. Bu qaror aniq risk va workload bo‘yicha qabul qilinadi.
Monitoring
WAL generation rate, flush latency, archive failure, retained segment hajmi, replication lag va disk free space kuzatiladi. Bulk update, index build va table rewrite juda ko‘p WAL yaratishi mumkin. Maintenance oldidan archive va replica capacity rejalashtiriladi.
Recovery faqat log mavjudligi bilan tasdiqlanmaydi. Base backupdan tiklash, WAL replay va target vaqtga yetish muntazam sinov qilinadi. Corrupt yoki yetishmagan bitta segment zanjirni uzishi mumkin, shuning uchun checksum, nusxa va archive monitoring talab etiladi.
Bog‘liq tushunchalar
Transaction log, Checkpoint, Crash recovery, Point-in-time recovery, Replication, LSN, Group commit, Durability