WAL-G៖ ការបម្រុងទុក និងការស្តារ PostgreSQL DBMS

វាត្រូវបានគេស្គាល់ជាយូរមកហើយថាការធ្វើឱ្យការបម្រុងទុកចូលទៅក្នុង SQL dumps (ដោយប្រើ pg_dump ឬ pg_dumpall) មិនមែនជាគំនិតល្អទេ។ ដើម្បីបម្រុងទុក PostgreSQL DBMS វាជាការប្រសើរក្នុងការប្រើពាក្យបញ្ជា pg_basebackupដែលបង្កើតច្បាប់ចម្លងគោលពីរនៃកំណត់ហេតុ WAL ។ ប៉ុន្តែនៅពេលដែលអ្នកចាប់ផ្តើមសិក្សាដំណើរការទាំងមូលនៃការបង្កើតច្បាប់ចម្លង និងការស្តារឡើងវិញ អ្នកនឹងយល់ថាអ្នកត្រូវសរសេរយ៉ាងហោចណាស់បីកង់បីសម្រាប់ដំណើរការនេះ និងមិនធ្វើឱ្យអ្នកឈឺចាប់ទាំងខាងលើ និងខាងក្រោម។ ដើម្បីកាត់បន្ថយការឈឺចាប់ WAL-G ត្រូវបានបង្កើតឡើង។

WAL-G គឺ​ជា​ឧបករណ៍​ដែល​សរសេរ​នៅ​ក្នុង Go សម្រាប់​ការ​បម្រុង​ទុក និង​ស្ដារ​មូលដ្ឋាន​ទិន្នន័យ PostgreSQL (ហើយថ្មីៗនេះ MySQL/MariaDB, MongoDB និង FoundationDB) វាគាំទ្រការធ្វើការជាមួយ Amazon S3 storage (និង analogues ឧទាហរណ៍ Yandex Object Storage) ក៏ដូចជា Google Cloud Storage, Azure Storage, Swift Object Storage និងសាមញ្ញជាមួយប្រព័ន្ធឯកសារ។ ការរៀបចំទាំងមូលចុះទៅជំហានសាមញ្ញៗ ប៉ុន្តែដោយសារតែអត្ថបទអំពីវាត្រូវបានរាយប៉ាយពាសពេញអ៊ីនធឺណិត មិនមានសៀវភៅណែនាំអំពីរបៀបពេញលេញដែលនឹងរួមបញ្ចូលជំហានទាំងអស់ពីដើមដល់ចប់ (មានប្រកាសជាច្រើននៅលើ Habre, ប៉ុន្តែចំណុចជាច្រើនត្រូវបានខកខាននៅទីនោះ) ។

អត្ថបទនេះត្រូវបានសរសេរជាចម្បង ដើម្បីរៀបចំជាប្រព័ន្ធនូវចំណេះដឹងរបស់ខ្ញុំ ខ្ញុំមិនមែនជា DBA ហើយខ្ញុំអាចបង្ហាញខ្លួនឯងជាភាសារបស់ឧបាសកនៅកន្លែងណាមួយ ដូច្នេះការកែតម្រូវណាមួយត្រូវបានស្វាគមន៍!

ដោយឡែកពីគ្នា ខ្ញុំកត់សម្គាល់ថាអ្វីគ្រប់យ៉ាងខាងក្រោមគឺពាក់ព័ន្ធ និងត្រូវបានសាកល្បងសម្រាប់ PostgreSQL 12.3 នៅលើអ៊ូប៊ុនទូ 18.04 ពាក្យបញ្ជាទាំងអស់ត្រូវតែប្រតិបត្តិជាអ្នកប្រើប្រាស់ដែលមានសិទ្ធិ។

ការកំណត់

នៅពេលសរសេរអត្ថបទនេះ កំណែស្ថេរភាពនៃ WAL-G គឺ v0.2.15 (មីនា 2020). នេះជាអ្វីដែលយើងនឹងប្រើ (ប៉ុន្តែប្រសិនបើអ្នកចង់បង្កើតវាដោយខ្លួនឯងពីសាខាមេនោះ ឃ្លាំង github មានការណែនាំទាំងអស់សម្រាប់រឿងនេះ។) ដើម្បីទាញយក និងដំឡើង អ្នកត្រូវធ្វើ៖

#!/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 bucket" និងគ្រាប់ចុចចូល។

អត្ថបទមុនទាំងអស់អំពី WAL-G បានប្រើការកំណត់រចនាសម្ព័ន្ធដោយប្រើអថេរបរិស្ថាន ប៉ុន្តែជាមួយនឹងការចេញផ្សាយនេះ ការកំណត់អាចមានទីតាំងនៅ ឯកសារ .walg.json នៅក្នុងថតផ្ទះរបស់អ្នកប្រើ postgres ។ ដើម្បីបង្កើតវា ដំណើរការស្គ្រីប bash ខាងក្រោម៖

#!/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 របស់អ្នកដែលការបម្រុងទុកនឹងត្រូវបានផ្ទុកឡើង (អ្នកអាចទៅ root ឬទៅថតមួយ);
• AWS_ACCESS_KEY_ID - សោចូលប្រើក្នុង S3 (នៅក្នុងករណីនៃការងើបឡើងវិញនៅលើម៉ាស៊ីនមេសាកល្បង សោទាំងនេះត្រូវតែមានគោលការណ៍ ReadOnly! នេះត្រូវបានពិពណ៌នាលម្អិតបន្ថែមទៀតនៅក្នុងផ្នែកស្តីពីការងើបឡើងវិញ។);
• AWS_SECRET_ACCESS_KEY - សោសម្ងាត់នៅក្នុងការផ្ទុក S3;
• WALG_COMPRESSION_METHOD - វិធីសាស្ត្របង្ហាប់ វាជាការប្រសើរក្នុងការប្រើ Brotli (ចាប់តាំងពីនេះគឺជាមធ្យមមាសរវាងទំហំចុងក្រោយ និងល្បឿនបង្ហាប់/បង្រួម);
• WALG_DELTA_MAX_STEPS - ចំនួននៃ "deltas" មុនពេលបង្កើតការបម្រុងទុកពេញលេញ (ពួកគេសន្សំសំចៃពេលវេលានិងទំហំនៃទិន្នន័យដែលបានទាញយកប៉ុន្តែអាចបន្ថយដំណើរការស្តារឡើងវិញបន្តិចដូច្នេះវាមិនត្រូវបានណែនាំឱ្យប្រើតម្លៃធំទេ);
• PGDATA - ផ្លូវទៅកាន់ថតដែលមានទិន្នន័យមូលដ្ឋានទិន្នន័យរបស់អ្នក (អ្នកអាចស្វែងយល់ដោយដំណើរការពាក្យបញ្ជា pg_lsclusters);
• PGHOST - ការភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ ជាមួយនឹងការបម្រុងទុកមូលដ្ឋាន វាជាការប្រសើរក្នុងការធ្វើវាតាមរយៈរន្ធ unix ដូចក្នុងឧទាហរណ៍នេះ។

ប៉ារ៉ាម៉ែត្រផ្សេងទៀតអាចរកបាននៅក្នុងឯកសារ៖ 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_level - តើព័ត៌មានប៉ុន្មានដែលត្រូវសរសេរក្នុងកំណត់ហេតុ WAL, "ចម្លង" - សរសេរអ្វីគ្រប់យ៉ាង;
• របៀបបណ្ណសារ - បើកការទាញយកកំណត់ហេតុ WAL ដោយប្រើពាក្យបញ្ជាពីប៉ារ៉ាម៉ែត្រ archive_command;
• archive_command - ពាក្យបញ្ជាសម្រាប់ការរក្សាទុកកំណត់ហេតុ WAL ដែលបានបញ្ចប់។
• បណ្ណសារ_អស់ពេល - ការរក្សាទុកកំណត់ហេតុត្រូវបានអនុវត្តតែនៅពេលដែលវាត្រូវបានបញ្ចប់ ប៉ុន្តែប្រសិនបើម៉ាស៊ីនមេរបស់អ្នកផ្លាស់ប្តូរ / បន្ថែមទិន្នន័យតិចតួចទៅក្នុងមូលដ្ឋានទិន្នន័យ នោះវាសមហេតុផលក្នុងការកំណត់ដែនកំណត់នៅទីនេះក្នុងរយៈពេលប៉ុន្មានវិនាទី បន្ទាប់ពីនោះពាក្យបញ្ជាការរក្សាទុកនឹងត្រូវបានហៅដោយបង្ខំ (ខ្ញុំសរសេរយ៉ាងស៊ីជម្រៅទៅលើមូលដ្ឋានទិន្នន័យជារៀងរាល់វិនាទី ដូច្នេះខ្ញុំបានសម្រេចចិត្តមិនកំណត់ប៉ារ៉ាម៉ែត្រនេះនៅក្នុងផលិតកម្មទេ។);
• restore_command - ពាក្យបញ្ជាដើម្បីស្ដារកំណត់ហេតុ WAL ពីការបម្រុងទុកនឹងត្រូវបានប្រើប្រសិនបើ "ការបម្រុងទុកពេញលេញ" (ការបម្រុងទុកមូលដ្ឋាន) ខ្វះការផ្លាស់ប្តូរចុងក្រោយបំផុតនៅក្នុងមូលដ្ឋានទិន្នន័យ។

អ្នកអាចអានបន្ថែមអំពីប៉ារ៉ាម៉ែត្រទាំងនេះនៅក្នុងការបកប្រែឯកសារផ្លូវការ៖ https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

រៀបចំកាលវិភាគបម្រុងទុក

អ្វីដែលគេអាចនិយាយបាន វិធីងាយស្រួលបំផុតដើម្បីដំណើរការវាគឺ cron ។ នេះជាអ្វីដែលយើងនឹងកំណត់រចនាសម្ព័ន្ធដើម្បីបង្កើតការបម្រុងទុក។ ចូរចាប់ផ្តើមជាមួយនឹងពាក្យបញ្ជាដើម្បីបង្កើតការបម្រុងទុកពេញលេញ: នៅក្នុង wal-g នេះគឺជាអាគុយម៉ង់ចាប់ផ្តើម ការបម្រុងទុក - រុញ. ប៉ុន្តែជាដំបូង វាជាការប្រសើរក្នុងការដំណើរការពាក្យបញ្ជានេះដោយដៃពីអ្នកប្រើប្រាស់ postgres ដើម្បីប្រាកដថាអ្វីៗទាំងអស់គឺល្អ (ហើយមិនមានកំហុសក្នុងការចូលប្រើទេ)៖

#!/bin/bash

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

អាគុយម៉ង់នៃការបើកដំណើរការបង្ហាញពីផ្លូវទៅកាន់ថតទិន្នន័យ - ខ្ញុំរំលឹកអ្នកថាអ្នកអាចស្វែងរកវាបានដោយការរត់ pg_lsclusters.

ប្រសិនបើអ្វីៗដំណើរការដោយគ្មានកំហុស ហើយទិន្នន័យត្រូវបានផ្ទុកទៅក្នុង S3 storage បន្ទាប់មកអ្នកអាចកំណត់រចនាសម្ព័ន្ធការបើកដំណើរការតាមកាលកំណត់នៅក្នុង 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 ព្រឹក។

ការលុបការបម្រុងទុកចាស់

ភាគច្រើន អ្នកមិនចាំបាច់រក្សាការបម្រុងទុកទាំងអស់ពីសម័យ Mesozoic នោះទេ ដូច្នេះវានឹងមានប្រយោជន៍ក្នុងការ "សម្អាត" ការផ្ទុករបស់អ្នកជាទៀងទាត់ (ទាំង "ការបម្រុងទុកពេញលេញ" និងកំណត់ហេតុ WAL) ។ យើងនឹងធ្វើទាំងអស់នេះតាមរយៈកិច្ចការ cron៖

#!/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

Cron នឹងដំណើរការកិច្ចការនេះជារៀងរាល់ថ្ងៃនៅម៉ោង 6:30 ព្រឹក ដោយលុបអ្វីៗទាំងអស់ (ការបម្រុងទុកពេញលេញ deltas និង WALs) លើកលែងតែច្បាប់ចម្លងសម្រាប់រយៈពេល 10 ថ្ងៃចុងក្រោយ ប៉ុន្តែទុកយ៉ាងហោចណាស់ការបម្រុងទុកមួយ រហូតដល់ទៅ កាលបរិច្ឆេទដែលបានបញ្ជាក់ដូច្នេះចំណុចណាមួយ។ после កាលបរិច្ឆេទត្រូវបានរួមបញ្ចូលក្នុង PITR ។

ការស្ដារឡើងវិញពីការបម្រុងទុក

វាគ្មានអាថ៌កំបាំងទេដែលគន្លឹះនៃមូលដ្ឋានទិន្នន័យដែលមានសុខភាពល្អគឺការស្ដារឡើងវិញតាមកាលកំណត់ និងការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃទិន្នន័យនៅខាងក្នុង។ ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដើម្បីស្ដារដោយប្រើ WAL-G នៅក្នុងផ្នែកនេះ ហើយយើងនឹងនិយាយអំពីការត្រួតពិនិត្យនៅពេលក្រោយ។

វាគួរឱ្យកត់សម្គាល់ដាច់ដោយឡែក ដើម្បីស្ដារនៅក្នុងបរិយាកាសសាកល្បង (អ្វីគ្រប់យ៉ាងដែលមិនមែនជាការផលិត) អ្នកត្រូវប្រើគណនី Read Only នៅក្នុង 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

សម្រាប់អ្នកដែលចង់ពិនិត្យមើលដំណើរការងើបឡើងវិញ បំណែកតូចមួយនៃវេទមន្ត bash ត្រូវបានរៀបចំនៅខាងក្រោម ដូច្នេះក្នុងករណីមានបញ្ហាក្នុងការសង្គ្រោះ ស្គ្រីបនឹងគាំងជាមួយនឹងលេខកូដចេញដែលមិនសូន្យ។ ក្នុងឧទាហរណ៍នេះ ការត្រួតពិនិត្យចំនួន 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)។ ប៉ុន្តែនៅអប្បបរមា ចាំបាច់ត្រូវពិនិត្យមើលទិន្នន័យ និងលិបិក្រមនៅក្នុងមូលដ្ឋានទិន្នន័យ។

ដើម្បីពិនិត្យមើលទិន្នន័យ វាគ្រប់គ្រាន់ហើយក្នុងការដំណើរការវាតាមរយៈការបោះចោល ប៉ុន្តែវាជាការប្រសើរដែលថានៅពេលបង្កើតមូលដ្ឋានទិន្នន័យ អ្នកបានបើកដំណើរការ checksums (ការពិនិត្យទិន្នន័យ):

#!/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

សង្ខេប

ខ្ញុំសូមថ្លែងអំណរគុណចំពោះ Andrey Borodin សម្រាប់ជំនួយរបស់គាត់ក្នុងការរៀបចំការបោះពុម្ពផ្សាយ និងអរគុណជាពិសេសចំពោះការរួមចំណែករបស់គាត់ក្នុងការអភិវឌ្ឍន៍ WAL-G!

នេះបញ្ចប់កំណត់ចំណាំនេះ។ ខ្ញុំសង្ឃឹមថាខ្ញុំអាចបង្ហាញពីភាពងាយស្រួលនៃការដំឡើង និងសក្តានុពលដ៏ធំសម្រាប់ការប្រើប្រាស់ឧបករណ៍នេះនៅក្នុងក្រុមហ៊ុនរបស់អ្នក។ ខ្ញុំបានលឺច្រើនអំពី WAL-G ប៉ុន្តែមិនដែលមានពេលគ្រប់គ្រាន់ដើម្បីអង្គុយចុះ ហើយដោះស្រាយវាទេ។ ហើយបន្ទាប់ពីខ្ញុំបានអនុវត្តវានៅផ្ទះ អត្ថបទនេះបានចេញពីខ្ញុំ។

ដោយឡែកវាគួរឱ្យកត់សម្គាល់ថា WAL-G ក៏អាចធ្វើការជាមួយ DBMS ខាងក្រោមបានដែរ៖

• MySQL / MariaDB;
• MongoDB;
• មូលនិធិឌីប៊ី;
• ហើយការវិនិច្ឆ័យដោយការប្តេជ្ញាចិត្ត មានការរំពឹងទុកជាច្រើនទៀត!

ប្រភព: www.habr.com