PostgreSQL WAL արխիվացում. տարածված թակարդներ և տվյալների կորստի ռիսկեր

Տվյալների բազայի ադմինիստրատորների (DBA) և DevOps ինժեներների համար, ովքեր կառավարում են PostgreSQL-ը արտադրական միջավայրում, զրոյին մոտ Վերականգնման կետի նպատակին (RPO) հասնելը հիմնական պահանջ է: PostgreSQL-ի աղետներից վերականգնման և ժամանակի որոշակի կետից վերականգնման (PITR) հնարավորությունների հիմքում ընկած է Write-Ahead Logging (WAL) գործառույթը: Մինչ WAL-ը ապահովում է ACID համապատասխանությունը՝ գրանցելով գործարքները նախքան դրանք տվյալների ֆայլերում գրվելը, WAL-ի արխիվացումը այն մեխանիզմն է, որը պահպանում է այդ գրանցամատյանները երկարաժամկետ պահուստավորման և ռեպլիկացիայի համար:

Այնուամենայնիվ, WAL արխիվացման կազմաձևումը «միացրու և մոռացիր» գործողություն չէ: Սխալ կազմաձևումները, աննկատ ձախողումները և ճարտարապետական թյուրիմացությունները կարող են հանգեցնել տվյալների կատաստրոֆիկ կորստի, «split-brain» սցենարների կամ տվյալների բազայի ամբողջական խափանումների:

Այս համապարփակ ուղեցույցում մենք կուսումնասիրենք PostgreSQL WAL արխիվացման ճարտարապետությունը, կբացահայտենք տվյալների կորստի հանգեցնող ամենատարածված թակարդները և կուրվագծենք արտադրական մակարդակի լավագույն փորձը՝ ձեր տվյալների բազայի կայունությունը ապահովելու համար:

Հասկանալով PostgreSQL WAL ճարտարապետությունը

Նախքան թակարդներին անդրադառնալը, կարևոր է հասկանալ, թե ինչպես է PostgreSQL-ը մշակում գործարքների գրանցամատյանները:

PostgreSQL-ը բոլոր փոփոխությունները գրում է WAL սեգմենտներում (կանխադրված՝ 16 ՄԲ ֆայլեր), որոնք գտնվում են pg_wal գրացուցակում (նախկինում՝ pg_xlog, 10-ից ցածր տարբերակներում): Յուրաքանչյուր գործարք գրանցվում է հաջորդաբար՝ նշված Գրանցամատյանի հաջորդականության համարով (LSN):

Երբ WAL սեգմենտը լցվում է, PostgreSQL-ը անցնում է նորին: pg_wal գրացուցակի անվերջ մեծացումը կանխելու համար PostgreSQL-ը վերամշակում կամ հեռացնում է հին WAL սեգմենտները, երբ դրանք այլևս անհրաժեշտ չեն վթարից հետո վերականգնման կամ ռեպլիկացիայի համար:

WAL արխիվացումը ընդհատում է այս վերամշակման գործընթացը: Երբ archive_mode-ը միացված է, PostgreSQL-ը կատարում է օգտագործողի կողմից սահմանված archive_command-ը (կամ օգտագործում է archive_library-ն PostgreSQL 15 և ավելի բարձր տարբերակներում)՝ ավարտված WAL սեգմենտը անվտանգ, երկրորդական վայր պատճենելու համար, նախքան այն ջնջվելը կամ վերագրվելը:

Ժամանակի որոշակի կետից վերականգնում (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           # Ստիպողաբար WAL անջատում յուրաքանչյուր 10 րոպեն մեկ

archive_command-ում՝
* %p-ն ներկայացնում է արխիվացվող WAL ֆայլի ամբողջական ուղին:
* %f-ը ներկայացնում է WAL ֆայլի անունը:

Թեև վերոնշյալ կազմաձևումը պարզ է թվում, ձեռնարկատիրական միջավայրերում պարզ shell հրամանների վրա հույս դնելը զգալի ռիսկեր է պարունակում:

WAL արխիվացման ընդհանուր թակարդները

Թակարդ 1. archive_command-ի «Լուռ հաջողությունը»

PostgreSQL-ը լիովին հիմնվում է archive_command-ի ելքային կոդի վրա: Եթե հրամանը վերադարձնում է 0, PostgreSQL-ը ենթադրում է, որ WAL ֆայլը անվտանգ արխիվացված է և անցնում է սկզբնական ֆայլի վերամշակմանը:

Տարածված սխալ է այնպիսի հրամանի օգտագործումը, որը վերադարձնում է 0, նույնիսկ եթե տվյալները անվտանգ չեն գրվել մշտական պահեստում: Օրինակ՝ պարզ cp հրամանը կարող է հաջողություն վերադարձնել հենց որ տվյալները հասնում են նպատակային սերվերի OS էջի քեշին: Եթե նպատակային սերվերը կորցնի հոսանքը նախքան քեշը սկավառակի վրա գրվելը, WAL ֆայլը կկորչի, բայց PostgreSQL-ն արդեն ջնջել է իր տեղական պատճենը:

Ռիսկը. Ընդհատված WAL շղթա և PITR կատարելու անկարողություն, որը հայտնաբերվում է միայն աղետից հետո վերականգնման սցենարի ժամանակ:

Մեղմացումը. Համոզվեք, որ ձեր արխիվացման սկրիպտը պարտադրում է սինխրոն գրառումներ: Եթե օգտագործում եք ստանդարտ shell հրամաններ, օգտագործեք գործիքներ, որոնք երաշխավորում են տվյալների գրառումը, կամ գրեք wrapper սկրիպտ, որը ստուգում է ֆայլի չափը և ստուգաթիվը (checksum) փոխանցումից հետո:

Թակարդ 2. pg_wal բաժանմունքի սպառում (WAL Bloat)

Եթե archive_command-ը ձախողվում է (վերադարձնում է ոչ զրոյական ելքային կոդ)՝ ցանցային խափանումների, սխալ թույլտվությունների կամ նպատակային սկավառակի լցվածության պատճառով, PostgreSQL-ը կպահի WAL ֆայլը pg_wal գրացուցակում և անվերջ կփորձի կրկնել հրամանը:

Թեև սա կանխում է տվյալների կորուստը՝ չջնջելով չարխիվացված WAL-ները, այն ներկայացնում է հասանելիության լուրջ ռիսկ: Եթե pg_wal գրացուցակը գտնվում է մի բաժանմունքում, որը լցվում է 100%-ով, PostgreSQL-ը կթողարկի PANIC և կխափանվի: Տվյալների բազան չի վերագործարկվի, քանի դեռ տարածքը չի ազատվել:

Ռիսկը. Տվյալների բազայի ամբողջական խափանում՝ pg_wal բաժանմունքի լցվածության պատճառով:

Մեղմացումը.
1. Միշտ տեղադրեք pg_wal-ը հատուկ սկավառակի բաժանմունքում:
2. Իրականացրեք pg_wal գրացուցակի չափի ակտիվ մոնիտորինգ:
3. Մոնիտորինգի ենթարկեք pg_stat_archiver տեսքը՝ ձախողված արխիվացման հրամանները անմիջապես հայտնաբերելու համար:

Թակարդ 3. Թերի բազային պահուստային պատճեններ

Բազային պահուստային պատճենը անօգուտ է առանց պահուստավորման գործընթացի ընթացքում ստեղծված WAL ֆայլերի: Եթե դուք կատարում եք ֆայլային համակարգի մակարդակի սնեփշոթ կամ օգտագործում եք pg_basebackup՝ առանց WAL-ների հոսքի (-X stream), դուք պետք է համոզվեք, որ պահուստավորման սկզբի և ավարտի միջև ստեղծված WAL ֆայլերը հաջողությամբ արխիվացվել են:

Եթե ձեր արխիվատորը հետ է մնում կամ ձախողվում է, և այդ հատուկ WAL ֆայլերը կորչում են, բազային պահուստային պատճենը չի կարող բերվել հետևողական վիճակի:

Ռիսկը. Վնասված կամ անվերականգնելի բազային պահուստային պատճեններ:

Մեղմացումը. Օգտագործեք pg_basebackup -X stream՝ անհրաժեշտ WAL ֆայլերը հենց պահուստային պատճենի մեջ ներառելու համար, կամ օգտագործեք ձեռնարկատիրական պահուստավորման լուծումներ, որոնք ավտոմատ կերպով կառավարում են բազային պահուստային պատճենների և WAL սեգմենտների միջև կախվածությունը:

Թակարդ 4. Ժամանակացույցի շփոթություն և «Split-Brain» սցենարներ

Երբ սպասող (standby) սերվերը առաջխաղացվում է որպես հիմնական (primary), PostgreSQL-ը մեծացնում է «Ժամանակացույցի ID»-ն (WAL ֆայլի անվան առաջին մասը, օրինակ՝ 0000000200000001000000A4): Սա կանխում է նոր հիմնական սերվերին հին հիմնական սերվերի WAL պատմությունը վերագրելուց:

Այնուամենայնիվ, եթե հին հիմնական սերվերը պատահաբար գործարկվում է առանց պատշաճ պաշտպանության (split-brain սցենար), այն կարող է փորձել WAL ֆայլեր ուղարկել նույն արխիվային վայր՝ օգտագործելով հին ժամանակացույցը: Եթե ձեր archive_command-ը կույր կերպով վերագրում է ֆայլերը, դուք կարող եք վնասել ձեր արխիվային պահոցը:

Ռիսկը. Վերագրված WAL ֆայլեր, վնասված արխիվներ և անվերականգնելի տվյալների բազաներ:

Մեղմացումը. Ձեր archive_command-ը երբեք չպետք է վերագրի գոյություն ունեցող ֆայլը: Նկատեք, որ նախորդ պարզ կազմաձևման մեջ մենք օգտագործեցինք test ! -f /mnt/nfs/archive/%f՝ հստակ ձախողելու համար, եթե ֆայլն արդեն գոյություն ունի:

Տվյալների կորստի ռիսկերի մեղմացում. Արտադրական լավագույն փորձ

Ձեր PostgreSQL արխիվացման ռազմավարությունը ամրապնդելու համար իրականացրեք հետևյալ լավագույն փորձը.

1. Մոնիտորինգի ենթարկեք արխիվացման գործընթացը բնիկ եղանակով

PostgreSQL-ը տրամադրում է ներկառուցված pg_stat_archiver տեսքը, որը հետևում է ձեր արխիվացման գործընթացի հաջողությանը և ձախողմանը: Դուք պետք է ինտեգրեք այս տեսքը ձեր դիտարկման համակարգի (observability stack) մեջ (օրինակ՝ 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 ֆայլի և արխիվացնել ընթացիկը, նույնիսկ եթե այն լրիվ չէ: Սա երաշխավորում է, որ ձեր RPO-ն չի գերազանցում 10 րոպեն՝ մասամբ լցված WAL ֆայլերի պատճառով պահեստային տարածքի մի փոքր ավելի մեծ օգտագործման գնով:

3. Անցում archive_library-ին (PostgreSQL 15+)

Պատմականորեն archive_command-ը յուրաքանչյուր WAL ֆայլի համար ստեղծում էր նոր shell գործընթաց: Բարձր թողունակությամբ միջավայրերում, որոնք րոպեում հարյուրավոր WAL ֆայլեր են ստեղծում, shell գործընթացների ստեղծման ծախսերը դառնում են կատարողականի խոչընդոտ:

PostgreSQL 15-ը ներկայացրեց archive_library պարամետրը, որը թույլ է տալիս WAL արխիվացումը կառավարել դինամիկ բեռնվող C մոդուլների միջոցով: Սա վերացնում է shell-ի ստեղծման ծախսերը և ապահովում է շատ ավելի ամուր, բարձր կատարողականությամբ արխիվացման մեխանիզմ: Եթե դուք օգտագործում եք PostgreSQL 15 կամ ավելի բարձր տարբերակ, փնտրեք պահուստավորման գործիքներ, որոնք աջակցում են հատուկ արխիվային մոդուլներ:

4. Կանոնավոր կերպով փորձարկեք ժամանակի որոշակի կետից վերականգնումը (PITR)

Չփորձարկված պահուստային պատճենը պահուստային պատճեն չէ, այն ցանկություն է: Ձեր WAL արխիվացման ճիշտ աշխատանքը, WAL շղթայի անխափանությունը և բազային պահուստային պատճենների հետևողականությունը ստուգելու միակ միջոցը կանոնավոր, ավտոմատացված PITR թեստեր կատարելն է:

Գործարկեք ժամանակավոր օրինակ, վերականգնեք բազային պահուստային պատճենը, կազմաձևեք restore_command-ը՝ ձեր արխիվից քաշելու համար, և վերականգնեք մինչև որոշակի ժամանակային կետ: Ստուգեք, որ տվյալների բազան հասնում է հետևողական վիճակի և բացվում է կապերի համար:

Ձեռնարկատիրական պահուստավորում և վերականգնում CloudSave-ի հետ

archive_command-ի համար հատուկ shell սկրիպտների կառավարումը, WAL դեդուպլիկացիայի իրականացումը և գործարքների գրանցամատյանների համար անվտանգ, արտաքին պահեստավորման ապահովումը կարող են արագորեն դառնալ ՏՏ թիմերի համար գործառնական բեռ:

Այստեղ է, որ CloudSave-ը զգալի արժեք է տալիս ձեռնարկատիրական PostgreSQL միջավայրերի համար: CloudSave-ը անմիջականորեն ինտեգրվում է PostgreSQL-ի բնիկ պահուստավորման և WAL արխիվացման API-ների հետ՝ վերացնելու վերը նշված ձեռնարկային թակարդները:

Փխրուն bash սկրիպտներ գրելու փոխարեն, CloudSave-ը տրամադրում է ամուր, գործակալի վրա հիմնված կամ առանց գործակալի ինտեգրում, որը՝
* Երաշխավորում է առաքումը. Ստանդարտ shell հրամանները փոխարինում է ստուգված, ստուգաթիվով հաստատված փոխանցումներով դեպի անվտանգ արտաքին կամ ամպային պահեստ:
* Կանխում է WAL Bloat-ը. Ակտիվորեն մոնիտորինգի է ենթարկում 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) ձեռնարկատիրական տվյալների բազաների համար: