PostgreSQL-ஐ தயாரிப்புச் சூழலில் (production) நிர்வகிக்கும் தரவுத்தள நிர்வாகிகள் (DBAs) மற்றும் DevOps பொறியாளர்களுக்கு, பூஜ்ஜியத்திற்கு நெருக்கமான மீட்புப் புள்ளி இலக்கை (Recovery Point Objective – RPO) அடைவது ஒரு முதன்மையான கட்டாயமாகும். PostgreSQL-இன் பேரிடர் மீட்பு மற்றும் குறிப்பிட்ட நேரத்திற்கு மீட்பு (Point-in-Time Recovery – PITR) திறன்களின் மையமாக Write-Ahead Logging (WAL) உள்ளது. WAL ஆனது தரவு கோப்புகளில் எழுதப்படுவதற்கு முன்பே பரிவர்த்தனைகளை பதிவு செய்வதன் மூலம் ACID இணக்கத்தை உறுதி செய்கிறது, அதே நேரத்தில் WAL ஆர்க்கைவிங் (archiving) என்பது நீண்ட கால காப்புப்பிரதி மற்றும் பிரதிபலிப்புக்காக (replication) இந்த பதிவுகளைப் பாதுகாக்கும் ஒரு பொறிமுறையாகும்.
இருப்பினும், WAL ஆர்க்கைவிங்கை உள்ளமைப்பது என்பது “அமைத்துவிட்டு மறந்துவிடும்” ஒரு செயல் அல்ல. தவறான உள்ளமைவுகள், அமைதியான தோல்விகள் மற்றும் கட்டடக்கலை தவறான புரிதல்கள் பேரழிவுகரமான தரவு இழப்பு, ஸ்பிளிட்-பிரைன் (split-brain) காட்சிகள் அல்லது முழுமையான தரவுத்தள முடக்கத்திற்கு வழிவகுக்கும்.
இந்த விரிவான வழிகாட்டியில், PostgreSQL WAL ஆர்க்கைவிங்கின் கட்டமைப்பை ஆராய்வோம், தரவு இழப்புக்கு வழிவகுக்கும் பொதுவான குறைபாடுகளைக் கண்டறிவோம், மேலும் உங்கள் தரவுத்தளம் மீள்தன்மையுடன் இருப்பதை உறுதிசெய்ய தயாரிப்பு-தரத்திலான சிறந்த நடைமுறைகளை கோடிட்டுக் காட்டுவோம்.
PostgreSQL WAL கட்டமைப்பைப் புரிந்துகொள்வது
குறைபாடுகளைப் பற்றி ஆராய்வதற்கு முன், PostgreSQL பரிவர்த்தனை பதிவுகளை எவ்வாறு கையாளுகிறது என்பதைப் புரிந்துகொள்வது மிக முக்கியம்.
PostgreSQL அனைத்து மாற்றங்களையும் pg_wal கோப்பகத்தில் (பதிப்பு 10-க்கு முந்தைய பதிப்புகளில் pg_xlog) அமைந்துள்ள WAL பிரிவுகளில் (இயல்பாக 16MB கோப்புகள்) எழுதுகிறது. ஒவ்வொரு பரிவர்த்தனையும் வரிசையாகப் பதிவு செய்யப்பட்டு, லாக் சீக்வென்ஸ் நம்பர் (LSN) மூலம் குறிக்கப்படுகிறது.
ஒரு WAL பிரிவு நிரம்பும்போது, PostgreSQL புதிய ஒன்றிற்கு மாறுகிறது. pg_wal கோப்பகம் முடிவில்லாமல் வளர்வதைத் தடுக்க, விபத்து மீட்பு அல்லது பிரதிபலிப்புக்குத் தேவையில்லாத பழைய WAL பிரிவுகளை PostgreSQL மறுசுழற்சி செய்கிறது அல்லது நீக்குகிறது.
WAL ஆர்க்கைவிங் இந்த மறுசுழற்சி செயல்முறையை இடைமறிக்கிறது. archive_mode இயக்கப்பட்டிருக்கும் போது, PostgreSQL ஒரு பயனர் வரையறுக்கப்பட்ட archive_command-ஐ இயக்குகிறது (அல்லது PostgreSQL 15+-இல் archive_library-ஐப் பயன்படுத்துகிறது), இது முழுமையான 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 # ஒவ்வொரு 10 நிமிடங்களுக்கும் ஒருமுறை WAL மாற்றத்தை கட்டாயப்படுத்துகிறது
archive_command-இல்:
* %p என்பது ஆர்க்கைவ் செய்யப்பட வேண்டிய WAL கோப்பின் முழு பாதையைக் குறிக்கிறது.
* %f என்பது WAL கோப்பின் கோப்புப் பெயரைக் குறிக்கிறது.
மேலே உள்ள உள்ளமைவு எளிமையானதாகத் தோன்றினாலும், நிறுவனச் சூழல்களில் எளிய ஷெல் கட்டளைகளை நம்பியிருப்பது குறிப்பிடத்தக்க அபாயங்களை உருவாக்குகிறது.
WAL ஆர்க்கைவிங்கில் பொதுவான குறைபாடுகள்
குறைபாடு 1: archive_command-இன் “அமைதியான வெற்றி” (Silent Success)
PostgreSQL முற்றிலும் archive_command-இன் வெளியேறும் குறியீட்டை (exit code) நம்பியுள்ளது. கட்டளை 0-ஐத் திருப்பியளித்தால், WAL கோப்பு பாதுகாப்பாக ஆர்க்கைவ் செய்யப்பட்டதாக PostgreSQL கருதி, அசல் கோப்பை மறுசுழற்சி செய்யத் தொடங்கும்.
தரவு பாதுகாப்பாக நிரந்தர சேமிப்பகத்திற்கு அனுப்பப்படாவிட்டாலும் 0-ஐத் திருப்பியளிக்கும் கட்டளையைப் பயன்படுத்துவது ஒரு பொதுவான தவறு. உதாரணமாக, ஒரு எளிய cp கட்டளை, தரவு இலக்கு சேவையகத்தில் உள்ள OS பக்க தற்காலிக சேமிப்பை (page cache) அடைந்தவுடன் வெற்றியைத் திருப்பியளிக்கலாம். வட்டுக்கு தரவு எழுதப்படுவதற்கு முன்பே இலக்கு சேவையகத்தில் மின்சாரம் துண்டிக்கப்பட்டால், WAL கோப்பு இழக்கப்படும், ஆனால் PostgreSQL ஏற்கனவே அதன் உள்ளூர் நகலை நீக்கியிருக்கும்.
அபாயம்: உடைந்த WAL சங்கிலி மற்றும் PITR செய்ய இயலாமை, இது பேரிடர் மீட்பு சூழலின் போது மட்டுமே கண்டறியப்படும்.
தணிப்பு: உங்கள் ஆர்க்கைவிங் ஸ்கிரிப்ட் ஒத்திசைவான எழுத்துக்களை (synchronous writes) அமல்படுத்துவதை உறுதி செய்யவும். நிலையான ஷெல் கட்டளைகளைப் பயன்படுத்தினால், தரவு வட்டில் எழுதப்படுவதை உறுதி செய்யும் கருவிகளைப் பயன்படுத்தவும் அல்லது பரிமாற்றத்திற்குப் பிறகு கோப்பு அளவு மற்றும் செக்சம் (checksum) ஆகியவற்றைச் சரிபார்க்கும் ரேப்பர் ஸ்கிரிப்டை எழுதவும்.
குறைபாடு 2: pg_wal பகிர்வு தீர்ந்துபோதல் (WAL Bloat)
archive_command தோல்வியுற்றால் (பூஜ்ஜியமற்ற வெளியேறும் குறியீட்டைத் திருப்பியளித்தால்)—பிணையத் தடங்கல்கள், தவறான அனுமதிகள் அல்லது நிரம்பிய இலக்கு வட்டு காரணமாக—PostgreSQL அந்த WAL கோப்பை pg_wal கோப்பகத்தில் வைத்திருக்கும் மற்றும் கட்டளையை காலவரையின்றி மீண்டும் முயற்சிக்கும்.
இது ஆர்க்கைவ் செய்யப்படாத WAL-களை நீக்காமல் இருப்பதன் மூலம் தரவு இழப்பைத் தடுத்தாலும், இது கடுமையான கிடைக்கும் தன்மை அபாயத்தை (availability risk) அறிமுகப்படுத்துகிறது. pg_wal கோப்பகம் 100% நிரம்பிய பகிர்வில் இருந்தால், PostgreSQL ஒரு PANIC பிழையை வெளியிட்டு செயலிழக்கும். இடம் சுத்தம் செய்யப்படும் வரை தரவுத்தளம் மீண்டும் தொடங்காது.
அபாயம்: முழு pg_wal பகிர்வு காரணமாக தரவுத்தளம் முழுமையாக முடங்குதல்.
தணிப்பு:
1. pg_wal-ஐ எப்போதும் ஒரு பிரத்யேக வட்டு பகிர்வில் வைக்கவும்.
2. pg_wal கோப்பகத்தின் அளவில் தீவிர கண்காணிப்பைச் செயல்படுத்தவும்.
3. தோல்வியுறும் ஆர்க்கைவ் கட்டளைகளை உடனடியாகக் கண்டறிய pg_stat_archiver பார்வையை கண்காணிக்கவும்.
குறைபாடு 3: முழுமையற்ற அடிப்படை காப்புப்பிரதிகள்
காப்புப்பிரதி செயல்முறையின் போது உருவாக்கப்பட்ட WAL கோப்புகள் இல்லாமல் அடிப்படை காப்புப்பிரதி பயனற்றது. நீங்கள் கோப்பு முறைமை அளவிலான ஸ்னாப்ஷாட்டை எடுத்தால் அல்லது WAL-களை ஸ்ட்ரீமிங் செய்யாமல் (-X stream) pg_basebackup-ஐப் பயன்படுத்தினால், காப்புப்பிரதியின் தொடக்கத்திற்கும் முடிவிற்கும் இடையில் உருவாக்கப்பட்ட WAL கோப்புகள் வெற்றிகரமாக ஆர்க்கைவ் செய்யப்படுவதை நீங்கள் உறுதி செய்ய வேண்டும்.
உங்கள் ஆர்க்கைவர் பின்தங்கியிருந்தால் அல்லது தோல்வியுற்றால், அந்த குறிப்பிட்ட WAL கோப்புகள் இழக்கப்பட்டால், அடிப்படை காப்புப்பிரதியை நிலையான நிலைக்குக் கொண்டு வர முடியாது.
அபாயம்: சிதைந்த அல்லது மீட்க முடியாத அடிப்படை காப்புப்பிரதிகள்.
தணிப்பு: தேவையான WAL கோப்புகளை காப்புப்பிரதி பேலோடிலேயே சேர்க்க pg_basebackup -X stream-ஐப் பயன்படுத்தவும், அல்லது அடிப்படை காப்புப்பிரதிகள் மற்றும் WAL பிரிவுகளுக்கு இடையிலான சார்புநிலையை தானாகவே நிர்வகிக்கும் நிறுவன காப்புப்பிரதி தீர்வுகளைப் பயன்படுத்தவும்.
குறைபாடு 4: காலவரிசை குழப்பம் மற்றும் ஸ்பிளிட்-பிரைன் காட்சிகள்
ஒரு ஸ்டாண்ட்பை சேவையகம் முதன்மை சேவையகமாக உயர்த்தப்படும்போது, PostgreSQL “காலவரிசை ஐடி” (Timeline ID)-ஐ (WAL கோப்புப் பெயரின் முதல் பகுதி, எ.கா., 0000000200000001000000A4) அதிகரிக்கிறது. இது புதிய முதன்மை சேவையகம் பழைய முதன்மை சேவையகத்தின் WAL வரலாற்றை மேலெழுதாமல் தடுக்கிறது.
இருப்பினும், பழைய முதன்மை சேவையகம் முறையாக வேலி அமைக்கப்படாமல் (fenced) தற்செயலாகத் தொடங்கப்பட்டால் (ஸ்பிளிட்-பிரைன் காட்சி), அது பழைய காலவரிசையைப் பயன்படுத்தி அதே ஆர்க்கைவ் இருப்பிடத்திற்கு 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-ஐப் பயன்படுத்தவும்
குறைந்த எழுதும் அளவு கொண்ட தரவுத்தளங்களில், 16MB WAL கோப்பு நிரம்ப பல மணிநேரம் ஆகலாம். அது நிரம்பும் வரை, அது ஆர்க்கைவ் செய்யப்படாது. சேவையகம் செயலிழந்து உள்ளூர் வட்டு இழக்கப்பட்டால், நீங்கள் பல மணிநேர பரிவர்த்தனைகளை இழக்க நேரிடும்.
archive_timeout = 600 (10 நிமிடங்கள்) என்று அமைப்பது, PostgreSQL-ஐ புதிய WAL கோப்பிற்கு மாறவும், தற்போதைய கோப்பு நிரம்பவில்லை என்றாலும் அதை ஆர்க்கைவ் செய்யவும் கட்டாயப்படுத்துகிறது. இது உங்கள் RPO 10 நிமிடங்களுக்கு மேல் போகாது என்பதை உறுதி செய்கிறது, பகுதி நிரப்பப்பட்ட WAL கோப்புகளால் சற்று அதிக சேமிப்பக பயன்பாடு ஏற்படும்.
3. archive_library-க்கு மாறுதல் (PostgreSQL 15+)
வரலாற்று ரீதியாக, archive_command ஒவ்வொரு WAL கோப்பிற்கும் ஒரு புதிய ஷெல் செயல்முறையை உருவாக்கியது. நிமிடத்திற்கு நூற்றுக்கணக்கான WAL கோப்புகளை உருவாக்கும் அதிக செயல்திறன் கொண்ட சூழல்களில், ஷெல் செயல்முறைகளை உருவாக்குவதற்கான மேல்நிலை (overhead) ஒரு செயல்திறன் தடையாக மாறுகிறது.
PostgreSQL 15 ஆனது archive_library அளவுருவை அறிமுகப்படுத்தியது, இது WAL ஆர்க்கைவிங்கை மாறும் வகையில் ஏற்றப்பட்ட C தொகுதிகள் மூலம் கையாள அனுமதிக்கிறது. இது ஷெல்-ஃபோர்க்கிங் மேல்நிலையை நீக்குகிறது மற்றும் மிகவும் வலுவான, உயர் செயல்திறன் கொண்ட ஆர்க்கைவிங் பொறிமுறையை வழங்குகிறது. நீங்கள் PostgreSQL 15 அல்லது அதற்கு மேற்பட்ட பதிப்பில் இருந்தால், தனிப்பயன் ஆர்க்கைவ் தொகுதிகளை ஆதரிக்கும் காப்புப்பிரதி கருவிகளைத் தேடுங்கள்.
4. குறிப்பிட்ட நேரத்திற்கு மீட்பு (PITR) சோதனையைத் தொடர்ந்து செய்யவும்
சோதிக்கப்படாத காப்புப்பிரதி என்பது காப்புப்பிரதி அல்ல; அது ஒரு விருப்பம் மட்டுமே. உங்கள் WAL ஆர்க்கைவிங் சரியாகச் செயல்படுகிறதா, உங்கள் WAL சங்கிலி உடையாமல் இருக்கிறதா, மற்றும் உங்கள் அடிப்படை காப்புப்பிரதிகள் சீராக இருக்கிறதா என்பதைச் சரிபார்க்க ஒரே வழி, வழக்கமான, தானியங்கி PITR சோதனைகளைச் செய்வதுதான்.
ஒரு தற்காலிக நிகழ்வை (instance) உருவாக்கி, அடிப்படை காப்புப்பிரதியை மீட்டெடுத்து, உங்கள் ஆர்க்கைவிலிருந்து இழுக்க restore_command-ஐ உள்ளமைத்து, ஒரு குறிப்பிட்ட நேரத்திற்கு மீட்டெடுக்கவும். தரவுத்தளம் சீரான நிலையை அடைந்து இணைப்புகளுக்குத் திறக்கப்படுவதைச் சரிபார்க்கவும்.
CloudSave உடன் நிறுவன காப்புப்பிரதி மற்றும் மீட்பு
archive_command-க்கான தனிப்பயன் ஷெல் ஸ்கிரிப்ட்களை நிர்வகித்தல், WAL டிடூப்ளிகேஷன் (deduplication) கையாளுதல் மற்றும் பரிவர்த்தனை பதிவுகளுக்கு பாதுகாப்பான, ஆஃப்சைட் சேமிப்பகத்தை உறுதி செய்தல் ஆகியவை IT குழுக்களுக்கு விரைவாக ஒரு செயல்பாட்டுச் சுமையாக மாறும்.
இங்குதான் CloudSave நிறுவன PostgreSQL சூழல்களுக்கு குறிப்பிடத்தக்க மதிப்பை வழங்குகிறது. CloudSave நேரடியாக PostgreSQL-இன் சொந்த காப்புப்பிரதி மற்றும் WAL ஆர்க்கைவிங் API-களுடன் ஒருங்கிணைந்து மேலே விவாதிக்கப்பட்ட கைமுறை குறைபாடுகளை நீக்குகிறது.
பலவீனமான பாஷ் ஸ்கிரிப்ட்களை எழுதுவதற்குப் பதிலாக, CloudSave ஒரு வலுவான, ஏஜென்ட்-அடிப்படையிலான அல்லது ஏஜென்ட் இல்லாத ஒருங்கிணைப்பை வழங்குகிறது:
* டெலிவரியை உறுதி செய்கிறது: நிலையான ஷெல் கட்டளைகளை பாதுகாப்பான ஆஃப்சைட் அல்லது கிளவுட் சேமிப்பகத்திற்கு சரிபார்க்கப்பட்ட, செக்சம்-சரிபார்க்கப்பட்ட பரிமாற்றங்களுடன் மாற்றுகிறது.
* WAL Bloat-ஐத் தடுக்கிறது: pg_wal கோப்பகத்தை தீவிரமாக கண்காணித்து, பகிர்வு தீர்ந்துபோவதற்கு நீண்ட காலத்திற்கு முன்பே நிர்வாகிகளுக்கு எச்சரிக்கை செய்கிறது.
* PITR-ஐ தானியங்குபடுத்துகிறது: உள்ளுணர்வு இடைமுகம் மூலம் குறிப்பிட்ட நேரத்திற்கு மீட்பு (PITR) செய்வதை எளிதாக்குகிறது. நீங்கள் மீட்க விரும்பும் சரியான நிமிடத்தைத் தேர்ந்தெடுத்தால், CloudSave தானாகவே சரியான அடிப்படை காப்புப்பிரதியை மீட்டெடுத்து, அந்த நிலையை அடையத் தேவையான WAL கோப்புகளின் சரியான வரிசையை ஸ்ட்ரீம் செய்கிறது.
* காலவரிசைகளைக் கையாளுகிறது: PostgreSQL காலவரிசை வரலாறுகளை புத்திசாலித்தனமாக நிர்வகிக்கிறது, ஃபெயில்ஓவர்கள் (failovers) மற்றும் ஸ்பிளிட்-பிரைன் காட்சிகள் உங்கள் காப்புப்பிரதி களஞ்சியத்தை சிதைக்காது என்பதை உறுதி செய்கிறது.
WAL நிர்வாகத்தின் கடினமான பணிகளை CloudSave-க்கு மாற்றுவதன் மூலம், DBAs வினவல் மேம்படுத்தல் மற்றும் தரவுத்தள செயல்திறனில் கவனம் செலுத்த முடியும், அவர்களின் RPO மற்றும் RTO SLA-க்கள் நிறுவன-தரத்திலான தளத்தால் பாதுகாக்கப்படுகின்றன என்பதை அறிந்து கொள்ளலாம்.
முடிவு
PostgreSQL WAL ஆர்க்கைவிங் என்பது தரவுத்தள பேரிடர் மீட்பின் முதுகெலும்பாகும். ஒரு கோப்பை ஒரு கோப்பகத்திலிருந்து மற்றொன்றுக்கு நகலெடுக்கும் கருத்து எளிமையானதாகத் தோன்றினாலும், விளிம்பு நிலை சிக்கல்கள்—அமைதியான தோல்விகள், வட்டு தீர்ந்துபோதல் மற்றும் காலவரிசை விலகல்—தரவு ஒருமைப்பாட்டிற்கு கடுமையான அபாயங்களை ஏற்படுத்துகின்றன.
pg_wal-இன் கட்டமைப்பைப் புரிந்துகொள்வதன் மூலமும், அழிவுகரமான archive_command உள்ளமைவுகளைத் தவிர்ப்பதன் மூலமும், pg_stat_archiver-ஐக் கண்காணிப்பதன் மூலமும், CloudSave போன்ற நிறுவன காப்புப்பிரதி தளங்களைப் பயன்படுத்துவதன் மூலமும், வன்பொருள் தோல்விகள், மனித பிழைகள் மற்றும் பேரழிவுகரமான முடக்கங்களைத் தாங்கி, ஒரு கமிட் செய்யப்பட்ட பரிவர்த்தனையைக் கூட இழக்காமல் இருக்கக்கூடிய மீள்தன்மையுள்ள PostgreSQL உள்கட்டமைப்பை நீங்கள் உருவாக்க முடியும்.
தரவு இழப்புக்கு வழிவகுக்கும் PostgreSQL WAL ஆர்க்கைவிங்கின் பொதுவான குறைபாடுகளைக் கண்டறியவும். நிபுணர் DBA சிறந்த நடைமுறைகள், உள்ளமைவு குறிப்புகள் மற்றும் நிறுவன தரவுத்தளங்களுக்கு நம்பகமான குறிப்பிட்ட நேரத்திற்கு மீட்பு (PITR) செய்வதை எவ்வாறு உறுதி செய்வது என்பதை அறிக.
