Məhsuldar mühitdə PostgreSQL-i idarə edən verilənlər bazası administratorları (DBA-lar) və DevOps mühəndisləri üçün sıfıra yaxın Bərpa Nöqtəsi Məqsədinə (RPO) nail olmaq əsas vəzifədir. PostgreSQL-in fəlakətdən bərpa və Müəyyən Vaxta Bərpa (PITR) imkanlarının mərkəzində Yazıdan Əvvəl Jurnallama (WAL) dayanır. WAL, tranzaksiyaları məlumat fayllarına yazılmazdan əvvəl qeyd edərək ACID uyğunluğunu təmin etsə də, WAL arxivləşdirmə bu jurnalları uzunmüddətli ehtiyat nüsxə və replikasiya üçün qoruyan mexanizmdir.
Bununla belə, WAL arxivləşdirməni konfiqurasiya etmək “quraşdır və unut” tipli bir əməliyyat deyil. Yanlış konfiqurasiyalar, gizli nasazlıqlar və arxitektura ilə bağlı anlaşılmazlıqlar fəlakətli məlumat itkisinə, “split-brain” ssenarilərinə və ya tam verilənlər bazası kəsilmələrinə səbəb ola bilər.
Bu əhatəli bələdçidə biz PostgreSQL WAL arxivləşdirmə arxitekturasını araşdıracaq, məlumat itkisinə səbəb olan ən çox yayılmış çatışmazlıqları müəyyən edəcək və verilənlər bazanızın dayanıqlı qalmasını təmin etmək üçün istehsal səviyyəsində ən yaxşı təcrübələri nəzərdən keçirəcəyik.
PostgreSQL WAL Arxitekturasını Anlamaq
Çatışmazlıqlara keçməzdən əvvəl, PostgreSQL-in tranzaksiya jurnallarını necə idarə etdiyini başa düşmək çox vacibdir.
PostgreSQL bütün dəyişiklikləri pg_wal qovluğunda (10-dan əvvəlki versiyalarda pg_xlog) yerləşən WAL seqmentlərinə (standart olaraq 16MB fayllar) yazır. Hər bir tranzaksiya ardıcıl olaraq qeyd olunur və Jurnal Ardıcıllıq Nömrəsi (LSN) ilə işarələnir.
WAL seqmenti dolduqda, PostgreSQL yenisinə keçir. pg_wal qovluğunun sonsuz böyüməsinin qarşısını almaq üçün PostgreSQL qəza bərpası və ya replikasiya üçün artıq lazım olmayan köhnə WAL seqmentlərini təkrar emal edir və ya silir.
WAL Arxivləşdirmə bu təkrar emal prosesinə müdaxilə edir. archive_mode aktiv olduqda, PostgreSQL tamamlanmış WAL seqmentini silinməzdən və ya üzərinə yazılmazdan əvvəl təhlükəsiz, ikinci dərəcəli bir yerə köçürmək üçün istifadəçi tərəfindən müəyyən edilmiş archive_command-ı icra edir (və ya PostgreSQL 15+-də archive_library-dən istifadə edir).
Müəyyən Vaxta Bərpa (PITR) həyata keçirmək üçün iki komponentə ehtiyacınız var:
1. Etibarlı baza ehtiyat nüsxəsi.
2. Baza ehtiyat nüsxəsindən hədəf bərpa vaxtına qədər arxivlənmiş WAL fayllarının kəsilməz zənciri.
Əgər həmin WAL zənciri qırılarsa, PITR prosesiniz uğursuz olacaq.
İstehsal üçün WAL Arxivləşdirmənin Konfiqurasiyası
WAL arxivləşdirməni aktivləşdirmək üçün postgresql.conf faylınızı dəyişdirməlisiniz. Əsas konfiqurasiya wal_level-in təyin edilməsini, archive_mode-un aktivləşdirilməsini və archive_command-ın müəyyən edilməsini tələb edir.
# postgresql.conf
wal_level = replica # arxivləşdirmə üçün 'replica' və ya 'logical' tələb olunur
archive_mode = on # arxivləşdirici prosesi aktivləşdirir
archive_command = 'test ! -f /mnt/nfs/archive/%f && cp %p /mnt/nfs/archive/%f'
archive_timeout = 600 # hər 10 dəqiqədən bir WAL keçidini məcbur edin
archive_command-da:
* %p arxivlənəcək WAL faylının tam yolunu təmsil edir.
* %f WAL faylının adını təmsil edir.
Yuxarıdakı konfiqurasiya sadə görünsə də, müəssisə mühitlərində sadə shell əmrlərinə etibar etmək ciddi risklər yaradır.
WAL Arxivləşdirmədə Ümumi Çatışmazlıqlar
Çatışmazlıq 1: archive_command-ın “Səssiz Uğuru”
PostgreSQL tamamilə archive_command-ın çıxış koduna güvənir. Əgər əmr 0 qaytararsa, PostgreSQL WAL faylının təhlükəsiz arxivləndiyini güman edir və orijinal faylı təkrar emal etməyə başlayır.
Ümumi bir səhv, məlumatlar davamlı yaddaşa etibarlı şəkildə yazılmasa belə 0 qaytaran bir əmrdən istifadə etməkdir. Məsələn, sadə cp əmri məlumatlar təyinat serverindəki OS səhifə keşinə düşən kimi uğur qaytara bilər. Əgər təyinat serveri keş diskə yazılmamışdan əvvəl enerjini itirərsə, WAL faylı itirilir, lakin PostgreSQL artıq öz yerli nüsxəsini silmiş olur.
Risk: Qırılmış WAL zənciri və yalnız fəlakətdən bərpa ssenarisi zamanı aşkar edilən PITR-i həyata keçirə bilməmək.
Azaldılma: Arxivləşdirmə skriptinizin sinxron yazıları məcbur etdiyinə əmin olun. Əgər standart shell əmrlərindən istifadə edirsinizsə, məlumatın diskə yazılmasını təmin edən alətlərdən istifadə edin və ya köçürmədən sonra fayl ölçüsünü və checksum-u yoxlayan bir wrapper skripti yazın.
Çatışmazlıq 2: pg_wal Bölməsinin Tükənməsi (WAL Şişməsi)
Əgər archive_command uğursuz olarsa (sıfırdan fərqli çıxış kodu qaytararsa)—şəbəkə kəsilmələri, yanlış icazələr və ya dolu təyinat diski səbəbindən—PostgreSQL WAL faylını pg_wal qovluğunda saxlayacaq və əmri qeyri-müəyyən müddətə yenidən cəhd edəcək.
Bu, arxivlənməmiş WAL-ları silməməklə məlumat itkisinin qarşısını alsa da, ciddi bir əlçatanlıq riski yaradır. Əgər pg_wal qovluğu 100%-ə qədər dolan bir bölmədə yerləşirsə, PostgreSQL PANIC siqnalı verəcək və dayanacaq. Verilənlər bazası yer boşaldılana qədər yenidən başlamayacaq.
Risk: Tam pg_wal bölməsi səbəbindən verilənlər bazasının tamamilə dayanması.
Azaldılma:
1. pg_wal-ı həmişə xüsusi disk bölməsində yerləşdirin.
2. pg_wal qovluğunun ölçüsünə ciddi monitorinq tətbiq edin.
3. Uğursuz arxiv əmrlərini dərhal aşkar etmək üçün pg_stat_archiver görünüşünü izləyin.
Çatışmazlıq 3: Natamam Baza Ehtiyat Nüsxələri
Baza ehtiyat nüsxəsi, ehtiyat nüsxə prosesi zamanı yaradılan WAL faylları olmadan yararsızdır. Əgər fayl sistemi səviyyəsində snapshot götürürsünüzsə və ya WAL-ları yayımlamadan (-X stream) pg_basebackup istifadə edirsinizsə, ehtiyat nüsxənin başlanğıcı və sonu arasında yaradılan WAL fayllarının uğurla arxivləndiyinə əmin olmalısınız.
Əgər arxivləşdiriciniz gecikirsə və ya uğursuz olursa və həmin xüsusi WAL faylları itirilərsə, baza ehtiyat nüsxəsi ardıcıl vəziyyətə gətirilə bilməz.
Risk: Korlanmış və ya bərpa olunmaz baza ehtiyat nüsxələri.
Azaldılma: Lazımi WAL fayllarını ehtiyat nüsxənin özünə daxil etmək üçün pg_basebackup -X stream istifadə edin və ya baza ehtiyat nüsxələri ilə WAL seqmentləri arasındakı asılılığı avtomatik idarə edən müəssisə ehtiyat nüsxə həllərindən istifadə edin.
Çatışmazlıq 4: Zaman Çizelgesi Qarışıqlığı və “Split-Brain” Ssenariləri
Standby serveri əsas (primary) serverə yüksəldildikdə, PostgreSQL “Zaman Çizelgesi ID-sini” (WAL fayl adının ilk hissəsi, məsələn, 0000000200000001000000A4) artırır. Bu, yeni əsas serverin köhnə əsas serverin WAL tarixçəsinin üzərinə yazmasının qarşısını alır.
Bununla belə, əgər köhnə əsas server düzgün şəkildə ayrılmadan (fencing) təsadüfən başladılarsa (“split-brain” ssenarisi), o, köhnə zaman çizelgesindən istifadə edərək eyni arxiv yerinə WAL faylları göndərməyə cəhd edə bilər. Əgər archive_command-ınız kor-koranə faylların üzərinə yazırsa, arxiv anbarınızı korlaya bilərsiniz.
Risk: Üzərinə yazılmış WAL faylları, korlanmış arxivlər və bərpa olunmaz verilənlər bazaları.
Azaldılma: archive_command-ınız mövcud faylın üzərinə heç vaxt yazmamalıdır. Əvvəlki əsas konfiqurasiyada fayl artıq mövcud olduqda açıq şəkildə uğursuz olmaq üçün test ! -f /mnt/nfs/archive/%f istifadə etdiyimizə diqqət yetirin.
Məlumat İtkisi Risklərinin Azaldılması: İstehsal üçün Ən Yaxşı Təcrübələr
PostgreSQL arxivləşdirmə strategiyanızı gücləndirmək üçün aşağıdakı ən yaxşı təcrübələri tətbiq edin.
1. Arxivləşdirici Prosesi Yerli Şəkildə İzləyin
PostgreSQL, arxivləşdirmə prosesinizin uğur və uğursuzluqlarını izləyən daxili pg_stat_archiver görünüşünü təqdim edir. Bu görünüşü müşahidə yığmanıza (məsələn, Prometheus, Datadog və ya Zabbix) inteqrasiya etməlisiniz.
SELECT
archived_count,
last_archived_wal,
last_archived_time,
failed_count,
last_failed_wal,
last_failed_time,
stats_reset
FROM pg_stat_archiver;
Konfiqurasiya ediləcək xəbərdarlıq hədləri:
* failed_count artarsa xəbərdarlıq edin.
* now() və last_archived_time arasındakı vaxt fərqi RPO həddinizi (məsələn, 15 dəqiqə) aşarsa xəbərdarlıq edin, unutmayın ki, archive_timeout təyin olunmadıqda aşağı trafikli verilənlər bazalarında təbii gecikmələr ola bilər.
2. archive_timeout-dan istifadə edin
Aşağı yazma həcmi olan verilənlər bazalarında 16MB-lıq WAL faylının dolması saatlar çəkə bilər. Dolana qədər o, arxivlənmir. Əgər server qəzaya uğrayarsa və yerli disk itərsə, siz saatlarla tranzaksiyanı itirirsiniz.
archive_timeout = 600 (10 dəqiqə) təyin etmək, PostgreSQL-i tam dolmasa belə yeni WAL faylına keçməyə və cari faylı arxivləməyə məcbur edir. Bu, qismən dolmuş WAL faylları səbəbindən bir qədər yüksək yaddaş istifadəsi bahasına, RPO-nuzun 10 dəqiqəni aşmamasını təmin edir.
3. archive_library-yə keçid (PostgreSQL 15+)
Tarixən, archive_command hər bir WAL faylı üçün yeni bir shell prosesi yaradırdı. Dəqiqədə yüzlərlə WAL faylı yaradan yüksək ötürücülü mühitlərdə, shell proseslərinin yaradılması (forking) performansı ləngidən bir amilə çevrilir.
PostgreSQL 15, WAL arxivləşdirmənin dinamik yüklənən C modulları tərəfindən idarə olunmasına imkan verən archive_library parametrini təqdim etdi. Bu, shell-forking yükünü aradan qaldırır və daha möhkəm, yüksək performanslı arxivləşdirmə mexanizmi təmin edir. Əgər PostgreSQL 15 və ya daha yüksək versiyadasınızsa, xüsusi arxiv modullarını dəstəkləyən ehtiyat nüsxə alətlərini axtarın.
4. Müəyyən Vaxta Bərpanı (PITR) Daimi Sınaqdan Keçirin
Sınaqdan keçirilməmiş ehtiyat nüsxə, ehtiyat nüsxə deyil; bu bir arzudur. WAL arxivləşdirmənizin düzgün işlədiyini, WAL zəncirinizin qırılmadığını və baza ehtiyat nüsxələrinizin ardıcıl olduğunu yoxlamağın yeganə yolu müntəzəm, avtomatlaşdırılmış PITR testləri aparmaqdır.
Müvəqqəti bir instansiya yaradın, baza ehtiyat nüsxəsini bərpa edin, arxivdən çəkmək üçün restore_command-ı konfiqurasiya edin və müəyyən bir zaman damğasına qədər bərpa edin. Verilənlər bazasının ardıcıl vəziyyətə çatdığını və bağlantılar üçün açıldığını yoxlayın.
CloudSave ilə Müəssisə Ehtiyat Nüsxəsi və Bərpa
archive_command üçün xüsusi shell skriptlərini idarə etmək, WAL deduplikasiyasını həyata keçirmək və tranzaksiya jurnalları üçün təhlükəsiz, ofisdən kənar yaddaşı təmin etmək İT komandaları üçün tez bir zamanda əməliyyat yükünə çevrilə bilər.
CloudSave-in müəssisə PostgreSQL mühitləri üçün əhəmiyyətli dəyər təmin etdiyi yer budur. CloudSave, yuxarıda müzakirə olunan əl ilə edilən çatışmazlıqları aradan qaldırmaq üçün PostgreSQL-in yerli ehtiyat nüsxə və WAL arxivləşdirmə API-ləri ilə birbaşa inteqrasiya olunur.
Kövrək bash skriptləri yazmaq əvəzinə, CloudSave aşağıdakıları təmin edən möhkəm, agent əsaslı və ya agentsiz inteqrasiya təklif edir:
* Çatdırılma Zəmanəti: Standart shell əmrlərini təhlükəsiz ofisdən kənar və ya bulud yaddaşına yoxlanılmış, checksum ilə təsdiqlənmiş köçürmələrlə əvəz edir.
* WAL Şişməsinin Qarşısını Alır: pg_wal qovluğunu aktiv şəkildə izləyir və bölmə tükənməmişdən çox əvvəl administratorlara xəbərdarlıq edir.
* PITR-i Avtomatlaşdırır: İntuitiv interfeys vasitəsilə Müəyyən Vaxta Bərpanı sadələşdirir. Bərpa etmək istədiyiniz dəqiq vaxtı seçirsiniz və CloudSave avtomatik olaraq düzgün baza ehtiyat nüsxəsini əldə edir və həmin vəziyyətə çatmaq üçün tələb olunan dəqiq WAL faylları ardıcıllığını yayımlayır.
* Zaman Çizelgələrini İdarə Edir: PostgreSQL zaman çizelgesi tarixçələrini ağıllı şəkildə idarə edir, failover və “split-brain” ssenarilərinin ehtiyat nüsxə anbarınızı korlamamasını təmin edir.
WAL idarəetməsinin ağır yükünü CloudSave-ə həvalə etməklə, DBA-lar RPO və RTO SLA-larının müəssisə səviyyəli platforma tərəfindən qorunduğunu bilərək, sorğu optimallaşdırılmasına və verilənlər bazası performansına diqqət yetirə bilərlər.
Nəticə
PostgreSQL WAL arxivləşdirmə, verilənlər bazasının fəlakətdən bərpasının onurğa sütunudur. Bir faylı bir qovluqdan digərinə köçürmək konsepsiyası sadə görünsə də, kənar hallar—gizli nasazlıqlar, disk tükənməsi və zaman çizelgesi ayrılması—məlumat bütövlüyü üçün ciddi risklər yaradır.
pg_wal arxitekturasını başa düşərək, dağıdıcı archive_command konfiqurasiyalarından ciddi şəkildə qaçaraq, pg_stat_archiver-i izləyərək və CloudSave kimi müəssisə ehtiyat nüsxə platformalarından istifadə edərək, aparat nasazlıqlarına, insan səhvlərinə və fəlakətli kəsilmələrə—bir dənə də olsun tranzaksiya itirmədən—dözə bilən dayanıqlı PostgreSQL infrastrukturu qura bilərsiniz.
Məlumat itkisinə səbəb olan PostgreSQL WAL arxivləşdirməsinin ümumi çatışmazlıqlarını kəşf edin. DBA ekspertlərinin ən yaxşı təcrübələrini, konfiqurasiya məsləhətlərini və müəssisə verilənlər bazaları üçün etibarlı Müəyyən Vaxta Bərpanı (PITR) necə təmin edəcəyinizi öyrənin.
