Восстановление баз данных

Восстановление баз данных#

На этом шаге дампы из миграционного архива заменяют содержимое баз данных целевой платформы. Выполняйте команды на узле целевой платформы от имени учетной записи, указанной в переменной ansible_user. Службы контейнерной модели работают от имени этой учетной записи, поэтому sudo для команд systemctl --user и podman не требуется.

Сверка описания миграции#

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

Прочитайте описание миграции и сверьте узел:

cd ~/migration-export
cat manifest.yml

MANIFEST_TARGET=$(sed -n 's/^target_node:[[:space:]]*//p' manifest.yml)
if [ "$MANIFEST_TARGET" = "$(hostname -f)" ]; then
  echo "OK: архив создан для этого узла"
else
  echo "STOP: архив создан для узла $MANIFEST_TARGET, а команда выполняется на $(hostname -f)"
fi

Сверьте также следующие значения описания миграции:

  • platform_version – совпадает с версией целевой платформы, которую развернула утилита развертывания;

  • source_nodes – перечисляет узлы той платформы, с которой снимали дампы;

  • target_node – называет текущий узел, в том числе когда описание инвентаря задает узел IP-адресом, а не доменным именем: тогда проверка выше сообщает STOP, и узел сверяют вручную.

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

Остановка компонентов целевой платформы#

Остановите контейнеры компонентов, кроме контейнера PostgreSQL:

systemctl --user stop 'automation-*' receptor 'redis-*'

Восстановление дампов#

Для восстановления дампов выполните следующие действия:

  1. Скопируйте дампы в контейнер PostgreSQL:

    podman exec postgresql rm -rf /tmp/migration-db
podman cp ~/migration-export/db postgresql:/tmp/migration-db

  2. Создайте заново базы данных и восстановите в них дампы:

    podman exec -i postgresql bash <<'EOF'
set -euo pipefail
cd /tmp/migration-db

for db in automationgateway awx automationhub automationedacontroller; do
  owner="$db"

  # Исключение записей мандатных меток, которых нет в PostgreSQL целевой платформы
  pg_restore -l "$db.pgc" | grep -Ev ' MAC (LABEL|CCR) ' > "$db.list"

  psql -U postgres -v ON_ERROR_STOP=1 \
    -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = '$db' AND pid <> pg_backend_pid();" \
    -c "DROP DATABASE IF EXISTS $db;" \
    -c "CREATE DATABASE $db OWNER $owner;"

  pg_restore -U postgres -d "$db" --no-owner --role="$owner" -L "$db.list" "$db.pgc"
done
EOF

    Команда pg_restore восстанавливает объекты от имени владельца базы, поэтому дополнительные привилегии на объекты выдавать не требуется.

  3. Удалите временную копию дампов из контейнера:

    podman exec postgresql rm -rf /tmp/migration-db

Очистка маршрутов шлюза#

Восстановленная база Platform Gateway содержит маршруты и узлы служб исходной платформы. Удалите эти записи, чтобы при повторном развертывании утилита создала их заново с адресом целевого узла:

podman exec -i postgresql psql -U postgres -d automationgateway -v ON_ERROR_STOP=1 <<'EOF'
DELETE FROM aap_gateway_api_additionalroute;
DELETE FROM aap_gateway_api_servicenode;
DELETE FROM aap_gateway_api_serviceapiroute;
DELETE FROM aap_gateway_api_route;
DELETE FROM aap_gateway_api_httpport WHERE is_api_port = true;
EOF

Ожидаемый результат – пять строк DELETE с количеством удаленных записей.