Checkpoint — database yoki stateful tizim o‘zining ma’lum vaqtdagi barqaror holatini qayd etadigan nuqta. Database’da u odatda xotiradagi o‘zgargan sahifalarni storage’ga yozish va transaction logida recovery qayerdan boshlanishini belgilash bilan bog‘liq.
WAL bilan ishlashi
Write-Ahead Logging ishlatadigan database avval o‘zgarish logini durable saqlaydi, data page esa keyinroq yozilishi mumkin. Crash’dan so‘ng log boshidan emas, oxirgi tegishli checkpointdan boshlab qayta ko‘riladi. Bu recovery vaqtini cheklaydi.
Checkpoint boshlanganida tizim dirty bufferlarni darhol bir lahzada yozib tugatishi shart emas. Ko‘p engine yozuvlarni interval bo‘ylab tarqatadi, shunda birdan katta IO spike paydo bo‘lmaydi. Checkpoint recordi qaysi log pozitsiyasi va transaction holati recovery uchun kerakligini ko‘rsatadi.
Fuzzy checkpoint
Faol database barcha transactionlarni to‘xtatib, mutlaq bir xil oniy surat yaratishi qimmat. Fuzzy checkpoint vaqtida application write davom etadi, dirty page’lar turli vaqtda diskka tushadi. WAL qoidasi har page’dan oldin tegishli log yozuvi flush bo‘lishini ta’minlaydi. Recovery log orqali noaniq oralig‘ni to‘g‘ri yakunlaydi.
Shu sabab checkpoint database backupining aynan o‘zi emas. U lokal crash recoveryni tezlashtiradi. Disk, cluster yoki sayt yo‘qolsa, mustaqil backup va archived loglar talab qilinadi.
Chastota va xarajat
Juda kam checkpoint logning ko‘p qismini recoveryda replay qilishga va WAL segmentlarini uzoq saqlashga olib keladi. Juda tez checkpoint ko‘p data page yozadi, ayni page bir necha marta dirty bo‘lsa write amplificationni oshiradi. IO latency va cache samaradorligi pasayishi mumkin.
Database vaqt intervali, yozilgan WAL hajmi yoki manual buyruq bo‘yicha checkpoint boshlashi mumkin. Sozlama workload, storage throughput va recovery time objective bilan tanlanadi. “Har daqiqada checkpoint” universal yaxshi qiymat emas.
Full-page write
PostgreSQL kabi tizimlarda checkpointdan keyingi sahifaning birinchi o‘zgarishi WALga full-page image yozishi mumkin. Bu torn page’dan himoya qiladi, ammo checkpointdan keyin WAL generation qisqa oshadi. Checkpoint juda tez-tez bo‘lsa full-page write soni ham ko‘payadi.
Storage atomic write va checksum xususiyatlari engine dizayniga ta’sir qiladi. Qurilma flushni noto‘g‘ri tasdiqlasa, database algoritmi kutilgan durabilityni bera olmaydi.
Replikatsiya va recovery
Standby WALni replay qilayotganda checkpoint recordlari uning restart nuqtasiga ta’sir qiladi. Replication slot yoki archive eski logni ushlab qolishi mumkin; checkpoint bo‘ldi deb WALni o‘chirib yuborish mumkin emas. Har consumerning minimal kerakli log pozitsiyasi hisobga olinadi.
Point-in-time recovery maqsadida base backup bilan undan keyingi WAL zanjiri saqlanadi. Checkpoint backup boshlanishi va yakunini muvofiqlashtirishda ishtirok etadi, lekin recovery target timestamp yoki LSN bo‘yicha tanlanadi.
Monitoring
Checkpoint soni, davomiyligi, yozilgan bufferlar, forced/requested checkpoint, WAL generation va storage latency kuzatiladi. Tez-tez forced checkpoint odatda WAL limit yoki sozlama workloadga mos emasligini ko‘rsatadi. Uzoq checkpoint recovery emas, foreground query latency’siga ham ta’sir qilishi mumkin.
Sozlama o‘zgarishi load test bilan tekshiriladi. Crash recovery mashqida real replay vaqti o‘lchanadi; faqat checkpoint logidagi “completed” xabari RTO bajarilishini isbotlamaydi.
Checkpoint chastotasi tizim yukiga mos tanlanadi. Juda tez-tez checkpoint yaratish disk yozuvlarini ko‘paytiradi, juda siyrak yaratish esa tiklanishda qayta ijro etiladigan log oralig‘ini uzaytiradi. Kuzatuvda checkpoint davomiyligi va logning o‘sish tezligi birga baholanadi.
Bog‘liq tushunchalar
Write-Ahead Log, Crash recovery, Dirty page, Buffer cache, LSN, Point-in-time recovery, Full-page write, Durability