Үйлдвэрлэлийн орчинд PostgreSQL-ийг удирдаж буй Мэдээллийн сангийн администраторууд (DBA) болон DevOps инженерүүдийн хувьд Сэргээх цэгийн зорилтыг (RPO) тэгтэй ойртуулах нь үндсэн үүрэг юм. PostgreSQL-ийн гамшгаас хамгаалах болон Цаг хугацааны цэгээр сэргээх (PITR) чадамжийн гол цөм нь Write-Ahead Logging (WAL) буюу Урьдчилсан бичилтийн бүртгэл юм. WAL нь гүйлгээг өгөгдлийн файлд бичихээс өмнө бүртгэх замаар ACID-ийн нийцлийг хангадаг бол WAL архивлалт нь эдгээр бүртгэлийг урт хугацааны нөөцлөлт болон хуулбарлалтад зориулан хадгалдаг механизм юм.
Гэсэн хэдий ч WAL архивлалтыг тохируулах нь “тохируулаад л мартах” ажил биш юм. Буруу тохиргоо, чимээгүй алдаанууд болон архитектурын буруу ойлголтууд нь өгөгдлийн их хэмжээний алдагдал, “split-brain” (хоёр тал зэрэг ажиллах) нөхцөл байдал эсвэл мэдээллийн сан бүрэн зогсоход хүргэж болзошгүй.
Энэхүү иж бүрэн гарын авлагад бид PostgreSQL WAL архивлалтын архитектурыг судалж, өгөгдөл алдагдахад хүргэдэг хамгийн түгээмэл алдаануудыг тодорхойлж, мэдээллийн сангийнхаа тэсвэрлэх чадварыг хангах үйлдвэрлэлийн түвшний шилдэг туршлагуудыг тоймлох болно.
PostgreSQL WAL архитектурыг ойлгох нь
Алдаануудыг судлахаасаа өмнө PostgreSQL гүйлгээний бүртгэлийг хэрхэн зохицуулдгийг ойлгох нь чухал юм.
PostgreSQL бүх өөрчлөлтийг pg_wal лавлахад (10-аас өмнөх хувилбаруудад pg_xlog гэдэг байсан) байрлах WAL сегментүүдэд (анхдагчаар 16МБ файлууд) бичдэг. Гүйлгээ бүрийг Лог дарааллын дугаараар (LSN) тэмдэглэн дарааллаар нь бүртгэдэг.
WAL сегмент дүүрэх үед PostgreSQL шинэ сегмент рүү шилждэг. pg_wal лавлахыг хязгааргүй томрохоос сэргийлэхийн тулд PostgreSQL нь осол сэргээлт эсвэл хуулбарлалтад шаардлагагүй болсон хуучин WAL сегментүүдийг дахин ашиглах эсвэл устгадаг.
WAL Архивлалт нь энэхүү дахин ашиглах үйл явцыг тасалдаг. archive_mode идэвхжсэн үед PostgreSQL нь дууссан WAL сегментийг устгах эсвэл дахин бичихээс өмнө аюулгүй, хоёрдогч байршил руу хуулахын тулд хэрэглэгчийн тодорхойлсон archive_command-ыг (эсвэл PostgreSQL 15+ хувилбарт archive_library-г) гүйцэтгэдэг.
Цаг хугацааны цэгээр сэргээх (PITR) үйлдэл хийхийн тулд танд хоёр бүрэлдэхүүн хэсэг хэрэгтэй:
1. Хүчинтэй үндсэн нөөцлөлт (base backup).
2. Үндсэн нөөцлөлт хийсэн цагаас эхлэн таны сэргээх гэж буй зорилтот цаг хүртэлх тасралтгүй үргэлжилсэн архивлагдсан WAL файлуудын гинжин хэлхээ.
Хэрэв тэрхүү WAL гинжин хэлхээ тасарвал таны PITR амжилтгүй болно.
Үйлдвэрлэлийн орчинд WAL архивлалтыг тохируулах
WAL архивлалтыг идэвхжүүлэхийн тулд та postgresql.conf файлаа өөрчлөх ёстой. Үндсэн тохиргоонд wal_level-ийг тохируулах, archive_mode-ийг идэвхжүүлэх, мөн archive_command-ыг тодорхойлох шаардлагатай.
# postgresql.conf
wal_level = replica # 'replica' эсвэл 'logical' нь архивлахад шаардлагатай
archive_mode = on # Архивлагч процессыг идэвхжүүлнэ
archive_command = 'test ! -f /mnt/nfs/archive/%f && cp %p /mnt/nfs/archive/%f'
archive_timeout = 600 # 10 минут тутамд WAL шилжилтийг албадан хийнэ
archive_command-д:
* %p нь архивлагдах WAL файлын бүтэн замыг илэрхийлнэ.
* %f нь WAL файлын нэрийг илэрхийлнэ.
Дээрх тохиргоо нь энгийн мэт боловч байгууллагын түвшинд зөвхөн энгийн shell командууд дээр найдах нь томоохон эрсдэлүүдийг дагуулдаг.
WAL архивлалтын нийтлэг алдаанууд
Алдаа 1: archive_command-ын “Чимээгүй амжилт”
PostgreSQL нь бүхэлдээ archive_command-ын гаралтын код (exit code) дээр тулгуурладаг. Хэрэв команд 0 гэсэн код буцаавал PostgreSQL нь WAL файлыг аюулгүй архивлагдсан гэж үзээд эх файлыг дахин ашиглахаар устгадаг.
Түгээмэл гардаг алдаа бол өгөгдөл нь байнгын хадгалах төхөөрөмж рүү аюулгүй бичигдээгүй байсан ч 0 гэсэн код буцаадаг командыг ашиглах явдал юм. Жишээлбэл, энгийн cp команд нь өгөгдөл очих серверийн OS хуудасны кэш (page cache) рүү орох даруйд амжилттай гэж үзэн код буцааж болно. Хэрэв кэш диск рүү бичигдэхээс өмнө очих сервер унтарвал WAL файл алдагдах боловч PostgreSQL өөрийн локал хуулбарыг аль хэдийн устгасан байдаг.
Эрсдэл: WAL гинжин хэлхээ тасрах, PITR хийх боломжгүй болох бөгөөд энэ нь зөвхөн гамшгаас сэргээх үед л илэрдэг.
Бууруулах арга: Архивлалтын скриптээ синхрон бичилт хийдэг эсэхийг баталгаажуулна уу. Хэрэв стандарт shell команд ашиглаж байгаа бол өгөгдөл бүрэн бичигдсэнийг баталгаажуулдаг хэрэгслүүдийг ашиглах эсвэл шилжүүлгийн дараа файлын хэмжээ болон хяналтын нийлбэрийг (checksum) шалгадаг wrapper скрипт бичээрэй.
Алдаа 2: pg_wal хуваалтын дүүрэлт (WAL-ийн хэт томролт)
Хэрэв archive_command (сүлжээний тасалдал, буруу зөвшөөрөл эсвэл очих диск дүүрсэн зэргээс шалтгаалан) амжилтгүй болж, тэгээс ялгаатай код буцаавал PostgreSQL нь WAL файлыг pg_wal лавлахад хадгалж, командыг дахин дахин оролдсоор байх болно.
Энэ нь архивлагдаагүй WAL-уудыг устгахгүй байх замаар өгөгдөл алдагдахаас сэргийлдэг ч хүртээмжийн ноцтой эрсдэлийг үүсгэдэг. Хэрэв pg_wal лавлах нь 100% дүүрсэн хуваалт дээр байрлаж байвал PostgreSQL нь PANIC алдаа гаргаж, зогсох болно. Зай чөлөөлөгдөх хүртэл мэдээллийн сан дахин асахгүй.
Эрсдэл: pg_wal хуваалт дүүрснээс болж мэдээллийн сан бүрэн зогсох.
Бууруулах арга:
1. pg_wal-ийг үргэлж тусгай дискний хуваалт дээр байрлуул.
2. pg_wal лавлахын хэмжээнд хяналт (monitoring) тавь.
3. Амжилтгүй болсон архивлалтын командыг нэн даруй илрүүлэхийн тулд pg_stat_archiver харагдацыг хяна.
Алдаа 3: Бүрэн бус үндсэн нөөцлөлт
Үндсэн нөөцлөлт нь нөөцлөлтийн явцад үүссэн WAL файлуудгүйгээр ямар ч хэрэггүй. Хэрэв та файлын системийн түвшний агшин зуурын зураг (snapshot) авч байгаа эсвэл WAL-уудыг дамжуулалгүйгээр (-X stream) pg_basebackup ашиглаж байгаа бол нөөцлөлтийн эхлэл болон төгсгөлийн хооронд үүссэн WAL файлуудыг амжилттай архивлагдсаныг баталгаажуулах ёстой.
Хэрэв таны архивлагч удаашралтай эсвэл алдаатай ажиллаж, тухайн WAL файлууд алдагдвал үндсэн нөөцлөлтийг тогтвортой төлөвт оруулах боломжгүй болно.
Эрсдэл: Гэмтсэн эсвэл сэргээх боломжгүй үндсэн нөөцлөлт.
Бууруулах арга: Шаардлагатай WAL файлуудыг нөөцлөлтийн багцад оруулахын тулд pg_basebackup -X stream ашиглах эсвэл үндсэн нөөцлөлт болон WAL сегментүүдийн хамаарлыг автоматаар удирддаг байгууллагын түвшний нөөцлөлтийн шийдлүүдийг ашиглаарай.
Алдаа 4: Цагийн шугамын (Timeline) төөрөгдөл ба Split-Brain нөхцөл байдал
Standby сервер нь Primary болж дэвших үед PostgreSQL нь “Timeline ID”-г (WAL файлын нэрний эхний хэсэг, жишээ нь: 0000000200000001000000A4) нэмэгдүүлдэг. Энэ нь шинэ Primary-г хуучин Primary-ийн WAL түүхийг дахин бичихээс сэргийлдэг.
Гэсэн хэдий ч, хэрэв хуучин Primary-г зохих ёсоор тусгаарлалгүйгээр (fencing) санамсаргүйгээр асаавал (split-brain нөхцөл байдал), энэ нь хуучин цагийн шугамыг ашиглан ижил архивын байршил руу WAL файл илгээхийг оролдож болзошгүй. Хэрэв таны archive_command файлуудыг сохроор дарж бичдэг бол та архивын сангаа гэмтээж болно.
Эрсдэл: Дарагдаж бичигдсэн WAL файлууд, гэмтсэн архивууд болон сэргээх боломжгүй мэдээллийн сан.
Бууруулах арга: Таны archive_command хэзээ ч байгаа файлыг дахин бичиж болохгүй. Өмнөх үндсэн тохиргоонд бид файл аль хэдийн байгаа бол алдаа гаргахын тулд test ! -f /mnt/nfs/archive/%f командыг ашигласныг анхаарна уу.
Өгөгдөл алдагдах эрсдэлийг бууруулах: Үйлдвэрлэлийн шилдэг туршлагууд
PostgreSQL архивлалтын стратегиа бэхжүүлэхийн тулд дараах шилдэг туршлагуудыг хэрэгжүүлээрэй.
1. Архивлагч процессыг уугуул байдлаар хянах
PostgreSQL нь архивлалтын үйл явцын амжилт болон алдааг хянадаг pg_stat_archiver гэсэн суурилагдсан харагдацтай. Та энэ харагдацыг өөрийн ажиглалтын стек (жишээ нь: Prometheus, Datadog, эсвэл Zabbix) дотор нэгтгэх хэрэгтэй.
SELECT
archived_count,
last_archived_wal,
last_archived_time,
failed_count,
last_failed_wal,
last_failed_time,
stats_reset
FROM pg_stat_archiver;
Тохируулах сэрэмжлүүлгийн босго:
* failed_count нэмэгдвэл сэрэмжлүүлэг өгөх.
* now() болон last_archived_time хоорондын зөрүү таны RPO босгыг (жишээ нь: 15 минут) давсан тохиолдолд сэрэмжлүүлэг өгөх (archive_timeout тохируулаагүй бол бага ачаалалтай мэдээллийн сангуудад саатал гарч болзошгүйг анхаарна уу).
2. archive_timeout-ийг ашиглах
Бичилтийн хэмжээ багатай мэдээллийн сангуудад 16МБ WAL файл дүүрэхэд хэдэн цаг зарцуулагдаж болно. Дүүрэх хүртэл нь архивлагддаггүй. Хэрэв сервер унаж, локал диск алдагдвал та хэдэн цагийн гүйлгээг алдах болно.
archive_timeout = 600 (10 минут) гэж тохируулах нь PostgreSQL-ийг дүүрээгүй байсан ч шинэ WAL файл руу шилжиж, одоогийн файлыг архивлахад хүргэдэг. Энэ нь хагас дүүрсэн WAL файлуудаас шалтгаалан хадгалах сангийн ашиглалт бага зэрэг нэмэгдэх боловч таны RPO 10 минутаас хэтрэхгүй байх баталгаа болно.
3. archive_library руу шилжих (PostgreSQL 15+)
Түүхэндээ archive_command нь WAL файл бүрт шинэ shell процесс үүсгэдэг байсан. Минутанд олон зуун WAL файл үүсгэдэг өндөр ачаалалтай орчинд shell процесс үүсгэх нь гүйцэтгэлийн саад болдог.
PostgreSQL 15 нь archive_library параметрийг нэвтрүүлснээр WAL архивлалтыг динамикаар ачаалагдсан C модулиудаар удирдах боломжтой болсон. Энэ нь shell-forking-ийн ачааллыг арилгаж, илүү бат бөх, өндөр гүйцэтгэлтэй архивлалтын механизмыг хангадаг. Хэрэв та PostgreSQL 15 буюу түүнээс дээш хувилбар ашиглаж байгаа бол захиалгат архивын модулиудыг дэмждэг нөөцлөлтийн хэрэгслүүдийг хайж олоорой.
4. Цаг хугацааны цэгээр сэргээх (PITR) туршилтыг тогтмол хийх
Туршигдаагүй нөөцлөлт бол нөөцлөлт биш, зүгээр л хүсэл юм. Таны WAL архивлалт зөв ажиллаж байгаа, WAL гинжин хэлхээ тасраагүй, үндсэн нөөцлөлтүүд тогтвортой байгаа эсэхийг шалгах цорын ганц арга бол тогтмол, автоматжуулсан PITR туршилтуудыг хийх явдал юм.
Түр зуурын жишээ (instance) үүсгэж, үндсэн нөөцлөлтийг сэргээж, архиваас татахын тулд restore_command-ыг тохируулан, тодорхой цагийн цэг хүртэл сэргээлт хийгээрэй. Мэдээллийн сан тогтвортой төлөвт хүрч, холболтод нээгдэж байгаа эсэхийг шалгана уу.
CloudSave-ээр байгууллагын нөөцлөлт ба сэргээлт
archive_command-д зориулсан захиалгат shell скриптүүдийг удирдах, WAL-ийн давхардал арилгах (deduplication), гүйлгээний бүртгэлийг аюулгүй, гадны байршилд хадгалах нь IT багуудын хувьд үйл ажиллагааны дарамт болж хувирдаг.
Энд л CloudSave нь байгууллагын PostgreSQL орчинд ихээхэн үнэ цэнийг өгдөг. CloudSave нь PostgreSQL-ийн уугуул нөөцлөлт болон WAL архивлалтын API-уудтай шууд нэгдэн дээр дурдсан гар ажиллагааны алдаануудыг арилгадаг.
Эвдрэх магадлалтай bash скрипт бичихийн оронд CloudSave нь дараах боломжуудыг олгодог бат бөх, агент дээр суурилсан эсвэл агентгүй интеграцийг хангадаг:
* Хүргэлтийн баталгаа: Стандарт shell командудыг аюулгүй, гадны эсвэл үүлэн хадгалах сан руу хяналтын нийлбэрээр баталгаажсан шилжүүлгээр сольдог.
* WAL-ийн хэт томролтоос сэргийлдэг: pg_wal лавлахыг идэвхтэй хянаж, хуваалт дүүрэхээс өмнө администраторуудад сэрэмжлүүлэг өгдөг.
* PITR-ийг автоматжуулдаг: Цаг хугацааны цэгээр сэргээх үйлдлийг ойлгомжтой интерфэйсээр хялбаршуулдаг. Та сэргээхийг хүсэж буй яг тодорхой минутаа сонгоход CloudSave нь зөв үндсэн нөөцлөлтийг автоматаар татаж, тухайн төлөвт хүрэхэд шаардлагатай WAL файлуудын дарааллыг дамжуулдаг.
* Цагийн шугамыг удирддаг: PostgreSQL-ийн цагийн шугамын түүхийг ухаалгаар удирдаж, failover болон split-brain нөхцөл байдал нь таны нөөцлөлтийн санг гэмтээхгүй байхыг баталгаажуулдаг.
WAL удирдлагын хүнд ачааг CloudSave-д шилжүүлснээр DBA-ууд RPO болон RTO SLA-ууд нь байгууллагын түвшний платформд хамгаалагдсан гэдгийг мэдэж, асуулгын оновчлол болон мэдээллийн сангийн гүйцэтгэлд анхаарлаа төвлөрүүлэх боломжтой болно.
Дүгнэлт
PostgreSQL WAL архивлалт нь мэдээллийн сангийн гамшгаас сэргээх үйл ажиллагааны гол тулгуур юм. Файлыг нэг лавлах руу хуулах нь энгийн мэт санагдавч, чимээгүй алдаанууд, дискний дүүрэлт, цагийн шугамын зөрүү зэрэг нь өгөгдлийн бүрэн бүтэн байдалд ноцтой эрсдэл учруулдаг.
pg_wal-ийн архитектурыг ойлгож, archive_command-ын сүйтгэх тохиргооноос хатуу зайлсхийж, pg_stat_archiver-ийг хянаж, CloudSave зэрэг байгууллагын нөөцлөлтийн платформуудыг ашигласнаар та техник хангамжийн эвдрэл, хүний алдаа, гамшгийн үед ч нэг ч гүйлгээ алдахгүйгээр тэсвэрлэх чадвартай PostgreSQL дэд бүтцийг байгуулж чадна.
Өгөгдөл алдагдахад хүргэдэг PostgreSQL WAL архивлалтын нийтлэг алдаануудыг олж мэдээрэй. DBA-ийн шилдэг туршлагууд, тохиргооны зөвлөмжүүд болон байгууллагын мэдээллийн санд зориулсан Цаг хугацааны цэгээр сэргээх (PITR) найдвартай ажиллагааг хэрхэн хангах талаар суралцаарай.
