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

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

На этом этапе выполняется восстановление данных платформы из копий, созданных в окружении ВМ, в PostgreSQL, развернутую в Kubernetes.

Внимание

Восстановление выполняется после остановки всех компонентов платформы и до их повторного запуска.

Подготовка артефакта#

Для восстановления используйте артефакт artifact.tar.gz и его контрольную сумму artifact.tar.gz.sha256, созданные и скопированные на установочный узел ранее.

Подготовьте артефакт для восстановления:

  1. Проверьте контрольную сумму архива:

    sha256sum --check artifact.tar.gz.sha256

  2. Скопируйте архив в рабочий каталог установочного узла:

    minikube cp artifact.tar.gz tmp/

  3. Распакуйте артефакт:

    cd /tmp && tar xzf artifact.tar.gz

  4. Проверьте контрольные суммы копий:

    cd tmp/migration-export && sha256sum --check sha256sum.txt

Примечание

Артефакт распаковывается в каталог tmp/migration-export/, так как именно так называется каталог внутри архива.

Остановка компонентов для миграции#

После завершения развертывания необходимо остановить все компоненты платформы для безопасного восстановления дампов баз данных. Работающим должен остаться только PostgreSQL.

Остановка операторов#

Остановите операторы в следующем порядке:

  1. Остановите aa-operator:

    kubectl scale deployment -n astra-automation \
  aa-operator-aa-manager --replicas=0

  2. Остановите остальные операторы:

    kubectl scale deployment -n astra-automation \
  ac-operator-ac-manager \
  eda-operator-eda-manager \
  pah-operator-pah-manager \
  --replicas=0

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

Остановите все компоненты платформы в следующем порядке:

  1. Остановите все прикладные компоненты:

    kubectl scale deployment -n astra-automation --replicas=0 \
  aa-demo-gateway \
  ac-demo-task \
  ac-demo-web \
  eda-demo-activation-worker \
  eda-demo-api \
  eda-demo-default-worker \
  eda-demo-event-stream \
  eda-demo-scheduler \
  pah-demo-api \
  pah-demo-content \
  pah-demo-redis \
  pah-demo-web \
  pah-demo-worker

  2. Проверьте статус подов:

    kubectl get pods -n astra-automation

    Ожидаемый результат:

    • Все поды компонентов платформы находятся в состоянии Terminated или Scaled down.

    • В рабочем состоянии остается только под PostgreSQL (aa-demo-postgres-15-*).

Создание временного пода для восстановления#

Примечание

Этот шаг необходим только при использовании внутренней СУБД, созданной в Kubernetes

Для выполнения восстановления следует создать временный под с клиентом PostgreSQL и доступом к файловой системе с копиями баз данных:

  1. Создайте временный под:

    kubectl run postgres-restore-temp \
--image=registry.astra.ru/aa/postgresql:2.0-preview \
--restart=Never \
-n astra-automation \
--overrides='
{
   "spec": {
      "containers": [{
         "name": "postgres-restore-temp",
         "image": "registry.astra.ru/aa/postgresql:2.0-preview",
         "command": ["sleep", "infinity"],
         "volumeMounts": [{
            "name": "artifact",
            "mountPath": "/artifact"
         }]
      }],
      "volumes": [{
         "name": "artifact",
         "hostPath": {
            "path": "/tmp/migration-export",
            "type": "Directory"
         }
      }]
   }
}' -- sleep infinity

  2. Проверьте, что под создан и активен:

    kubectl get pod postgres-restore-temp -n astra-automation

Получение параметров подключения к PostgreSQL#

Определите параметры подключения к PostgreSQL:

  1. Получите имя сервиса PostgreSQL:

    kubectl get svc -n astra-automation | grep postgres

    Обычно используется сервис aa-demo-postgres-15.

  2. Получите пароль администратора PostgreSQL:

    kubectl get secret aa-demo-gateway-postgres-configuration -n astra-automation \
  -o jsonpath='{.data.postgres_admin_password}' | base64 -d
echo ""

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

Важно

Примите во внимание следующие особенности:

  • Восстановление выполняется без использования флага --no-owner.

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

  1. Войдите во временный под:

    kubectl exec -it postgres-restore-temp -n astra-automation -- bash

  2. Внутри временного пода выполните следующие действия:

    • Перейдите в каталог с артефактом:

      cd /artifact/

    • Проверьте подключение к PostgreSQL:

      psql -h aa-demo-postgres-15 -U postgres -d template1 -c '\l'

      Примечание

      PostgreSQL может не запрашивать пароль, так как под работает внутри Kubernetes и использует доверенную аутентификацию. Это нормальное поведение.

Восстановление баз данных выполняйте в следующем порядке:

  1. Automation Controller:

    pg_restore --clean --create \
  -h aa-demo-postgres-15 -U postgres \
  -d template1 \
  controller/controller.pgc

    Проверка:

    psql -h aa-demo-postgres-15 -U postgres -d awx -c '\dt'

  2. Private Automation Hub:

    pg_restore --clean --create \
  -h aa-demo-postgres-15 -U postgres \
  -d template1 \
  hub/hub.pgc

    Проверка:

    psql -h aa-demo-postgres-15 -U postgres -d automationhub -c '\dt'

  3. Platform Gateway:

    pg_restore --clean --create \
  -h aa-demo-postgres-15 -U postgres \
  -d template1 \
  gateway/gateway.pgc

    Проверка:

    psql -h aa-demo-postgres-15 -U postgres -d automationgateway -c '\dt'

  4. Event-Driven Automation:

    pg_restore --clean --create \
  -h aa-demo-postgres-15 -U postgres \
  -d template1 \
  eda/eda.pgc

    Проверка:

    psql -h aa-demo-postgres-15 -U postgres -d automationedacontroller -c '\dt'

Проверка восстановленных баз данных#

Проверьте, что все базы данных были успешно восстановлены:

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

    psql -h aa-demo-postgres-15 -U postgres -c '\l'

    Ожидаемые базы данных:

    • awx;

    • automationhub;

    • automationgateway;

    • automationedacontroller.

  2. Проверьте их объем:

    psql -h aa-demo-postgres-15 -U postgres -c '\l+'