Откат#

Внимание

Действия, описанные ниже, нужно выполнять суперпользователем.

Для определения необходимости восстановления СУБД к исходному состоянию, необходимо изучить лог.

  • Восстанавливать СУБД нужно, если последней строкой записи является:

    • «В процессе обновления возникла ошибка»;

    • «Восстановление СУБД Pangolin в автоматическом режиме недоступно для этого типа ошибки»;

    • «Восстановление СУБД Pangolin запущено»;

  • Восстанавливать СУБД не нужно, если последней строкой записи является:

    • «Обновление СУБД Pangolin успешно завершено»;

    • «Восстановление СУБД Pangolin успешно завершено».

Внимание

Процесс отката/восстановления встроен в процесс обновления. Отдельный запуск скрипта отката не предусмотрен.

Откат возможен только на исходную версию, с которой производилось обновление. Для ориентирования по поддерживаемым версиям обновления воспользуйтесь таблицей.

Откат вручную к исходной версии и состоянию кластера#

Восстановление после неудачного обновления с переносом данных#

Данный раздел рассматривает ручное восстановление с переносом данных СУБД Pangolin после неудачного обновления с версии 5.4.x/5.5.x до 6.4.x.

Внимание

Каждый пункт будет начинаться с информации в круглых скобках, о том на каких узлах необходимо выполнить данный шаг. Все команды необходимо выполнять последовательно.

Например, сочетание (master, replica) означает, что действия, указанные в пункте, необходимо выполнить сначала на основном узле, затем на реплике (при этом выполнять действия на арбитре не нужно).

Восстановление СУБД может осуществляться пользователем с правами суперпользователя, а также пользователем postgres.

В названиях rpm-пакетов при необходимости в блоках кода замените наименование ОС.

Шаг №1. Остановка компонентов СУБД Pangolin#

  1. (master) В случае конфигурации с Pangolin Manager переведите компонент в режим паузы:

    sudo -iu postgres
/usr/patroni/patroni_venv/bin/patronictl -c /etc/patroni/postgres.yml edit-config --set 'pause=true' --force
/opt/pangolin-manager/bin/pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml edit-config --set 'pause=true' --force
exit

    Примечание

    Используйте два варианта остановки (команды в примере выше) для новой и старой версии компонента. Поскольку инструкция рассчитана на любой момент падения, необходимо убедиться в том, что ни одна версия не активна.

  2. (replica, master, arbiter) Остановите все компоненты СУБД Pangolin:

    sudo systemctl stop pgbouncer
sudo systemctl stop pangolin-pooler
sudo systemctl stop pg_certs_rotate_agent
sudo systemctl stop pangolin-certs-rotate
sudo systemctl stop pangolin_reencrypt@postgres.service
sudo systemctl stop pangolin_reencrypt@kmadmin_pg.service
sudo systemctl stop pangolin-auth-reencrypt@postgres.service
sudo systemctl stop pangolin-auth-reencrypt@kmadmin_pg.service

    Дополнительно выполните:

    • для конфигурации без Pangolin Manager:

      sudo systemctl stop postgresql

    • Для конфигурации с Pangolin Manager:

      sudo -iu postgres
/usr/pangolin/bin/pg_ctl stop -D /pgdata/05/data
exit
sudo systemctl stop patroni
sudo systemctl stop pangolin-manager

    • Для конфигурации с etcd:

      sudo systemctl stop etcd

  3. (replica, master, arbiter) Остановите сторонние компоненты:

    sudo systemctl stop crond

Шаг 2. Удаление компонента pangolin-ansible-venv-controlled#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-ansible-venv-controlled

Шаг 3. Удаление компонента pangolin_reencrypt#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-auth-reencrypt
sudo rm -rf /opt/pangolin-auth-reencrypt
sudo rm -rf /etc/pangolin-auth-reencrypt

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /opt/pangolin-common/bin /etc/postgres
sudo chown postgres:kmadmin_pg /etc/postgres /opt/pangolin-common /opt/pangolin-common/bin
sudo chmod 0771 /etc/postgres
sudo chmod 0710 /opt/pangolin-common /opt/pangolin-common/bin
sudo cp -ra ~/pangolin/cache/backup/pangolin_reencrypt/pangolin_reencrypt@.service /etc/systemd/system/pangolin_reencrypt@.service
sudo cp -ra ~/pangolin/cache/backup/pangolin_reencrypt/pg_auth_reencrypt           /opt/pangolin-common/bin/pg_auth_reencrypt
sudo cp -ra ~/pangolin/cache/backup/pangolin_reencrypt/enc_util.cfg                /etc/postgres/enc_util.cfg
sudo cp -ra ~/pangolin/cache/backup/pangolin_reencrypt/enc_params.cfg.kmadmin_pg   /etc/postgres/enc_params.cfg.kmadmin_pg
sudo cp -ra ~/pangolin/cache/backup/pangolin_reencrypt/enc_params.cfg.postgres     /etc/postgres/enc_params.cfg.postgres

Шаг 4. Восстановление компонента pg_certs_rotate_agent#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-certs-rotate
sudo rm -rf /opt/pangolin-certs-rotate
sudo rm -rf /etc/pangolin-certs-rotate

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /opt/pangolin-common/bin /etc/postgres /pgerrorlogs/05/pg_certs_rotate_agent
sudo chown postgres:kmadmin_pg /etc/postgres /opt/pangolin-common /opt/pangolin-common/bin  
sudo chmod 0700 /pgerrorlogs/05 /pgerrorlogs/05/pg_certs_rotate_agent
sudo chown postgres:postgres /pgerrorlogs/05 /pgerrorlogs/05/pg_certs_rotate_agent
sudo chmod 0771 /etc/postgres
sudo chmod 0710 /opt/pangolin-common /opt/pangolin-common/bin
sudo cp -ra ~/pangolin/cache/backup/pg_certs_rotate_agent/pg_certs_rotate_agent.service /etc/systemd/system/pg_certs_rotate_agent.service
sudo cp -ra ~/pangolin/cache/backup/pg_certs_rotate_agent/pg_certs_rotate_agent         /opt/pangolin-common/bin/pg_certs_rotate_agent
sudo cp -ra ~/pangolin/cache/backup/pg_certs_rotate_agent/pg_certs_rotate_agent.yml     /etc/postgres/pg_certs_rotate_agent.yml

Шаг 5. Удаление компонента pangolin-diagnostic-tools#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-diagnostic-tool
sudo rm -rf /opt/pangolin-diagnostic-tool

Шаг 6. Удаление компонента pangolin-security-utilities#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-security-utilities
sudo rm -rf /opt/pangolin-security-utilities
sudo rm -rf /etc/pangolin-security-utilities
sudo mkdir -p /etc/postgres
sudo chown postgres:kmadmin_pg /etc/postgres
sudo chmod 0771 /etc/postgres
sudo cp -ra ~/pangolin/cache/backup/general/enc_connection_settings_cert.cfg /etc/postgres/enc_connection_settings_cert.cfg
sudo cp -ra ~/pangolin/cache/backup/general/enc_connection_settings.cfg      /etc/postgres/enc_connection_settings.cfg

Шаг 7. Восстановление компонента manage_backup#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-backup-tools
sudo rm -rf /opt/pangolin-backup-tools
sudo rm -rf /etc/pangolin-backup-tools

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /opt/omni/lbin/
sudo chown root:root /opt/omni/lbin/
sudo chmod 0755 /opt/omni/lbin/ 
sudo cp -ra ~/pangolin/cache/backup/manage_backup/* /opt/omni/lbin/

Шаг 8. Восстановление компонента Pangolin Pooler#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-pooler
sudo rm -rf /opt/pangolin-pooler
sudo rm -rf /etc/pangolin-pooler

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /etc/pgbouncer/
sudo chown postgres:postgres  /etc/pgbouncer/ 
sudo chmod 0700  /etc/pgbouncer/ 
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/pgbouncer.service /etc/systemd/system/pgbouncer.service
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/pgbouncer.ini     /etc/pgbouncer/pgbouncer.ini
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/userlist.txt      /etc/pgbouncer/userlist.txt
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/pgbouncer         /usr/local/bin/pgbouncer
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/pgbouncer.1       /usr/local/share/man/man1/pgbouncer.1
sudo cp -ra ~/pangolin/cache/backup/pgbouncer/pgbouncer.5       /usr/local/share/man/man5/pgbouncer.5

Шаг 9. Восстановление компонента Pangolin Manager#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-manager
sudo rm -rf /opt/pangolin-manager
sudo rm -rf /etc/pangolin-manager

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /etc/patroni/ /usr/patroni
sudo chown postgres:postgres /etc/patroni/ /usr/patroni
sudo chmod 0700 /etc/patroni/ /usr/patroni
sudo cp -ra ~/pangolin/cache/backup/patroni/patroni.service      /etc/systemd/system/patroni.service
sudo cp -ra ~/pangolin/cache/backup/patroni/postgres.yml         /etc/patroni/postgres.yml
sudo cp -ra ~/pangolin/cache/backup/patroni/reload_pgbouncer.sh  /etc/patroni/reload_pgbouncer.sh
sudo cp -ra ~/pangolin/cache/backup/patroni/patroni/*            /usr/patroni/

Шаг 10. Удаление pangolin-license#

  1. (master, replica) Удалите pangolin-license:

    sudo rm -rf /opt/pangolin_license

Шаг 11. Восстановление компонента pangolin-dbms#

  1. (master, replica) Удалите пакет компонента:

    sudo dnf remove -y pangolin-dbms-6.4
sudo dnf remove -y pangolin-dbms-6.4-client
sudo rm -rf /usr/pangolin-6.4 /usr/pangolin-dbms-6.4-client
sudo rm -rf /pgdata/06 /pgerrorlogs/06 /pgarclogs/06
 
#при необходимости
sudo dnf remove -y pangolin-timescaledb-6.4

  2. (master, replica) Восстановите рабочие файлы компонента:

    sudo mkdir -p /pgdata/05/data/
sudo chmod -R 0700 /pgdata
sudo chown -R postgres:postgres /pgdata
sudo dnf install -y /home/pprb_dev/pangolin/cache/backup/pangolin_dbms/platform-v-pangolin-dbms-05.005.04-sberlinux8.8.x86_64.rpm
sudo cp -ra ~/pangolin/cache/backup/pangolin_dbms/pangolin-5.5.4/* /usr/pangolin-5.5.4/
sudo chmod 0701 /usr/pangolin-5.5.4
sudo ln -sfnv /usr/pangolin-5.5.4 /usr/pangolin
sudo rm -rf /etc/pangolin-auth-encryption
sudo cp -ra ~/pangolin/cache/backup/general/enc_utils_auth_settings.cfg /etc/postgres/enc_utils_auth_settings.cfg
 
#для конфигурации без Pangolin Manager
sudo cp -r ~/pangolin/cache/backup/pangolin_dbms/postgresql.service /etc/systemd/system/postgresql.service

  3. (master) Восстановите локальную резервную копию:

    sudo -iu postgres
PGPASSWORD=<пароль пользователя postgres> /usr/pangolin-5/bin/pg_probackup restore -B /pgarclogs/cache/backup/pangolin_dbms --instance clustername -j 14 --progress --restore-command=cp /pgarclogs/cache/backup/pangolin_dbms/wal/clustername/%f  %p -w
exit
sudo cp -r ~/pangolin/cache/backup/pangolin_dbms/*.conf            /pgdata/05/data/

    • Дополнительно для конфигурации с Pangolin Manager:

      sudo cp -ra ~/pangolin/cache/backup/patroni/patroni.dynamic.json   /pgdata/05/data/patroni.dynamic.json

Шаг 12. Завершающие действия#

  1. (master, replica) Восстановите сторонние файлы:

    sudo cp -ra ~/pangolin/cache/backup/general/.bash_profile  /home/postgres/.bash_profile
sudo cp -ra ~/pangolin/cache/backup/general/10-kmadmin_pg  /etc/sudoers.d/10-kmadmin_pg
sudo cp -ra ~/pangolin/cache/backup/general/10-postgres    /etc/sudoers.d/10-postgres
sudo cp -ra ~/pangolin/cache/backup/general/dynmotd.sh     /usr/local/sbin/dynmotd.sh    # дополнительно восстановить на ноде arbiter
sudo ln -sfnv /pgdata/05 /pgdata/data
sudo rm -rf /pgdata/05/data/recovery.signal

Шаг 13. Запуск компонентов СУБД Pangolin#

  1. (master, replica, etcd) Запустите компоненты Pangolin:

    sudo systemctl daemon-reload

sudo systemctl restart pangolin-pooler
sudo systemctl restart pangolin-certs-rotate
sudo systemctl restart pangolin-auth-reencrypt@postgres
sudo systemctl restart pangolin-auth-reencrypt@kmadmin_pg

    Дополнительно выполните:

    • для конфигурации без pangolin-manager:

      sudo systemctl restart postgresql

    • Для конфигурации с pangolin-manager:

      sudo systemctl restart pangolin-manager

    • Для конфигурации с etcd:

      sudo systemctl restart etcd

  2. (master) Запустите сторонние сервисы:

    sudo systemctl restart crond

  3. (master) В случае конфигурации с pangolin-manager выведите pangolin-manager из режима паузы:

    sudo -iu postgres
/usr/patroni/patroni_venv/bin/patronictl -c /etc/patroni/postgres.yml remove clustername 
exit
sudo systemctl restart patroni #дополнительно выполнить на ноде replica
sudo -iu postgres
/usr/patroni/patroni_venv/bin/patronictl -c /etc/patroni/postgres.yml edit-config --set 'pause=false' --force
/usr/patroni/patroni_venv/bin/patronictl -c /etc/patroni/postgres.yml restart clustername
exit

Восстановление после неудачного обновления исполняемых файлов#

Внимание

Корректный откат к исходной версии Pangolin (6.1.0/6.1.2/6.1.4) при отсутствии резервной копии осуществить не получится (из-за изменения формата WAL-файлов), поэтому необходимо это учесть при попытке обновиться.

Перед началом выполнения инструкции убедитесь, что yum/dnf-репозитории настроены корректно. Откат СУБД осуществляется суперпользователем, пользователем postgres или пользователем kmadmin_pg.

Также для отката потребуется наличие резервного каталога, созданного скриптами во время обновления. Как пример, будет использоваться каталог /pgarclogs/backups/06.001.06/2024-10-23-T1213.

Откат необходимо производить только для тех компонентов, которые были обновлены на новую версию. Иначе, пропустить выполнение шага восстановления компонента.

Примечание

В разделе рассматривается процесс восстановления после неудачного обновления исполняемых файлов СУБД Pangolin с версий 6.1.x/6.2.x/6.3.x на 6.4.x.

В качестве примера указаны значения по умолчанию. При необходимости замените их на актуальные значения со стенда.

Поскольку инструкция является универсальной для standalone и cluster-архитектур, каждый пункт необходимо выполнить на узлах кластера БД.

На узле арбитре обновление компонентов производите только по необходимости (в случае конфигурации с DCS).

Шаг 1. Подготовка#

  1. Убедитесь, что все компоненты остановлены:

    sudo ps aux | grep -E "pangolin-pooler|postgres|etcd|patroni|pangolin-manager|pg_certs_rotate_agent|pangolin-certs-rotate|pangolin-auth-reencrypt@kmadmin_pg|pangolin-auth-reencrypt@postgres|pangolin_reencrypt@postgres|pangolin_reencrypt@kmadmin_pg" | grep -v grep

  2. Если команда вернула результат, то выполните:

    sudo kill -9 <pid>
#<pid> получить следующим образом:
sudo ps aux | grep -E "pangolin-pooler|postgres|etcd|patroni|pangolin-manager|pg_certs_rotate_agent|pangolin-certs-rotate|pangolin-auth-reencrypt@kmadmin_pg|pangolin-auth-reencrypt@postgres|pangolin_reencrypt@postgres|pangolin_reencrypt@kmadmin_pg" | grep -v grep

Шаг 2. Восстановление pangolin-auth-reencrypt (pangolin_reencrypt)#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.3.0:

    dnf remove pangolin-auth-reencrypt
rm -rf /etc/postgres/enc_util.cfg /etc/postgres/start_reencrypt.sh /etc/postgres/pg_auth_reencrypt /opt/pangolin-common/bin/pg_auth_reencrypt /etc/postgres/enc_params.cfg.kmadmin_pg /etc/postgres/enc_params.cfg.postgres /opt/pangolin-auth-reencrypt/ /etc/pangolin-auth-reencrypt/
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_auth_reencrypt/etc/postgres/enc_util.cfg /etc/postgres/enc_util.cfg
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_auth_reencrypt/opt/pangolin-common/bin/pg_auth_reencrypt /opt/pangolin-common/bin/pg_auth_reencrypt
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_auth_reencrypt/etc/postgres/enc_params.cfg.kmadmin_pg /etc/postgres/enc_params.cfg.kmadmin_pg
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_auth_reencrypt/etc/postgres/enc_params.cfg.postgres /etc/postgres/enc_params.cfg.postgres

  • для версий, начиная с 6.3.0:

    dnf remove pangolin-auth-reencrypt
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_certs_rotate/pangolin-auth-reencrypt-6.3.0-sberlinux8.8.x86_64.rpm
mv /etc/pangolin-auth-reencrypt/pangolin-auth-reencrypt.yml.rpmsave /etc/pangolin-auth-reencrypt/pangolin-auth-reencrypt.yml

Шаг 3. Восстановление pangolin-certs-rotate (pg_certs_rotate_agent)#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.3.0:

    dnf remove pangolin-certs-rotate
rm -rf /etc/systemd/system/pangolin-certs-rotate.service /etc/pangolin-certs-rotate /opt/pangolin-certs-rotate /opt/pangolin-common/bin/pg_certs_rotate_agent
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_certs_rotate/etc/postgres/pg_certs_rotate_agent.yml /etc/postgres/pg_certs_rotate_agent.yml
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_certs_rotate/etc/systemd/system/pg_certs_rotate_agent.service /etc/systemd/system/pg_certs_rotate_agent.service
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_certs_rotate/opt/pangolin-common/bin/pg_certs_rotate_agent /opt/pangolin-common/bin/pg_certs_rotate_agent

  • для версий, начиная с 6.3.0:

    dnf remove pangolin-certs-rotate
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_certs_rotate/pangolin-certs-rotate-6.3.0-sberlinux8.8.x86_64.rpm
mv /etc/pangolin-certs-rotate/pangolin-certs-rotate.yml.rpmsave /etc/pangolin-certs-rotate/pangolin-certs-rotate.yml

Шаг 4. Восстановление pangolin-security-utilities#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.3.0:

    dnf remove pangolin-security-utilities
cp -r /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_dbms/postgres /etc/

  • для версий, начиная с 6.3.0:

    dnf remove pangolin-security-utilities
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_security_utilities/pangolin-security-utilities-6.3.0-sberlinux8.8.x86_64.rpm

Шаг 5. Восстановление pangolin-diagnostic-tools (diagnostic_tool)#

Произведите восстановление исходных рабочих файлов/rpm-пакета компонента из каталога бэкапа:

  • для версий до 6.3.0:

    dnf remove pangolin-diagnostic-tool

  • для версий начиная с 6.3.0:

    dnf remove pangolin-diagnostic-tool
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_diagnostic_tool/pangolin-diagnostic-tool-6.3.0-sberlinux8.8.x86_64.rpm

Шаг 6. Восстановление pangolin-backup-tools (manager_backup)#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.1.3:

    dnf remove pangolin-backup-tools
rm -rf /opt/omni/lbin/ /etc/pangolin-backup-tools
cp -ra /pgarclogs/backups/06.001.02/2024-10-23-T1213/pangolin_backup_tools/06_manage_backup.sh /opt/omni/lbin/06_manage_backup.sh
cp -ra /pgarclogs/backups/06.001.02/2024-10-23-T1213/pangolin_backup_tools/06_pg_se_archlogs.sh /opt/omni/lbin/06_pg_se_archlogs.sh
cp -ra /pgarclogs/backups/06.001.02/2024-10-23-T1213/pangolin_backup_tools/06_manage_backup.bin /opt/omni/lbin/06_manage_backup.bin

  • для версий, начиная с 6.1.3:

    dnf remove pangolin-backup-tools
rm -rf /opt/omni/lbin/
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_backup_tools/pangolin-backup-tools-1.2.2-sberlinux8.8.x86_64.rpm

Шаг 7. Восстановление Pangolin Pooler#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.1.0:

    dnf remove pangolin-pooler
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/etc/pgbouncer/userlist.txt /etc/pgbouncer/userlist.txt
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/etc/systemd/system/pgbouncer.service /etc/systemd/system/pgbouncer.service
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/etc/logrotate.d/pgbouncer /etc/logrotate.d/pgbouncer
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/usr/local/bin/pgbouncer /usr/local/bin/pgbouncer
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/usr/local/share/doc /usr/local/share/
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/usr/local/share/man/man1/pgbouncer.1 /usr/local/share/man/man1/pgbouncer.1
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/usr/local/share/man/man5/pgbouncer.5 /usr/local/share/man/man5/
cp -ra /pgarclogs/backups/06.000.02/2024-10-23-T1213/pangolin_pooler/etc/pgbouncer/pgbouncer.ini /etc/pgbouncer/

  • для версий, начиная с 6.1.0:

    dnf remove pangolin-pooler
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_pooler/pangolin-pooler-1.3.1-sberlinux8.8.x86_64.rpm
cp -ra /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_pooler/etc/pangolin-pooler/userlist.txt /etc/pangolin-pooler/userlist.txt
cp -ra /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_pooler/etc/pangolin-pooler/pangolin-pooler.ini /etc/pangolin-pooler/pangolin-pooler.ini
cp -ra /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_pooler/opt/pangolin-pooler/bin/pangolin-pooler-restart.sh /opt/pangolin-pooler/bin/pangolin-pooler-restart.sh

Шаг 8. Восстановление Pangolin Manager#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.1.2:

    dnf remove pangolin-manager
rm -rf /opt/pangolin-manager/ /etc/pangolin-manager/ /usr/patroni/patroni_venv/
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1213/pangolin_manager/patroni_venv/ /usr/patroni/patroni_venv/
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1213/pangolin_manager/patroni.dynamic.json /pgdata/06/data/patroni.dynamic.json
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1213/pangolin_manager/etc/patroni/postgres.yml /etc/patroni/postgres.yml
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1400/pangolin_manager/etc/systemd/system/patroni.service /etc/systemd/system/patroni.service
ln -snf /usr/patroni/patroni_venv/lib /usr/patroni/patroni_venv/lib64

  • для версий, начиная с 6.1.2:

    dnf remove pangolin-manager
rm -rf /usr/patroni/patroni_venv/
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_manager/pangolin-manager-2.1.2-sberlinux8.8.x86_64.rpm
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1213/pangolin_manager/etc/pangolin-manager/postgres.yml /etc/pangolin-manager/postgres.yml
cp -ra /pgarclogs/backups/06.001.00/2024-10-23-T1213/pangolin_manager/patroni.dynamic.json /pgdata/06/data/patroni.dynamic.json

Шаг 9. Восстановление Pangolin DBMS#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.3.0:

    export PANGOLIN_OLD_VER=6.1.6
export PANGOLIN_NEW_VER=6.3
dnf remove pangolin-dbms platform-v-pangolin-dbms
rm -rf /usr/pangolin-$PANGOLIN_OLD_VER /usr/pangolin-$PANGOLIN_NEW_VER
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_dbms/pangolin-6.1.6 /usr
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_dbms/pgdata/06/data/{pg_hba.conf,postgresql.conf,pg_ident.conf,pg_quota.conf,postgresql.auto.conf,postgresql.base.conf,postgres.yml} /pgdata/06/data/
cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_dbms/etc/systemd/system/patroni.service /etc/systemd/system/patroni.service или cp -ra /pgarclogs/backups/06.001.06/2024-10-23-T1213/pangolin_dbms/etc/systemd/system/postgresql.service /etc/systemd/system/postgresql.service
ln -sfn /usr/pangolin-PANGOLIN_OLD_VER /usr/pangolin
ln -sfn /usr/pangolin-PANGOLIN_OLD_VER /usr/pangolin-6
ln -sfn /usr/pangolin-PANGOLIN_OLD_VER /opt/pangolin-dbms

  • для версий, начиная с 6.3.0:

    export PANGOLIN_OLD_VER=6.1.6
export PANGOLIN_NEW_VER=6.3
dnf remove pangolin-dbms platform-v-pangolin-dbms
rm -rf /usr/pangolin-$PANGOLIN_OLD_VER /usr/pangolin-$PANGOLIN_NEW_VER
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_dbms/pangolin-dbms-6.3-6.3.0-sberlinux8.8.x86_64.rpm

Шаг 10. Восстановление pangolin-dbms-client#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

  • для версий до 6.2.0:

    export PANGOLIN_OLD_VER=6.3
dnf remove pangolin-dbms-client
rm -rf /usr/pangolin-dbms-client /usr/pangolin-dbms-client-6 /usr/pangolin-dbms-client-$PANGOLIN_OLD_VER

  • для версий, начиная с 6.2.0:

    export PANGOLIN_OLD_VER=6.3
export PANGOLIN_NEW_VER=6.4
dnf remove pangolin-dbms-client
rm -rf /usr/pangolin-dbms-client-$PANGOLIN_OLD_VER /usr/pangolin-dbms-client-$PANGOLIN_NEW_VER
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_dbms/pangolin-dbms-6.3-client-6.3.0-sberlinux8.8.x86_64.rpm

Шаг 11. Восстановление pangolin-timescaledb (TimescaleDB)#

Восстановите исходные бинарные файлы/rpm пакета компонента из резервного каталога:

dnf remove pangolin-timescaledb

# установите пакет, если в исходной версии pangolin-timescaledb был в виде rpm-пакета
dnf install /pgarclogs/backups/06.003.00/2024-10-23-T1213/pangolin_timescaledb/pangolin-timescaledb-2.14.2-sberlinux8.8.x86_64.rpm

Шаг 12. Дополнительный действия#

Актуализируйте .bash_profile и dynmotd.sh:

export PANGOLIN_OLD_VER=6.1.6
export PANGOLIN_NEW_VER=6.4.0
export PANGOLIN_FULL_OLD_VER=06.001.06
export PANGOLIN_FULL_NEW_VER=06.004.00
export PANGOLIN_MANAGER_OLD_VER=1.2.0
export PANGOLIN_MANAGER_NEW_VER=1.2.1

sudo sed -i  "s/$PANGOLIN_NEW_VER/$PANGOLIN_OLD_VER/g" /home/postgres/.bash_profile
sudo sed -i  "s/$PANGOLIN_NEW_VER/$PANGOLIN_OLD_VER/g" /home/kmadmin_pg/.bash_profile
sudo sed -i  "s/$PANGOLIN_NEW_VER/$PANGOLIN_OLD_VER/g" /home/postgres/.bashrc
sudo sed -i  "s/$PANGOLIN_NEW_VER/$PANGOLIN_OLD_VER/g" /home/kmadmin_pg/.bashrc

# выполнить на всех нодах кластера
sudo sed -i  "s/$PANGOLIN_MANAGER_NEW_VER/$PANGOLIN_MANAGER_OLD_VER/g" /usr/local/sbin/dynmotd.sh
sudo sed -i  "s/$PANGOLIN_NEW_VER/$PANGOLIN_OLD_VER/g" /usr/local/sbin/dynmotd.sh
sudo sed -i  "s/$PANGOLIN_FULL_NEW_VER/$PANGOLIN_FULL_OLD_VER/g" /usr/local/sbin/dynmotd.sh

Шаг 13. Восстановление системного каталога#

Восстановите системный каталог согласно инструкции по ручному восстановлению системного каталога СУБД.

Шаг 14. Запуск компонентов СУБД Pangolin#

  1. Запустите компоненты Pangolin. В случае кластерной конфигурации, сначала выполните запуск на основном узле:

    • без функциональности «Отказ от root»:

      sudo systemctl daemon-reload
sudo systemctl restart user@$(id -u postgres)
sudo systemctl restart user@$(id -u kmadmin_pg)
   
# Для конфигурации без pangolin-manager
sudo systemctl restart postgresql
   
# Для конфигурации с pangolin-manager
sudo systemctl restart pangolin-manager
   
# Для конфигурации с etcd
sudo systemctl restart etcd
   
# Для любой конфигурации
sudo systemctl restart pangolin-pooler
sudo systemctl restart pangolin-certs-rotate
sudo systemctl restart pangolin-auth-reencrypt@postgres
sudo systemctl restart pangolin-auth-reencrypt@kmadmin_pg

    • с функциональностью «Отказ от root»:

       sudo systemctl restart user@$(id -u postgres)
 sudo systemctl restart user@$(id -u kmadmin_pg)

 # Для конфигурации с etcd
 sudo systemctl restart etcd

 sudo -iu postgres
 systemctl --user daemon-reload
 # Для конфигурации без pangolin-manager
 systemctl --user restart postgresql

 # Для конфигурации с pangolin-manager
 systemctl --user restart pangolin-manager

 # Для любой конфигурации
 systemctl --user restart pangolin-pooler
 systemctl --user restart pangolin-certs-rotate
 systemctl --user restart pangolin-auth-reencrypt
 exit
 sudo -iu kmadmin_pg
 systemctl --user daemon-reload  
 export XDG_RUNTIME_DIR=/run/user/$(id -u)
 export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
 systemctl --user restart pangolin-auth-reencrypt
 exit

  2. В случае конфигурации с Pangolin Manager выведите его из режима паузы:

    sudo -iu postgres
pangolin-manager-ctl -c /etc/pangolin-manager/postgres.yml edit-config --set 'pause=false' --force
exit

  3. Проверьте состояние служб:

    • без функциональности «Отказ от root»:

      # Для конфигурации без pangolin-manager
sudo systemctl status postgresql

# Для конфигурации с pangolin-manager
sudo systemctl status pangolin-manager

# Для конфигурации с etcd
sudo systemctl status etcd

# Для любой конфигурации
sudo systemctl status pangolin-pooler
sudo systemctl status pangolin-certs-rotate
sudo systemctl status pangolin-auth-reencrypt@postgres
sudo systemctl status pangolin-auth-reencrypt@kmadmin_pg

    • с функциональностью «Отказ от root»:

      # Для конфигурации с etcd
sudo systemctl status etcd

sudo -iu postgres
# Для конфигурации без pangolin-manager
systemctl --user status postgresql

# Для конфигурации с pangolin-manager
systemctl --user status pangolin-manager

# Для любой конфигурации
systemctl --user status pangolin-pooler
systemctl --user status pangolin-certs-rotate
systemctl --user status pangolin-auth-reencrypt
exit
sudo -iu kmadmin_pg
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
systemctl --user status pangolin-auth-reencrypt
exit

Ручное восстановление системного каталога СУБД#

При работе автоматического сценария обновления (или при обновлении в ручном режиме) может потребоваться ручное восстановление системного каталога. Способ восстановления зависит от ситуации.

При выявлении проблем в работе СУБД после успешного обновления и некоторого периода эксплуатации может возникнуть необходимость в корректировке системных данных каталога или откате их изменений, произведенных во время обновления.

Примечание

В случае кластерной конфигурации все действия по изменению системного каталога производятся только на основном узле, при этом репликация осуществляется во время синхронизации (разделы «Откат таблиц системного каталога СУБД» и «После восстановления не получилось снять дамп какой либо из баз данных СУБД»). Переименование директорий пользовательских табличных пространств, изменение версии системного каталога производится как на мастере, так и на реплике.

Восстановление стенда после неуспешного обновления#

Ошибка возникла до запуска утилиты inplace_upgrade.sh#

При возникновении ошибки до запуска утилиты inplace_upgrade.sh в случае, когда автоматический откат не выполнился, перейдите к инструкции отката.

Ошибка возникла при запуске утилиты inplace_upgrade.sh в режиме update, утилита вернула код 5#

При возникновении ошибки при запуске утилиты inplace_upgrade.sh до обновления системных каталогов, предусмотрено автоматическое восстановление версии системного каталога и пользовательских табличных пространств. Если автоматический откат не выполнился, перейдите к инструкции отката.

Ошибка возникла при запуске утилиты inplace_upgrade.sh в режиме update, утилита вернула код 4#

При возникновении ошибки при запуске утилиты inplace_upgrade.sh после начала обновления системных каталогов, предусмотрено автоматическое восстановление версии системного каталога и пользовательских табличных пространств. Если автоматический откат не выполнился, требуется откат бинарных файлов и настроек по инструкции отката. После отката бинарных файлов необходимо запустить утилиту inplace_upgrade.sh с командой reset:

./inplace_upgrade.sh -d <pgdata> -l <директория логов> -p <порт> -h <хост> -u <суперпользоватесь> -b <база данных для подключения по умолчанию> -s <директория с утилитой> -m <директория для sql-дампов> -B <директория бэкапа> reset -t <директория утилит postgres and pg_ctl> -T <директория утилит psql and pg_dump>

После получения кода возврата 0 откат считается успешным.

Ошибка при работе утилиты inplace_upgrade.sh в режиме update, утилита вернула код 1#

Завершение утилиты inplace_upgrade.sh с кодом 1 требует ручного восстановления. Ниже рассматриваются возможные ситуации.

Для отката бинарных файлов и настроек сценария обновления требуется обратиться к инструкции отката.

Неуспешное изменение версии системного каталога в файле global/pg_control, при обновлении#

Первое изменение, которое производит скрипт inplace_upgrade.sh, заключается в вызове утилиты update_catalog_version для обновления версии системного каталога. Перед обновлением файла global/pg_control утилита update_catalog_version формирует файл резервного копирования pg_control.bak в директории --backupdir. Утилита update_catalog_version вызывается также и при автоматическом восстановлении в случае неудачного обновления – при этом создается дополнительная резервная копия, которая помещается в директорию <--backupdir>/reset_pg_control/pg_control.bak.

Ниже рассматриваются возможные ситуации возникновения сбоя при работе утилиты update_catalog_version.

Ошибка обновления версии системного каталога утилитой update_catalog_version

Ошибка возникла во время работы утилиты update_catalog_version до момента начала обновления каталога. Данная ситуация сопровождается сообщением в логе:

update_catalog_version: error: Catalog version has not been updated, file <pgdata>/global/pg_control is corrupted

  1. Выполните команду:

    sudo cp <директория бэкапа>/pg_control.bak $PGDATA/global/pg_control

  2. После успешного завершения работы утилиты проверьте утилитой pg_controldata содержимое файла pg_control:

    pg_controldata -D $PGDATA

    Вывод:

    ...
Catalog version number:               <старая версия системного каталога>
...

Ошибка при повторном вызове утилиты update_catalog_version

Ошибка возникла во время работы утилиты update_catalog_version во время автоматического восстановления, инициированного утилитой inplace_upgrade.sh.

Данная ситуация сопровождается следующим сообщением в логе:

pg_ctl start: waiting for server to start.................... done server started
...
ERROR: ... # Ошибка во время работы inplace_upgrade.sh
...
INFO: renamed '/pgdata/06/tablespaces/Tbl_t/PG_15_<новая версия системного каталога>' -> '/pgdata/06/tablespaces/Tbl_t/PG_15_<старая версия системного каталога>'
...
ERROR: update_catalog_version: Catalog version has not been updated, file <pgdata>/global/pg_control is corrupted

Внимание

За время работы утилиты inplace_upgrade.sh может поменяться позиция LSN, это приведет к изменению текущего WAL-файла и файла pg_control. Поэтому в команде ниже работа производится именно с текущим pg_control, который был сохранен перед повторным вызовом утилиты.

  1. Выполните команду:

    sudo cp <директория бэкапа>/reset_pg_control/pg_control.bak $PGDATA/global/pg_control

  2. Проверьте права на доступ к файлу PostgreSQL. Запустите утилиту update_catalog_version:

    update_catalog_version -c <новая версия системного каталога> -C <старая версия системного каталога> -D $PGDATA -b <директория для бэкапа pg_control> -f

  3. После успешного завершения работы update_catalog_version проверьте утилитой pg_controldata содержимое файла pg_control:

    update_catalog_version
pg_controldata -D $PGDATA
update_catalog_version

    Вывод:

    ...
Catalog version number:               <старая версия системного каталога>
...
Ошибка восстановления имени папки пользовательского табличного пространства в соответствии со старой версией системного каталога#

Ошибка возникает во время автоматического восстановления, инициированного утилитой inplace_upgrade.sh при переименовании папки пользовательского табличного пространства.

Для восстановления пользовательских табличных пространств необходимо получить из файла <директория бэкапа>/user_tbls.txt все пользовательские табличные пространства, относящиеся к СУБД и произвести переименование содержащихся в них папок PG_<версия PostgreSQL>_<версия системного каталога> в соответствии с возвращаемой версией системного каталога.

Данная ситуация сопровождается следующим сообщением в логе:

ERROR: ... # Ошибка во время работы inplace_upgrade.sh
...
ERROR: mv: cannot move ...

  1. Выполните:

    sudo mv <пользовательский tablespace>/PG_15_202409231 <пользовательский tablespace>/PG_15_202310091

  2. Проверьте содержимое директории пользовательского табличного пространства командой ls:

    ls <директория пользовательского табличного пространства> -la
drwx------ 3 postgres postgres 4096 Oct 16 14:28 .
drwx------ 3 postgres postgres 4096 Oct 16 14:28 ..
drwx------ 3 postgres postgres 4096 Oct 16 14:28 PG_<версия PostgreSQL>_<старая версия системного каталога>
Ошибка обновления СУБД после успешного обновления утилитой inplace_upgrade.sh и возврата кода 0#

В случае проблемы в работе обновления СУБД после успешной отработки утилиты inplace_upgrade.sh необходимо произвести откат бинарных файлов к старой версии по инструкции отката и вернуть системный каталог в состояние, соответствующее старой версии СУБД. Для возвращения системного каталога в исходное состояние необходимо записать старую версию системного каталога в файл global/pg_control, переименовать папки в пользовательских табличных пространствах в соответствии со старой версией системного каталога и выполнить ручную корректировку данных системного каталога для отмены изменений, произошедших в нем во время обновления.

Откат версии системного каталога в файле global/pg_control#

  1. Запустите утилиту update_catalog_version:

    update_catalog_version -c <новая версия системного каталога> -C <старая версия системного каталога> -D $PGDATA -b <директория для бэкапа pg_control> -f

  2. После успешного завершения работы update_catalog_version проверьте утилитой pg_controldata содержимое файла pg_control на соответствие старой версии системного каталога.

Откат папок в пользовательских табличных пространствах СУБД#

Для восстановления пользовательских табличных пространств, получите из файла <директория бэкапа>/user_tbls.txt все пользовательские пространства, относящиеся к СУБД и переименуйте содержащиеся в них папки PG_<версия PostgreSQL>_<версия системного каталога> в соответствии с возвращаемой версией системного каталога.

Пример:

sudo mv <пользовательский tablespace>/PG_15_202409231 <пользовательский tablespace>/PG_15_202310091

Проверьте права на доступ к файлу PostgreSQL.

Откат таблиц системного каталога СУБД#

Для восстановления таблиц системного каталога:

  1. Проанализируйте SQL-скрипты обновления в папке installer/utilities/pg_inplace_upgrade/sql_upgrade_6xx/ для определения объектов, которые были добавлены или изменены при обновлении. Пример можно найти в разделе «После восстановления не получилось снять дамп какой-либо из баз данных СУБД», пункт 4, «Содержимое папки pg_inplace_upgrade/sql_upgrade_6xx».

  2. Проанализируйте файл <logdir>/inplace_upgrade.log для определения добавленных (измененных) объектов и их параметров.

    Пример содержимого лога, показывающий, какие объекты были созданы:

    2024-10-23 09:44:16.621 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.binary_upgrade_set_next_pg_proc_oid: "3814|binary_upgrade_set_next_pg_proc_oid|11|10|12|1|0|0|-|f|f|f|t|f|s|s|1|0|2278|26||||||binary_upgrade_set_next_pg_proc_oid||||"
2024-10-23 09:44:16.621 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 27 at RAISE
2024-10-23 09:44:16.622 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.binary_upgrade_set_next_namespace_oid: "3813|binary_upgrade_set_next_namespace_oid|11|10|12|1|0|0|-|f|f|f|t|f|s|s|1|0|2278|26||||||binary_upgrade_set_next_namespace_oid||||"
2024-10-23 09:44:16.622 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 47 at RAISE
2024-10-23 09:44:16.623 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.stop_recovery_event: "9306|stop_recovery_event|11|10|12|1|0|0|-|f|f|f|t|f|s|s|6|0|2278|""25 25 25 16 23 16""|""{25|25|25|16|23|16}""|""{i|i|i|i|i|i}""|""{action|dbname|dump_file|is_backup|time_in_min|result}""|||stop_recovery_event||||"
2024-10-23 09:44:16.623 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 68 at RAISE
2024-10-23 09:44:16.623 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.start_recovery_event: "9307|start_recovery_event|11|10|12|1|0|0|-|f|f|f|t|f|s|s|4|0|16|""25 25 25 16""|""{25|25|25|16}""|""{i|i|i|i}""|""{action|dbname|dump_file|is_backup}""|||start_recovery_event||||"
2024-10-23 09:44:16.623 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 90 at RAISE
2024-10-23 09:44:16.625 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.pg_integrity_add_file: "9308|pg_integrity_add_file|11|10|12|1|0|0|-|f|f|f|t|f|s|s|1|0|16|25|{25}|{i}|{file_check}|||IntegrityAddFiles||||{postgres=X/postgres}"
2024-10-23 09:44:16.625 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 113 at RAISE
2024-10-23 09:44:16.625 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.pg_integrity_add_catalog: "9309|pg_integrity_add_catalog|11|10|12|1|0|0|-|f|f|f|t|f|s|s|2|0|16|""25 25""|""{25|25}""|""{i|i}""|""{db_name|catalog_name}""|||IntegrityAddCatalog||||{postgres=X/postgres}"
2024-10-23 09:44:16.625 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 136 at RAISE
2024-10-23 09:44:16.626 MSK [2967393] [unknown] NOTICE:  CREATE FUNCTION pg_catalog.pg_integrity_check: "9310|pg_integrity_check|11|10|12|1|0|0|-|f|f|f|t|f|s|s|0|0|16|""""||||||IntegrityCheck||||{postgres=X/postgres}"
2024-10-23 09:44:16.626 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 156 at RAISE
2024-10-23 09:44:16.629 MSK [2967393] [unknown] NOTICE:  CREATE VIEW pg_catalog.pg_stat_progress_unite: "12001|pg_stat_progress_unite|11|12004|0|10|0|0|0|0|-1|0|0|f|f|p|v|6|0|t|f|f|f|f|t|n|f|0|0|0|||"
2024-10-23 09:44:16.629 MSK [2967393] [unknown] CONTEXT:  PL/pgSQL function inline_code_block line 187 at RAISE
backend> 2024-10-23 09:44:16.629 MSK [2967393] [unknown] NOTICE:  shutting down
2024-10-23 09:44:16.629 MSK [2967393] [unknown] LOG:  checkpoint starting: shutdown immediate
2024-10-23 09:44:16.630 MSK [2967393] [unknown] LOG:  checkpoint complete: wrote 44 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.001 s; sync files=0, longest=0.000 s, average=0.000 s; distance=215 kB, estimate=215 kB
2024-10-23 09:44:16.633 MSK [2967393] [unknown] NOTICE:  database system is shut down

  3. Проанализируйте файл <logdir>/postgres_updade.log для определения добавленных (измененных) объектов и их параметров.

  4. Проанализируйте (сравните) дампы системных каталогов СУБД до и после обновления и определите их отличия. Данный пункт выполняется если есть доступ к дампам (они не защищены политиками безопасности).

  5. Проанализируйте SQL-скрипты отката в папке installer/utilities/pg_inplace_upgrade/sql_upgrade_6xx/ для изучения скриптов отката добавленных объектов. Пример можно найти в разделе «После восстановления не получилось снять дамп какой-либо из баз данных СУБД», «Пример SQL-скрипта восстановления».

  6. На основе информации полученной в пунктах 1-5, определите, какие объекты были изменены или добавлены в результате обновления. Для всех объектов напишите SQL-скрипт отката (более подробно написание скриптов описано в разделе «После восстановления не получилось снять дамп какой-либо из баз данных СУБД»).

  7. Составьте общие SQL-скрипты по правилам, описанным в разделе «После восстановления не получилось снять дамп какой-либо из баз данных СУБД», «SQL-скрипт отката с rollback для проверки отсутствия ошибок написания», «SQL-скрипт отката без rollback для отката изменений».

  8. Для кластерной конфигурации создайте временной слот физической репликации для предотвращения удаления WAL-файлов, которые потребуются позднее для синхронизации реплики.

    psql -d postgres -qtAX -c "SELECT * FROM pg_create_physical_replication_slot('$slot_reset_name', 'TRUE');"

  9. Получите список всех баз данных:

    psql -d postgres -qtAX -c "SELECT datname FROM pg_database;"

  10. Остановите СУБД. Для кластера остановите процесс репликации, основной узел и реплику, дальнейшие действия выполняйте на основном узле.

  11. Запустите СУБД в режиме binary-mode:

    pg_ctl -D <директория pgdata> -l <файл для логов> -o -b start

  12. Для осуществления предварительной проверки скрипта выполните вариант скрипта с ROLLBACK в конце. Выполните скрипт во всех базах данных, требующих корректировки. Для получения доступа к базе template0 необходимо выставить в таблице pg_database параметр datallowconn = TRUE. Без этого доступ к базе template0 будет запрещен.

    Пример:

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
psql -d template0 -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"
psql -d template1 -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d postgres -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d $user_db -qtAX -c "<sql-скрипт с ROLLBACK>"
...

    Если во время проверки скриптов не возникло ошибок, то выполните вариант скрипта без ROLLBACK.

    Затем выполните скрипт во всех базах данных, требующих корректировки.

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
psql -d template0 -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"
psql -d template1 -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d postgres -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d $user_db -qtAX -c "<sql-скрипт без ROLLBACK>"
...

    Если в результате применения скриптов не возникло ошибок, то остановите СУБД и перейдите к следующему пункту. Если в результате выполнения скриптов возникли ошибки, то повторите пункты 1-12.

  13. После успешного выполнения скрипта во всех базах данных остановите СУБД:

    pg_ctl -D <директория pgdata> stop

  14. Запустите СУБД в обычном режиме:

    pg_ctl -D <директория pgdata> -l <файл для логов> start

  15. Снимите дампы системных каталогов во всех базах данных для проверки их консистентности. Пример:

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
pg_dump -d template0 -n pg_catalog --exclude-table pr_* 1> dump_template0.sql 2> dump_template0.err
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"
pg_dump -d template1 -n pg_catalog --exclude-table pr_* 1> dump_template1.sql 2> dump_template1.err
pg_dump -d postgres -n pg_catalog --exclude-table pr_* 1> dump_postgres.sql 2> dump_postgres.err
...

    Если все дампы снялись без ошибок, то восстановление считается успешным. Если нет, то вернитесь к пунктам 1-13.

  16. Остановите СУБД:

    pg_ctl -D <директория pgdata> stop

  17. Для standalone-конфигурации откат считается завершенным. Для кластерной конфигурации требуется запуск реплики и синхронизация ее с мастером посредством репликации.

  18. После успешной синхронизации реплики с основным узлом удалите временный слот репликации:

    Внимание

    Если временный слот физической репликации будет удален до окончания успешной синхронизации, могут быть потеряны актуальные WAL-файлы. Синхронизация реплики в этом случае будет невозможна.

    SELECT * FROM pg_drop_replication_slot('tmp_update_slot');

Восстановление стенда после неуспешного отката#

Ошибка при работе inplace_upgrade.sh в режиме reset, вернула код 1#

Режим reset является этапом автоматического отката системного каталога к исходному состоянию, остальные действия ручного восстановления описаны в инструкции отката. Во время этого этапа выполняется восстановление объектов:

  • файла pg_control;

  • WAL-файла, соответствующему восстановленному файлу pg_control;

  • папки pg_slots;

  • файлов папки global, относящихся к системному каталогу;

  • файлов папки base, относящихся к системному каталогу;

  • файлов, находящихся в папках пользовательских табличных пространств и относящихся к системному каталогу;

  • исходной структуры системного каталога (PGDATA).

Ниже приведены гипотетически возможные ошибки в результате работы скрипта inplace_upgrade.sh в режиме reset.

Невозможно восстановить какой-либо из файлов СУБД (в папках pg_wal, global, base и т.д.)#

Для решения проанализируйте <logdir>/inplace_upgrade.log и определите место возникновение ошибки. После чего скопируйте все файлы из директорий, указанных в файле <директория бэкапа>/backup_db/backup_db.txt в директории назначения СУБД.

Восстановление файлов СУБД

В данном разделе рассмотрен пример воссатновления файлов СУБД:

  1. Выполните команды:

    sudo cp -rf <директория бэкапа>/backup_db/pg_wal/ pgdata/06/data/
sudo cp -rf <директория бэкапа>/backup_db/pg_slots/ pgdata/06/data/
sudo cp -rf <директория бэкапа>/backup_db/base/ pgdata/06/data/
sudo cp -rf <директория бэкапа>/backup_db/global/ pgdata/06/data/
sudo cp -rf <директория бэкапа>/backup_db/user_tbsps <директория пользовательского табличного пространства>/
...

  2. Запустите СУБД со старыми бинарными файлами (откат к ним описан в инструкции отката):

    pg_ctl start

  3. Снимите SQL-дамп системных каталогов во всех базах данных. Пример снятия дампа:

    # Для возможности снятия sql-дампа с базы данных template0 необходимо установить параметр datallowconn в значение TRUE
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
pg_dump -d template0 -n pg_catalog --exclude-table pr_* 1> dump_template0.sql 2> dump_template0.err
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"

pg_dump -d template1 -n pg_catalog --exclude-table pr_* 1> dump_template1.sql 2> dump_template1.err
pg_dump -d postgres -n pg_catalog --exclude-table pr_* 1> dump_postgres.sql 2> dump_postgres.err
...

    В случае успешного снятия дампов откат считается успешным.

После восстановления не получилось снять дамп какой-либо из баз данных СУБД#

Если возникла проблема снятия дампа системного каталога на какой-либо из баз данных после автоматического восстановления, то выполните действия:

  1. Проанализируйте файл <logdir>/inplace_upgrade.log для определения первоначального места ошибки при обновлении.

  2. Проанализируйте файл <logdir>/postgres_updade.log для определения проблемы в СУБД (если она есть).

  3. Сравните дампы системных каталогов СУБД до обновления, после обновления, а также после отката. Необходимо определить их отличия. Данный пункт выполняется если есть доступ к дампам. Рекомендуется использовать команду diff для сравнения SQL-дампов.

  4. На основе информации, полученной в пунктах 1-3, определите, какие объекты были повреждены или неправильно добавлены. Для всех поврежденных объектов напишите SQL-скрипт отката.

    Примечание

    SQL-скрипты восстановления пишутся в соответствии с правилами написания SQL-скриптов для обновления системных данных каталога.

    В директории installer/utilities/pg_inplace_upgrade/sql_upgrade_6xx/ есть папки, соответствующие версиям Pangolin (например 616). В них присутствуют директории reset_sql/, в которых содержатся примеры скриптов отката. В папках binary_upgrade_sql/ и upgrade_sql/ содержатся скрипты обновления, с помощью которых ранее была произведена неудачная попытка обновления.

    Содержимое папки pg_inplace_upgrade/sql_upgrade_6xx:

    +sql_upgrade_6xx
|+6.1.0
||CATALOG_VERSION
|+6.1.1
||CATALOG_VERSION
|+6.1.2
||CATALOG_VERSION
|+6.1.3
||CATALOG_VERSION
|+reset_sql
|+binary_upgrade_sql
|+upgrade_sql
|+6.1.4
||CATALOG_VERSION
|+6.1.5
||CATALOG_VERSION
|+6.1.6
||CATALOG_VERSION
|+reset_sql
|+upgrade_sql
|+6.1.7
||CATALOG_VERSION
|+6.1.8
||CATALOG_VERSION
|+6.1.9
||CATALOG_VERSION
|+6.2.0
||CATALOG_VERSION
|+reset_sql
|+upgrade_sql
|+6.3.0
||CATALOG_VERSION
|+reset_sql
|+upgrade_sql
|+6.4.0
||CATALOG_VERSION  
|+reset_sql
|+binary_upgrade_sql

    Например, если обновление с 6.1.6 на 6.4.0, то необходимо проанализировать скрипты обновления и отката для версий 6.2.0, 6.3.0, 6.4.0. В соответствии с результатами анализа, полученными во всех предыдущих пунктах, нужно написать скрипты отката, которые необходимы для восстановления системных каталогов. Возможно потребуется использование уже готовых скриптов от разработчиков в папках reset_sql (может потребоваться корректировка).

    Пример SQL-скрипта восстановления:

    -- Проверка наличия представления в системном каталоге
-- Если его нет, то скрипт написан неверно
IF EXISTS (SELECT 1 FROM pg_catalog.pg_class WHERE
proname = 'my_view') THEN
-- Печать текущего состояния pg_class до удаления представления
SELECT rtrim(ltrim(replace(pg_class::text, ',', '|'), '('), ')') INTO msg FROM pg_catalog.pg_class WHERE relname = 'my_view';
RAISE NOTICE 'CREATE VIEW pg_catalog.my_view: %', quote_ident(msg);

       DROP VIEW pg_catalog.my_view;
ELSE
RAISE EXCEPTION 'The "my_view" view is already missing, there may be a product version error.';
END IF;

-- Проверка отсутствия объекта в системном каталоге
IF EXISTS (SELECT 1 FROM pg_catalog.pg_class WHERE relname = 'my_view') THEN
RAISE EXCEPTION 'Not found my_view';
END IF;

SET allow_system_table_mods = false;

    Отдельные SQL-скрипты отката встраиваются в общие SQL-скрипты отката. SQL-скрипт отката с ROLLBACK для проверки отсутствия ошибок написания:

    do $$
DECLARE
msg TEXT;
BEGIN
-- Включение возможности изменения системных таблиц
SET allow_system_table_mods = true;
SET LOCAL search_path TO pg_catalog;

    -- sql-cкрипты восстановления
     
    SET allow_system_table_mods = false;
    ROLLBACK;
END
$$;

    SQL-скрипт отката без ROLLBACK для отката изменений:

    do $$
DECLARE
msg TEXT;
BEGIN
-- Включение возможности изменения системных таблиц
SET allow_system_table_mods = true;
SET LOCAL search_path TO pg_catalog;

    -- sql-cкрипты восстановления
 
    SET allow_system_table_mods = false;
END
$$;

    SQL-скрипт c последующим ROLLBACK необходим для проверки наличия ошибок в SQL-скриптах.

    SQL-скрипт без ROLLBACK необходим для восстановления системных каталогов, после того как была проведена проверка SQL-скриптом с ROLLBACK.

  5. После составления скрипта восстановления системного каталога запустите СУБД в режиме binary-mode:

    pg_ctl -D <директория pgdata> -l <файл для логов> -o -b start

  6. Посредством psql запишите скрипт во все поврежденные базы данных (предварительно с ROLLBACK). Пример:

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
psql -d template0 -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"

psql -d template1 -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d postgres -qtAX -c "<sql-скрипт с ROLLBACK>"
psql -d $user_db -qtAX -c "<sql-скрипт с ROLLBACK>"
...

    Если в результате применения скриптов не возникло ошибок, то запустите скрипты для всех баз данных без ROLLBACK:

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
psql -d template0 -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"

psql -d template1 -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d postgres -qtAX -c "<sql-скрипт без ROLLBACK>"
psql -d $user_db -qtAX -c "<sql-скрипт без ROLLBACK>"
...

    Если в результате применения скриптов не возникло ошибок, то остановите СУБД и перейдите к следующему пункту. Если в результате выполнения скриптов возникли ошибки, то повторите пункты 1-6.

  7. После успешной записи всех скриптов остановите СУБД:

    pg_ctl -D <директория pgdata> stop

  8. Запустите СУБД в обычном режиме:

    pg_ctl -D <директория pgdata> -l <файл для логов> start

  9. Снимите дампы системных каталогов со всех поврежденных баз данных для проверки их консистентности. Пример снятия дампа:

    psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = TRUE WHERE datname = 'template0';"
pg_dump -d template0 -n pg_catalog --exclude-table pr_* 1> dump_template0.sql 2> dump_template0.err
psql -d postgres -qtAX -c "UPDATE pg_database SET datallowconn = FALSE WHERE datname = 'template0';"
pg_dump -d template1 -n pg_catalog --exclude-table pr_* 1> dump_template1.sql 2> dump_template1.err
pg_dump -d postgres -n pg_catalog --exclude-table pr_* 1> dump_postgres.sql 2> dump_postgres.err
...

    Если все дампы снялись успешно, то восстановление считается успешным. Если нет, то вернитесь к пунктам 1-7.

  10. Остановите СУБД:

    pg_ctl -D <директория pgdata> stop
Ошибка после работы inplace_upgrade.sh в режиме «reset», вернула код 0#

Проблема возникла в сценарии отката обновления после успешного выполнения inplace_upgrade.sh в режиме reset. Обратитесь к инструкции отката.

Корректировка данных системного каталога СУБД в случае обнаружения проблем на этапе эксплуатации#

В случае возникновения проблем в работе СУБД, связанных с прошедшим обновлением, приведите состояние объектов системного каталога к виду, обеспечивающему нормальное функционирование СУБД в новой версии.

Рекомендуется выполнить действия:

  1. Выполните анализ логов СУБД, определите, с какими объектами системного каталога связаны проблемы в работе.

  2. Проанализируйте SQL-скрипты обновления в папке installer/utilities/pg_inplace_upgrade/sql_upgrade_6xx/, с помощью которых выполнялось обновление СУБД (более подробно описано в разделе «После восстановления не получилось снять дамп какой-либо из баз данных СУБД», п. 4).

  3. Проанализируйте логи обновления inplace_upgrade.sh (<logdir>/inplace_upgrade.log, <logdir>/postgres_updade.log) для определения состояния обновленных объектов до и после обновления.

  4. На основе пунктов 1-3 составьте SQL-скрипты корректировки обновления в соответствии с правилами написания SQL-скриптов для обновления системных данных каталога и далее действуйте в соответствии с разделом «После восстановления не получилось снять дамп какой-либо из баз данных СУБД», п. 6-9.