WAL-G: PostgreSQL DBMS-ന്റെ ബാക്കപ്പുകളും വീണ്ടെടുക്കലും

SQL ഡംപുകളിലേക്ക് ബാക്കപ്പുകൾ നിർമ്മിക്കുന്നത് വളരെക്കാലമായി അറിയപ്പെടുന്നു (ഉപയോഗിക്കുന്നത് pg_dump അഥവാ pg_dumpall) നല്ല ആശയമല്ല. PostgreSQL DBMS ബാക്കപ്പ് ചെയ്യുന്നതിന്, കമാൻഡ് ഉപയോഗിക്കുന്നതാണ് നല്ലത് pg_basebackup, ഇത് WAL ലോഗുകളുടെ ബൈനറി പകർപ്പ് ഉണ്ടാക്കുന്നു. എന്നാൽ ഒരു പകർപ്പ് സൃഷ്‌ടിക്കുന്നതിനും പുനഃസ്ഥാപിക്കുന്നതിനുമുള്ള മുഴുവൻ പ്രക്രിയയും നിങ്ങൾ പഠിക്കാൻ തുടങ്ങുമ്പോൾ, ഇത് പ്രവർത്തിക്കുന്നതിന് കുറഞ്ഞത് രണ്ട് ട്രൈസൈക്കിളുകളെങ്കിലും എഴുതേണ്ടതുണ്ടെന്നും മുകളിലും താഴെയും വേദന ഉണ്ടാക്കരുതെന്നും നിങ്ങൾ മനസ്സിലാക്കും. കഷ്ടപ്പാടുകൾ ലഘൂകരിക്കാൻ, WAL-G വികസിപ്പിച്ചെടുത്തു.

WAL-G PostgreSQL ഡാറ്റാബേസുകൾ ബാക്കപ്പ് ചെയ്യുന്നതിനും പുനഃസ്ഥാപിക്കുന്നതിനുമായി Go-യിൽ എഴുതിയിരിക്കുന്ന ഒരു ടൂൾ ആണ് (കൂടാതെ അടുത്തിടെ MySQL/MariaDB, MongoDB, FoundationDB എന്നിവയും). ആമസോൺ എസ് 3 സ്റ്റോറേജ് (ഒപ്പം അനലോഗുകൾ, ഉദാഹരണത്തിന്, യാൻഡെക്സ് ഒബ്‌ജക്റ്റ് സ്റ്റോറേജ്), ഗൂഗിൾ ക്ലൗഡ് സ്റ്റോറേജ്, അസൂർ സ്റ്റോറേജ്, സ്വിഫ്റ്റ് ഒബ്‌ജക്റ്റ് സ്റ്റോറേജ്, കൂടാതെ ഫയൽ സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്നത് ഇത് പിന്തുണയ്ക്കുന്നു. മുഴുവൻ സജ്ജീകരണവും ലളിതമായ ഘട്ടങ്ങളിലേക്കാണ് വരുന്നത്, എന്നാൽ ഇതിനെക്കുറിച്ചുള്ള ലേഖനങ്ങൾ ഇന്റർനെറ്റിലുടനീളം ചിതറിക്കിടക്കുന്നതിനാൽ, തുടക്കം മുതൽ അവസാനം വരെയുള്ള എല്ലാ ഘട്ടങ്ങളും ഉൾക്കൊള്ളുന്ന പൂർണ്ണമായ ഒരു മാനുവൽ ഇല്ല (ഹബ്രെയിൽ നിരവധി പോസ്റ്റുകൾ ഉണ്ട്, എന്നാൽ പല പോയിന്റുകളും അവിടെ നഷ്‌ടമായി).

ഈ ലേഖനം പ്രാഥമികമായി എന്റെ അറിവ് ചിട്ടപ്പെടുത്തുന്നതിനാണ് എഴുതിയത്. ഞാൻ ഒരു DBA അല്ല, എനിക്ക് എവിടെയെങ്കിലും സാധാരണക്കാരുടെ ഭാഷയിൽ സ്വയം പ്രകടിപ്പിക്കാൻ കഴിയും, അതിനാൽ എന്തെങ്കിലും തിരുത്തലുകൾ സ്വാഗതം ചെയ്യുന്നു!

വെവ്വേറെ, ഉബുണ്ടു 12.3-ലെ PostgreSQL 18.04-ന് ചുവടെയുള്ള എല്ലാം പ്രസക്തവും പരീക്ഷിച്ചതും ഞാൻ ശ്രദ്ധിക്കുന്നു, എല്ലാ കമാൻഡുകളും ഒരു പ്രത്യേക ഉപയോക്താവായി എക്സിക്യൂട്ട് ചെയ്യണം.

ഇൻസ്റ്റലേഷൻ

ഈ ലേഖനം എഴുതുന്ന സമയത്ത്, WAL-G യുടെ സ്ഥിരമായ പതിപ്പാണ് v0.2.15 (മാർച്ച് 2020). ഇതാണ് ഞങ്ങൾ ഉപയോഗിക്കുന്നത് (എന്നാൽ നിങ്ങൾ അത് മാസ്റ്റർ ബ്രാഞ്ചിൽ നിന്ന് സ്വയം നിർമ്മിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഗിത്തബ് ശേഖരത്തിൽ ഇതിനുള്ള എല്ലാ നിർദ്ദേശങ്ങളും ഉണ്ട്). ഡൗൺലോഡ് ചെയ്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് നിങ്ങൾ ചെയ്യേണ്ടത്:

#!/bin/bash

curl -L "https://github.com/wal-g/wal-g/releases/download/v0.2.15/wal-g.linux-amd64.tar.gz" -o "wal-g.linux-amd64.tar.gz"
tar -xzf wal-g.linux-amd64.tar.gz
mv wal-g /usr/local/bin/

ഇതിനുശേഷം, നിങ്ങൾ ആദ്യം WAL-G കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്, തുടർന്ന് PostgreSQL തന്നെ.

WAL-G സജ്ജീകരിക്കുന്നു

ബാക്കപ്പുകൾ സംഭരിക്കുന്നതിനുള്ള ഒരു ഉദാഹരണത്തിനായി, Amazon S3 ഉപയോഗിക്കും (കാരണം ഇത് എന്റെ സെർവറുകൾക്ക് അടുത്താണ്, അതിന്റെ ഉപയോഗം വളരെ വിലകുറഞ്ഞതാണ്). ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ, നിങ്ങൾക്ക് ഒരു "s3 ബക്കറ്റും" ആക്സസ് കീകളും ആവശ്യമാണ്.

WAL-G നെക്കുറിച്ചുള്ള എല്ലാ മുൻ ലേഖനങ്ങളും എൻവയോൺമെന്റ് വേരിയബിളുകൾ ഉപയോഗിച്ചാണ് കോൺഫിഗറേഷൻ ഉപയോഗിച്ചത്, എന്നാൽ ഈ റിലീസിനൊപ്പം ക്രമീകരണങ്ങൾ കണ്ടെത്താനാകും .walg.json ഫയൽ പോസ്റ്റ്ഗ്രെസ് ഉപയോക്താവിന്റെ ഹോം ഡയറക്ടറിയിൽ. ഇത് സൃഷ്ടിക്കാൻ, ഇനിപ്പറയുന്ന ബാഷ് സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുക:

#!/bin/bash

cat > /var/lib/postgresql/.walg.json << EOF
{
    "WALG_S3_PREFIX": "s3://your_bucket/path",
    "AWS_ACCESS_KEY_ID": "key_id",
    "AWS_SECRET_ACCESS_KEY": "secret_key",
    "WALG_COMPRESSION_METHOD": "brotli",
    "WALG_DELTA_MAX_STEPS": "5",
    "PGDATA": "/var/lib/postgresql/12/main",
    "PGHOST": "/var/run/postgresql/.s.PGSQL.5432"
}
EOF
# обязательно меняем владельца файла:
chown postgres: /var/lib/postgresql/.walg.json

എല്ലാ പാരാമീറ്ററുകളെക്കുറിച്ചും ഞാൻ കുറച്ച് വിശദീകരിക്കാം:

• WALG_S3_PREFIX - ബാക്കപ്പുകൾ അപ്‌ലോഡ് ചെയ്യുന്ന നിങ്ങളുടെ S3 ബക്കറ്റിലേക്കുള്ള പാത (നിങ്ങൾക്ക് ഒന്നുകിൽ റൂട്ടിലേക്കോ ഫോൾഡറിലേക്കോ ആകാം);
• AWS_ACCESS_KEY_ID - എസ് 3 ലെ ആക്സസ് കീ (ഒരു ടെസ്റ്റ് സെർവറിൽ വീണ്ടെടുക്കുകയാണെങ്കിൽ, ഈ കീകൾക്ക് റീഡ് ഒൺലി പോളിസി ഉണ്ടായിരിക്കണം! വീണ്ടെടുക്കൽ എന്ന വിഭാഗത്തിൽ ഇത് കൂടുതൽ വിശദമായി വിവരിച്ചിരിക്കുന്നു.);
• AWS_SECRET_ACCESS_KEY - S3 സംഭരണത്തിലെ രഹസ്യ കീ;
• WALG_COMPRESSION_METHOD - കംപ്രഷൻ രീതി, ബ്രോട്‌ലി ഉപയോഗിക്കുന്നതാണ് നല്ലത് (ഇത് അവസാന വലുപ്പത്തിനും കംപ്രഷൻ / ഡികംപ്രഷൻ വേഗതയ്ക്കും ഇടയിലുള്ള സുവർണ്ണ ശരാശരിയായതിനാൽ);
• WALG_DELTA_MAX_STEPS - ഒരു പൂർണ്ണ ബാക്കപ്പ് സൃഷ്ടിക്കുന്നതിന് മുമ്പ് "ഡെൽറ്റകളുടെ" എണ്ണം (അവ സമയവും ഡൗൺലോഡ് ചെയ്ത ഡാറ്റയുടെ വലുപ്പവും ലാഭിക്കുന്നു, പക്ഷേ വീണ്ടെടുക്കൽ പ്രക്രിയയെ ചെറുതായി മന്ദഗതിയിലാക്കാം, അതിനാൽ വലിയ മൂല്യങ്ങൾ ഉപയോഗിക്കുന്നത് ഉചിതമല്ല);
• PGDATA - നിങ്ങളുടെ ഡാറ്റാബേസ് ഡാറ്റയുള്ള ഡയറക്ടറിയിലേക്കുള്ള പാത (കമാൻഡ് പ്രവർത്തിപ്പിച്ച് നിങ്ങൾക്ക് കണ്ടെത്താനാകും pg_lsclusters);
• PGHOST - ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്യുന്നു, ഒരു പ്രാദേശിക ബാക്കപ്പ് ഉപയോഗിച്ച് ഈ ഉദാഹരണത്തിലെന്നപോലെ ഒരു യുണിക്സ്-സോക്കറ്റ് വഴി ഇത് ചെയ്യുന്നതാണ് നല്ലത്.

മറ്റ് പാരാമീറ്ററുകൾ ഡോക്യുമെന്റേഷനിൽ കാണാം: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

PostgreSQL സജ്ജീകരിക്കുന്നു

ഡാറ്റാബേസിനുള്ളിലെ ആർക്കൈവറിന് WAL ലോഗുകൾ ക്ലൗഡിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നതിനും അവയിൽ നിന്ന് അവ പുനഃസ്ഥാപിക്കുന്നതിനും (ആവശ്യമെങ്കിൽ), നിങ്ങൾ കോൺഫിഗറേഷൻ ഫയലിൽ നിരവധി പാരാമീറ്ററുകൾ സജ്ജീകരിക്കേണ്ടതുണ്ട്. /etc/postgresql/12/main/postgresql.conf. തുടക്കക്കാർക്ക് വേണ്ടി മാത്രം നിങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട്ചുവടെയുള്ള ക്രമീകരണങ്ങളൊന്നും മറ്റേതെങ്കിലും മൂല്യങ്ങളിലേക്ക് സജ്ജമാക്കിയിട്ടില്ല, അതിനാൽ കോൺഫിഗറേഷൻ വീണ്ടും ലോഡുചെയ്യുമ്പോൾ, DBMS ക്രാഷ് ആകില്ല. ഇനിപ്പറയുന്നവ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ പാരാമീറ്ററുകൾ ചേർക്കാൻ കഴിയും:

#!/bin/bash

echo "wal_level=replica" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_mode=on" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_command='/usr/local/bin/wal-g wal-push "%p" >> /var/log/postgresql/archive_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf
echo “archive_timeout=60” >> /etc/postgresql/12/main/postgresql.conf
echo "restore_command='/usr/local/bin/wal-g wal-fetch "%f" "%p" >> /var/log/postgresql/restore_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf

# перезагружаем конфиг через отправку SIGHUP сигнала всем процессам БД
killall -s HUP postgres

സജ്ജമാക്കേണ്ട പാരാമീറ്ററുകളുടെ വിവരണം:

• വാൽ_ലെവൽ - WAL ലോഗുകളിൽ എത്ര വിവരങ്ങൾ എഴുതണം, "പ്രതിരൂപം" - എല്ലാം എഴുതുക;
• ആർക്കൈവ്_മോഡ് - പാരാമീറ്ററിൽ നിന്നുള്ള കമാൻഡ് ഉപയോഗിച്ച് WAL ലോഗുകൾ ഡൗൺലോഡ് ചെയ്യുന്നത് പ്രവർത്തനക്ഷമമാക്കുക ആർക്കൈവ്_കമാൻഡ്;
• ആർക്കൈവ്_കമാൻഡ് - പൂർത്തിയാക്കിയ WAL ലോഗ് ആർക്കൈവ് ചെയ്യുന്നതിനുള്ള കമാൻഡ്;
• ആർക്കൈവ്_ടൈംഔട്ട് - ലോഗുകളുടെ ആർക്കൈവിംഗ് പൂർത്തിയാകുമ്പോൾ മാത്രമേ നടപ്പിലാക്കുകയുള്ളൂ, എന്നാൽ നിങ്ങളുടെ സെർവർ ഡാറ്റാബേസിലേക്ക് കുറച്ച് ഡാറ്റ മാറ്റുകയോ ചേർക്കുകയോ ചെയ്യുകയാണെങ്കിൽ, നിമിഷങ്ങൾക്കുള്ളിൽ ഇവിടെ ഒരു പരിധി സജ്ജീകരിക്കുന്നത് അർത്ഥമാക്കുന്നു, അതിനുശേഷം ആർക്കൈവിംഗ് കമാൻഡ് നിർബന്ധിതമായി വിളിക്കപ്പെടും (ഓരോ സെക്കൻഡിലും ഞാൻ ഡാറ്റാബേസിലേക്ക് തീവ്രമായി എഴുതുന്നു, അതിനാൽ ഈ പരാമീറ്റർ ഉൽപ്പാദനത്തിൽ സജ്ജീകരിക്കേണ്ടതില്ലെന്ന് ഞാൻ തീരുമാനിച്ചു);
• റിസ്റ്റോർ_കമാൻഡ് - "പൂർണ്ണ ബാക്കപ്പ്" (ബേസ് ബാക്കപ്പ്) ഡാറ്റാബേസിലെ ഏറ്റവും പുതിയ മാറ്റങ്ങൾ ഇല്ലെങ്കിൽ, ഒരു ബാക്കപ്പിൽ നിന്ന് WAL ലോഗ് പുനഃസ്ഥാപിക്കുന്നതിനുള്ള കമാൻഡ് ഉപയോഗിക്കും.

ഔദ്യോഗിക ഡോക്യുമെന്റേഷന്റെ വിവർത്തനത്തിൽ ഈ എല്ലാ പാരാമീറ്ററുകളെയും കുറിച്ച് നിങ്ങൾക്ക് കൂടുതൽ വായിക്കാം: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

ഒരു ബാക്കപ്പ് ഷെഡ്യൂൾ സജ്ജീകരിക്കുന്നു

ഒരാൾ എന്ത് പറഞ്ഞാലും, അത് പ്രവർത്തിപ്പിക്കാനുള്ള ഏറ്റവും സൗകര്യപ്രദമായ മാർഗം ക്രോൺ ആണ്. ബാക്കപ്പുകൾ സൃഷ്‌ടിക്കാൻ ഞങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നത് ഇതാണ്. ഒരു പൂർണ്ണ ബാക്കപ്പ് സൃഷ്ടിക്കുന്നതിനുള്ള കമാൻഡ് ഉപയോഗിച്ച് നമുക്ക് ആരംഭിക്കാം: wal-g-ൽ ഇതാണ് ലോഞ്ച് ആർഗ്യുമെന്റ് ബാക്കപ്പ്-പുഷ്. എന്നാൽ ആദ്യം, എല്ലാം ശരിയാണെന്ന് ഉറപ്പാക്കാൻ പോസ്റ്റ്ഗ്രെസ് ഉപയോക്താവിൽ നിന്ന് ഈ കമാൻഡ് സ്വമേധയാ പ്രവർത്തിപ്പിക്കുന്നതാണ് നല്ലത് (കൂടാതെ ആക്സസ് പിശകുകളൊന്നുമില്ല):

#!/bin/bash

su - postgres -c '/usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main'

ലോഞ്ച് ആർഗ്യുമെന്റുകൾ ഡാറ്റ ഡയറക്ടറിയിലേക്കുള്ള പാതയെ സൂചിപ്പിക്കുന്നു - പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ നിങ്ങൾക്കത് കണ്ടെത്താനാകുമെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കുന്നു pg_lsclusters.

എല്ലാം പിശകുകളില്ലാതെ പോകുകയും ഡാറ്റ S3 സ്റ്റോറേജിലേക്ക് ലോഡുചെയ്യുകയും ചെയ്താൽ, നിങ്ങൾക്ക് crontab-ൽ ആനുകാലിക ലോഞ്ച് ക്രമീകരിക്കാൻ കഴിയും:

#!/bin/bash

echo "15 4 * * *    /usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main >> /var/log/postgresql/walg_backup.log 2>&1" >> /var/spool/cron/crontabs/postgres
# задаем владельца и выставляем правильные права файлу
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

ഈ ഉദാഹരണത്തിൽ, ബാക്കപ്പ് പ്രക്രിയ എല്ലാ ദിവസവും രാവിലെ 4:15 ന് ആരംഭിക്കുന്നു.

പഴയ ബാക്കപ്പുകൾ ഇല്ലാതാക്കുന്നു

മിക്കവാറും, മെസോസോയിക് കാലഘട്ടത്തിൽ നിന്നുള്ള എല്ലാ ബാക്കപ്പുകളും നിങ്ങൾ സൂക്ഷിക്കേണ്ടതില്ല, അതിനാൽ നിങ്ങളുടെ സംഭരണം ("പൂർണ്ണമായ ബാക്കപ്പുകളും" WAL ലോഗുകളും) ഇടയ്ക്കിടെ "വൃത്തിയാക്കാൻ" ഇത് ഉപയോഗപ്രദമാകും. ഒരു ക്രോൺ ടാസ്ക്കിലൂടെ ഞങ്ങൾ ഇതെല്ലാം ചെയ്യും:

#!/bin/bash

echo "30 6 * * *    /usr/local/bin/wal-g delete before FIND_FULL $(date -d '-10 days' '+%FT%TZ') --confirm >> /var/log/postgresql/walg_delete.log 2>&1" >> /var/spool/cron/crontabs/postgres
# ещё раз задаем владельца и выставляем правильные права файлу (хоть это обычно это и не нужно повторно делать)
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

ക്രോൺ എല്ലാ ദിവസവും രാവിലെ 6:30-ന് ഈ ടാസ്‌ക് പ്രവർത്തിപ്പിക്കും, കഴിഞ്ഞ 10 ദിവസമായി പകർപ്പുകൾ ഒഴികെ എല്ലാം (മുഴുവൻ ബാക്കപ്പുകൾ, ഡെൽറ്റകൾ, WAL-കൾ) ഇല്ലാതാക്കും, എന്നാൽ കുറഞ്ഞത് ഒരു ബാക്കപ്പെങ്കിലും അവശേഷിക്കുന്നു ഇതിനായി നിർദ്ദിഷ്ട തീയതി അങ്ങനെ ഏതെങ്കിലും പോയിന്റ് после തീയതികൾ PITR ൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

ഒരു ബാക്കപ്പിൽ നിന്ന് പുനഃസ്ഥാപിക്കുന്നു

ആരോഗ്യകരമായ ഒരു ഡാറ്റാബേസിന്റെ താക്കോൽ ആനുകാലിക പുനഃസ്ഥാപനവും ഉള്ളിലെ ഡാറ്റയുടെ സമഗ്രത പരിശോധിക്കലും ആണെന്നത് രഹസ്യമല്ല. ഈ വിഭാഗത്തിൽ WAL-G ഉപയോഗിച്ച് എങ്ങനെ വീണ്ടെടുക്കാമെന്ന് ഞാൻ നിങ്ങളോട് പറയും, ഞങ്ങൾ പിന്നീട് പരിശോധനകളെക്കുറിച്ച് സംസാരിക്കും.

ഇത് പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടതാണ് ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ പുനഃസ്ഥാപിക്കാൻ (പ്രൊഡക്ഷൻ അല്ലാത്ത എല്ലാം) നിങ്ങൾ S3-ൽ ഒരു റീഡ് ഓൺലി അക്കൗണ്ട് ഉപയോഗിക്കേണ്ടതുണ്ട്, അങ്ങനെ ആകസ്മികമായി ബാക്കപ്പുകൾ തിരുത്തിയെഴുതാതിരിക്കുക. WAL-G-യുടെ കാര്യത്തിൽ, നിങ്ങൾ ഗ്രൂപ്പ് നയത്തിൽ S3 ഉപയോക്താവിനായി ഇനിപ്പറയുന്ന അവകാശങ്ങൾ സജ്ജീകരിക്കേണ്ടതുണ്ട് (പ്രഭാവം: അനുവദിക്കുക): s3:GetObject, s3:ListBucket, s3:GetBucketLocation. കൂടാതെ, തീർച്ചയായും, സജ്ജമാക്കാൻ മറക്കരുത് archive_mode=ഓഫ് ക്രമീകരണ ഫയലിൽ postgresql.conf, അതിനാൽ നിങ്ങളുടെ ടെസ്റ്റ് ഡാറ്റാബേസ് നിശബ്ദമായി ബാക്കപ്പ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നില്ല.

കൈയുടെ ചെറിയ ചലനത്തിലൂടെയാണ് പുനഃസ്ഥാപനം നടത്തുന്നത് എല്ലാ PostgreSQL ഡാറ്റയും ഇല്ലാതാക്കുന്നു (ഉപയോക്താക്കൾ ഉൾപ്പെടെ), അതിനാൽ ഇനിപ്പറയുന്ന കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ ദയവായി അതീവ ജാഗ്രത പാലിക്കുക.

#!/bin/bash

# если есть балансировщик подключений (например, pgbouncer), то вначале отключаем его, чтобы он не нарыгал ошибок в лог
service pgbouncer stop
# если есть демон, который перезапускает упавшие процессы (например, monit), то останавливаем в нём процесс мониторинга базы (у меня это pgsql12)
monit stop pgsql12
# или останавливаем мониторинг полностью
service monit stop
# останавливаем саму базу данных
service postgresql stop
# удаляем все данные из текущей базы (!!!); лучше предварительно сделать их копию, если есть свободное место на диске
rm -rf /var/lib/postgresql/12/main
# скачиваем резервную копию и разархивируем её
su - postgres -c '/usr/local/bin/wal-g backup-fetch /var/lib/postgresql/12/main LATEST'
# помещаем рядом с базой специальный файл-сигнал для восстановления (см. https://postgrespro.ru/docs/postgresql/12/runtime-config-wal#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY ), он обязательно должен быть создан от пользователя postgres
su - postgres -c 'touch /var/lib/postgresql/12/main/recovery.signal'
# запускаем базу данных, чтобы она инициировала процесс восстановления
service postgresql start

വീണ്ടെടുക്കൽ പ്രക്രിയ പരിശോധിക്കാൻ ആഗ്രഹിക്കുന്നവർക്കായി, ഒരു ചെറിയ ബാഷ് മാജിക് ചുവടെ തയ്യാറാക്കിയിട്ടുണ്ട്, അതിനാൽ വീണ്ടെടുക്കലിൽ പ്രശ്നങ്ങൾ ഉണ്ടായാൽ, പൂജ്യമല്ലാത്ത എക്സിറ്റ് കോഡ് ഉപയോഗിച്ച് സ്ക്രിപ്റ്റ് ക്രാഷ് ചെയ്യും. ഈ ഉദാഹരണത്തിൽ, സിഗ്നൽ ഫയൽ ഇല്ലാതാക്കിയിട്ടുണ്ടോ എന്നറിയാൻ 120 സെക്കൻഡ് (വീണ്ടെടുക്കാൻ ആകെ 5 മിനിറ്റ്) സമയപരിധിയോടെ 10 പരിശോധനകൾ നടത്തുന്നു (ഇത് വീണ്ടെടുക്കൽ വിജയകരമാണെന്ന് അർത്ഥമാക്കും):

#!/bin/bash

CHECK_RECOVERY_SIGNAL_ITER=0
while [ ${CHECK_RECOVERY_SIGNAL_ITER} -le 120 ]
do
    if [ ! -f "/var/lib/postgresql/12/main/recovery.signal" ]
    then
        echo "recovery.signal removed"
        break
    fi
    sleep 5
    ((CHECK_RECOVERY_SIGNAL_ITER+1))
done

# если после всех проверок файл всё равно существует, то падаем с ошибкой
if [ -f "/var/lib/postgresql/12/main/recovery.signal" ]
then
    echo "recovery.signal still exists!"
    exit 17
fi

വിജയകരമായ വീണ്ടെടുക്കലിനുശേഷം, എല്ലാ പ്രക്രിയകളും തിരികെ ആരംഭിക്കാൻ മറക്കരുത് (pgbouncer/monit, മുതലായവ).

വീണ്ടെടുക്കലിനുശേഷം ഡാറ്റ പരിശോധിക്കുന്നു

പുനഃസ്ഥാപിച്ചതിന് ശേഷം ഡാറ്റാബേസിന്റെ സമഗ്രത പരിശോധിക്കേണ്ടത് അത്യന്താപേക്ഷിതമാണ്, അതിനാൽ തകർന്ന/വളഞ്ഞ ബാക്കപ്പ് ഉള്ള ഒരു സാഹചര്യം ഉണ്ടാകില്ല. സൃഷ്ടിച്ച ഓരോ ആർക്കൈവിലും ഇത് ചെയ്യുന്നതാണ് നല്ലത്, എന്നാൽ എവിടെ, എങ്ങനെ നിങ്ങളുടെ ഭാവനയെ മാത്രം ആശ്രയിച്ചിരിക്കുന്നു (നിങ്ങൾക്ക് ഒരു മണിക്കൂർ അടിസ്ഥാനത്തിൽ വ്യക്തിഗത സെർവറുകൾ ഉയർത്താം അല്ലെങ്കിൽ CI-യിൽ ഒരു പരിശോധന നടത്താം). എന്നാൽ കുറഞ്ഞത്, ഡാറ്റാബേസിലെ ഡാറ്റയും സൂചികകളും പരിശോധിക്കേണ്ടത് ആവശ്യമാണ്.

ഡാറ്റ പരിശോധിക്കുന്നതിന്, അത് ഒരു ഡംപിലൂടെ പ്രവർത്തിപ്പിച്ചാൽ മതി, പക്ഷേ ഡാറ്റാബേസ് സൃഷ്ടിക്കുമ്പോൾ ചെക്ക്സം പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നത് നല്ലതാണ് (ഡാറ്റ ചെക്ക്സംസ്):

#!/bin/bash

if ! su - postgres -c 'pg_dumpall > /dev/null'
then
    echo 'pg_dumpall failed'
    exit 125
fi

സൂചികകൾ പരിശോധിക്കാൻ - നിലവിലുണ്ട് amcheck മൊഡ്യൂൾ, നമുക്ക് അതിനുള്ള sql അന്വേഷണം എടുക്കാം WAL-G ടെസ്റ്റുകൾ അതിനു ചുറ്റും ഒരു ചെറിയ യുക്തി നിർമ്മിക്കുക:

#!/bin/bash

# добавляем sql-запрос для проверки в файл во временной директории
cat > /tmp/amcheck.sql << EOF
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree'
AND c.relpersistence != 't'
AND i.indisready AND i.indisvalid;
EOF
chown postgres: /tmp/amcheck.sql

# добавляем скрипт для запуска проверок всех доступных баз в кластере
# (обратите внимание что переменные и запуск команд – экранированы)
cat > /tmp/run_amcheck.sh << EOF
for DBNAME in $(su - postgres -c 'psql -q -A -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" ')
do
    echo "Database: ${DBNAME}"
    su - postgres -c "psql -f /tmp/amcheck.sql -v 'ON_ERROR_STOP=1' ${DBNAME}" && EXIT_STATUS=$? || EXIT_STATUS=$?
    if [ "${EXIT_STATUS}" -ne 0 ]
    then
        echo "amcheck failed on DB: ${DBNAME}"
        exit 125
    fi
done
EOF
chmod +x /tmp/run_amcheck.sh

# запускаем скрипт
/tmp/run_amcheck.sh > /tmp/amcheck.log

# для проверки что всё прошло успешно можно проверить exit code или grep’нуть ошибку
if grep 'amcheck failed' "/tmp/amcheck.log"
then
    echo 'amcheck failed: '
    cat /tmp/amcheck.log
    exit 125
fi

ചുരുക്കി പറഞ്ഞാൽ

പ്രസിദ്ധീകരണം തയ്യാറാക്കുന്നതിൽ സഹായിച്ച ആൻഡ്രി ബോറോഡിനോടുള്ള എന്റെ നന്ദിയും WAL-G യുടെ വികസനത്തിന് അദ്ദേഹം നൽകിയ സംഭാവനയ്ക്ക് പ്രത്യേക നന്ദിയും അറിയിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു!

ഇതോടെ ഈ കുറിപ്പ് അവസാനിക്കുന്നു. സജ്ജീകരണത്തിന്റെ എളുപ്പവും നിങ്ങളുടെ കമ്പനിയിൽ ഈ ഉപകരണം ഉപയോഗിക്കുന്നതിനുള്ള വലിയ സാധ്യതകളും അറിയിക്കാൻ എനിക്ക് കഴിഞ്ഞുവെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഞാൻ WAL-G-യെ കുറിച്ച് ഒരുപാട് കേട്ടിട്ടുണ്ട്, പക്ഷേ ഒരിക്കലും ഇരുന്നു മനസ്സിലാക്കാൻ വേണ്ടത്ര സമയം കിട്ടിയില്ല. ഞാൻ അത് വീട്ടിൽ നടപ്പിലാക്കിയ ശേഷം, ഈ ലേഖനം എന്നിൽ നിന്ന് പുറത്തുവന്നു.

വെവ്വേറെ, WAL-G ന് ഇനിപ്പറയുന്ന DBMS-ൽ പ്രവർത്തിക്കാൻ കഴിയുമെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്:

• MySQL / MariaDB;
• മോംഗോഡിബി;
• ഫൗണ്ടേഷൻ ഡിബി;
• കമ്മിറ്റുകളുടെ അടിസ്ഥാനത്തിൽ വിലയിരുത്തിയാൽ, ഇനിയും പലതും പ്രതീക്ഷിക്കുന്നു!

അവലംബം: www.habr.com