PostgreSQL backup байхад ч минут алдана: PITR-д WAL тасарч болохгүй

PostgreSQL-ийг тодорхой мөчид сэргээхийн тулд файлын түвшний base backup авч, backup эхэлснээс зорилтот мөч хүртэлх WAL дарааллыг бүрэн хадгална. Сэргээхдээ backup-ийг тусгаар орчинд байрлуулж, WAL-ийг сонгосон цэг хүртэл дахин тоглуулна. PostgreSQL-ийн PITR заавар энэ аргаар бүх кластер сэргээгддэгийг тайлбарладаг; pg_dump болон pg_dumpall-ийн логик хуулбар WAL replay-д хэрэгтэй файлын backup болж чаддаггүй.

Зөв дараалал нь WAL архивыг эхэлж ажиллуулах, дараа нь base backup авах, архивын хоцрогдол ба тасралтыг хянах, эцэст нь recovery target тавьж турших юм. Backup бүрэн байсан ч түүнээс хойших WAL-ийн шаардлагатай сегмент алга бол сонгосон мөчид хүрэх боломжгүй. Архивласан хамгийн сүүлийн өөрчлөлтөөс хойш хэдэн минут өнгөрсөн бол тэр хугацааны бичилт сэргээгдэхгүй үлдэж болно.

WAL архивыг backup-аас өмнө ажиллуул

Үндсэн серверийн postgresql.conf файлд wal_level = 'replica', archive_mode = 'on' гэж тохируулж, дууссан WAL сегментийг өөр хадгалах сан руу шилжүүлэх archive_command өгнө. archive_mode болон wal_level нь сервер эхлэхэд хэрэгждэг тул өөрчилсөн бол PostgreSQL-ийг дахин эхлүүлнэ. Архивын сан руу серверийн хэрэглэгч бичиж, сэргээх орчин уншиж чаддаг байх шаардлагатай. Үндсэн өгөгдөлтэй хамт алдагдах нэг диск дээр архивын ганц хуулбарыг байршуулах нь сэргээх төлөвлөгөөг сулруулна.

Unix орчинд, урьдчилан үүсгэсэн сан руу хуулах жишээ нь archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' юм. Энд %p нь эх файлын зам, %f нь архивт хадгалах нэр. Энэ энгийн команд ижил нэртэй файл байвал дарж бичихгүй ч өмнө нь амжилттай архивлагдсан файлыг PostgreSQL дахин илгээхэд алдаа буцаана. Ашиглалтын команд ийм тохиолдолд хоёр файлын агуулга ижил бөгөөд архивын хуулбар найдвартай хадгалагдсан эсэхийг шалгаж байж амжилт гэж үзэх ёстой.

Архивлах команд зөвхөн хаагдсан WAL сегментэд ажиллана. Бичилт багатай үед сегмент нээлттэй удаж болох учир archive_timeout = '60s' гэх мэт тохиргоо үе үе сегмент солиход тусална. Энэ нь өгөгдөл алдах хугацааны хатуу баталгаа биш: архивын сан руу хуулах саатал, командын алдаа нэмэгдэнэ. Хугацааг хэт богиносговол дутуу дүүрсэн сегмент ч бүтэн хэмжээтэй хадгалагдаж, архивын зай хурдан өснө.

Base backup-ийн WAL горим ба давтамжийг сонго

Архив ажиллаж эхэлснийг шалгасны дараа REPLICATION эрхтэй, pg_hba.conf-д зөвшөөрөгдсөн хэрэглэгчээр pg_basebackup -h PRIMARY_HOST -U backup_user -D /backup/base_01 -Fp -X stream -P командыг ажиллуулна. PRIMARY_HOST болон backup_user нь өөрийн орчинд солих утга; очих сан байхгүй эсвэл хоосон байх ёстой. -Fp нь backup-ийг файлын бүтцээр хадгалж, -P нь явцыг харуулна. Нэмэлт tablespace ашигладаг бол backup авах болон дараа нь сэргээх замыг мөн төлөвлөнө.

pg_basebackup-ийн зааварт тайлбарласнаар -X stream нь backup авч байх зуур шаардлагатай WAL-ийг зэрэг дамжуулдаг бөгөөд хоёр replication холболт хэрэглэнэ. -X fetch нь WAL-ийг төгсгөлд нь авдаг тул тухайн сегментүүд үндсэн серверээс арчигдаагүй байх шаардлагатай; -X none нь WAL-ийг backup-д багтаахгүй. Stream горим backup-ийг эхлүүлэхэд хэрэгтэй WAL-ийг хамт өгдөг. Харин backup дууссанаас хойших мөчид хүрэхэд үргэлжилсэн архив хэрэгтэй.

RPO буюу зөвшөөрөх өгөгдлийн алдагдлын хугацаа base backup авах давтамжтай шууд тэнцүү биш. Жишээ нь таван минутын RPO зорьсон ч таван минут тутам бүтэн base backup авах шаардлагагүй; харин архивын бодит хоцрогдол энэ зорилгод багтаж, шаардлагатай WAL дараалал бүрэн байх ёстой. Base backup-уудын хоорондын зайг хадгалах багтаамж болон сэргээх үед хэдий хэмжээний WAL дахин тоглуулахыг зөвшөөрөхөөс хамааруулна.

Хуучин backup-ийг устгахаасаа өмнө түүнээс хамаарах WAL-ийн хадгалах хугацааг тооц. Сонгосон сэргээх мөч нь ашиглах base backup дууссанаас хойш байх ёстой. Хэрэв устгал тэр backup үргэлжилж байх үед болсон бол түүнээс өмнө дууссан backup хэрэгтэй. Иймээс хадгалах бодлогод backup файл төдийгүй түүнд холбогдох WAL болон шаардлагатай timeline history файлууд хамт багтана.

Архивын хоцрогдол, тасралтыг хяна

pg_stat_archiver харагдцын archived_count, last_archived_wal, last_archived_time, failed_count утгууд архивлагч ажиллаж байгаа эсэхийг ажиглахад тустай. Гэхдээ хамгийн сүүлд архивлагдсан файлын нэрээс өмнөх бүх сегмент байгаа гэж дүгнэж болохгүй. Архивын сан дахь файлуудыг backup-ийн шаардлагатай WAL хүрээтэй тулгаж, завсрын файл алга эсэхийг шалгана.

Бичилт багатай серверт last_archived_time хуучин байх нь дангаараа алдаа биш. Хяналтын туршилтаар бичилт хийж, дараа нь SELECT pg_switch_wal(); ажиллуулаад шинэ сегмент архивт очихыг хүлээж болно. Хэрэв failed_count өсөх эсвэл pg_wal-д архивлагдаагүй файлууд хуримтлагдвал командын алдаа, сангийн эрх, сул зай болон дамжуулах хугацааг шалгана. Зарим төрлийн архивлагчийн алдаа pg_stat_archiver-ийн тоолуурт орохгүй тул серверийн бүртгэлийг мөн хянах хэрэгтэй.

RPO-г хэмжихдээ хамгийн сүүлийн амжилттай архивлалтын цагийг одоогийн цагтай харьцуулахаас гадна тухайн файл бодитоор сэргээх орчноос уншигдаж байгаа эсэхийг үз. Архивын команд амжилт буцаасан ч файл хадгалах сангаас буцаан авах боломжгүй бол тэр цэгт сэргээх боломжгүй. WAL-ийн тасралт болон архивын хоцрогдлыг тус тусад нь хянах нь энэ ялгааг ил гаргана.

Устгалын өмнөх мөчид тусгаар орчинд сэргээ

Буруу үйлдэл commit болсон цагийг өгөгдлийн сан болон програмын бүртгэлээр тогтоож, түүнээс өмнөх recovery target сонгоно. Сонгосон target нь base backup дууссанаас хойш байх ёстой. Үндсэн сервер дээр туршихын оронд ижил major хувилбарын тусгаар PostgreSQL инстанц ашиглаж, backup болон архивын эх хувийг хадгалан үлдээнэ.

1. Тусгаар инстанцыг зогсоож, өгөгдлийн хоосон хавтсанд сонгосон base backup-ийн хуулбарыг байрлуул. Файлын эзэмшигч, эрх болон tablespace-ийн холбоос, замыг шалга. -X stream-ээр ирсэн pg_wal файлуудыг дур мэдэн устгахгүй; архивт хараахан очоогүй, тусад нь хадгалсан WAL байвал сэргээх хуулбартаа нэмнэ.
2. Сэргээх орчны postgresql.conf файлд restore_command = 'cp /mnt/server/archivedir/%f %p' болон recovery_target_time-г өг. Нөхцөлт жишээ: устгал 2026-09-15 14:30:00+08-д commit болсон нь тогтоогдвол recovery_target_time = '2026-09-15 14:30:00+08', recovery_target_inclusive = off гэж тавьснаар яг тэр цагт commit болсон үйлдлийг сэргээх цэгээс хасна. Бодит target-ийг бүртгэлийн цагийн бүс, нарийвчлалд тааруул.
3. Өгөгдлийн үндсэн хавтсанд хоосон recovery.signal файл үүсгээд инстанцыг эхлүүл. Хэрэглэгчдийг хугацаанаас өмнө холбохгүйн тулд сэргээх орчны pg_hba.conf-ийг хязгаарла. Зорилтот цэгт түр зогсоож шалгах бол recovery_target_action = 'pause' хэрэглэж болно; уншиж шалгах холболтод hot_standby идэвхтэй байх шаардлагатай.

Сэргээх зорилтын тохиргоо нь recovery_target_time, recovery_target_inclusive болон зорилтод хүрмэгц хийх үйлдлийг тусад нь удирдана. Зорилтот цэгт хүрэхээс өмнө шаардлагатай WAL дуусвал сэргээх процесс алдаатай зогсоно. Ийм үед архивын эх хувь болон үндсэн серверээс хадгалж авсан, хараахан архивлагдаагүй WAL-ийг шалгана; байхгүй сегментийг өөр backup файл нөхөхгүй.

Сэргээх туршилтаар үр дүнг тогтоо

Тусгаар орчны туршилт backup-ийг задлах, WAL-ийг буцаан унших, target-д хүрэх бүх алхмыг хамтад нь шалгана. Сонгосон мөчөөс өмнө байсан өгөгдөл сэргэсэн, дараах буруу өөрчлөлт ороогүй эсэхийг өгөгдлийн агуулга болон сэргээх бүртгэлээр нягтал. Түр зогссон сэргээх процессыг үргэлжлүүлэх эсвэл дахин эхлүүлэх шийдвэрийг энэ шалгалтын дараа гаргана.

Туршилтад зарцуулсан хугацаа нь base backup-уудын хооронд хэр их WAL дахин тоглуулах боломжтойг харуулна. Харин архивын сүүлийн найдвартай цэг нь хэдий хэмжээний шинэ өгөгдөл алдагдаж болохыг харуулна. Эдгээрийг тусад нь хэмжсэнээр backup авах давтамж, WAL хадгалах хугацаа, архивын саатлын дохиог бодит сэргээх шаардлагад тааруулж болно.

Мөн уншаарай:

• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө
• PostgreSQL эсвэл MySQL: benchmark-ийн ялагч workload солигдоход өөрчлөгдөнө