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

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

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

Важно

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

Не запускайте компонент раньше, чем восстановлена его база данных. Если пустой сервис будет запущен до восстановления, он сгенерирует новый service_id, который не совпадет с service_id, зарегистрированным в Platform Gateway из дампа. В результате появится ошибка 401 Unauthorized с сообщением Token issuer ... does not exist. Базы данных сервисов и база данных Platform Gateway должны восстанавливаться из одного миграционного артефакта ВМ, чтобы их service_id совпадали.

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

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

Шаги этого раздела выполняются на узле кластера Kubernetes, куда скопирован артефакт, а все последующие разделы – на установочном узле, где доступна утилита kubectl. Поэтому раздел открывается подключением к узлу кластера и завершается возвратом.

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

  1. Подключитесь к узлу кластера, на который скопирован артефакт:

    ssh [-i <ssh_key>] <ssh_user>@<cluster_node_ip>

    Здесь <cluster_node_ip> – IP-адрес узла кластера Kubernetes, на который скопирован артефакт.

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

    cd /tmp

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

    sha256sum --check artifact.tar.gz.sha256

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

    tar xzf artifact.tar.gz

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

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

  6. Завершите сеанс на узле кластера и вернитесь на установочный узел:

    exit

Примечание

Артефакт распаковывается в каталог /tmp/migration-export/, так как именно так называется каталог внутри архива. Далее временный под монтирует этот каталог с выбранного узла кластера Kubernetes через hostPath.

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

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

Команды этого и последующих разделов выполняйте на установочном узле, где доступна утилита kubectl.

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

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

  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-*).

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

Примечание

Временный под используется и при восстановлении во внешнюю СУБД. В командах восстановления для внешней PostgreSQL указывайте аргументы -h <address> и -p <port> внешнего сервера.

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

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

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

    Здесь:

    • <version> – версия Astra Automation, например 2.1;

    • <node_name> – название узла кластера Kubernetes, на который скопирован и распакован миграционный артефакт. Чтобы посмотреть названия узлов, выполните команду kubectl get nodes.

  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.

    Если PostgreSQL развернута средствами Astra Automation, пароль администратора хранится в секрете шлюза:

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

    Если используется внешняя PostgreSQL, пароль администратора не хранится в секрете Kubernetes. Используйте пароль администратора внешнего сервера PostgreSQL.

Подготовка файла с паролем#

Внешний сервер PostgreSQL требует пароль для любого подключения по TCP. Внутренняя СУБД, развернутая средствами платформы, ведет себя по-разному в зависимости от образа: postgresql:2.1 и более поздние требуют пароль так же, как внешний сервер, а более ранние принимают подключение по TCP без пароля от любой роли. Беспарольный доступ по локальному сокету внутри пода PostgreSQL сохранен в обоих случаях.

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

В интерактивном режиме psql и pg_restore запрашивают пароль сами. Часть команд процедуры миграции неинтерактивна, поэтому ввести пароль по запросу нельзя, а передавать его аргументом команды недопустимо – значение попадет в журнал аудита API-сервера Kubernetes. Для таких команд пароль передается файлом .pgpass внутри временного пода.

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

  1. На установочном узле создайте файл с паролем администратора в формате pgpass. Пароль вводите по запросу, без отображения на экране, чтобы его значение не попало в историю команд оболочки:

    umask 077
read -rsp 'Пароль администратора PostgreSQL: ' pgpw && echo
pgpw_esc=${pgpw//\\/\\\\}
pgpw_esc=${pgpw_esc//:/\\:}
printf '%s:%s:%s:%s:%s\n' '*' '*' '*' postgres "$pgpw_esc" > pgpass
unset pgpw pgpw_esc

    Команда umask 077 задает режим доступа 0600 для создаваемого файла, поэтому он недоступен другим пользователям узла.

    Символ * в полях узла, порта и базы данных делает запись применимой к любому серверу PostgreSQL. Благодаря этому один и тот же файл подходит и для внутренней СУБД (aa-demo-postgres-15), и для внешнего сервера.

    В формате pgpass символы : и \ внутри поля экранируются обратной косой чертой, поэтому пароль записывается в файл в экранированном виде. Без этого пароль с двоеточием разорвал бы строку на лишние поля, и аутентификация завершилась бы отказом. Обратные косые черты экранируются первыми, иначе добавленное экранирование двоеточий было бы экранировано повторно.

  2. Передайте файл во временный под и ограничьте доступ к нему:

    kubectl exec -i -n astra-automation postgres-restore-temp -- \
  sh -c 'cat > /tmp/.pgpass && chmod 600 /tmp/.pgpass' < pgpass

    Примечание

    Файл размещается в каталоге /tmp/, а не в домашнем каталоге пользователя root: под может быть запущен от имени непривилегированного пользователя, и запись в /root/ в этом случае завершится ошибкой Permission denied.

  3. Удалите локальную копию файла:

    rm -f pgpass

Путь к файлу передается командам в переменной окружения PGPASSFILE. Указывайте переменную перед командой, а не после нее: иначе psql или pg_restore получит env в качестве аргумента.

Важно

После завершения миграции удалите файл с паролем из временного пода:

kubectl exec -n astra-automation postgres-restore-temp -- rm -f /tmp/.pgpass

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

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

Важно

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

  • Восстановление выполняется без использования флага --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'

      Примечание

      Подключение из временного пода выполняется по TCP, поэтому psql запросит пароль администратора, если СУБД требует его для таких подключений. Так ведет себя внешний сервер, а из внутренних – образ postgresql:2.1 и более поздние. Используйте пароль, полученный ранее.

      Образы внутренней СУБД до postgresql:2.1 принимают подключение по TCP без пароля от любой роли, поэтому запроса пароля не будет. Ход миграции это не меняет, но беспарольный доступ по сети остается открытым и после нее. Если пароль не запрошен, экземпляр уязвим, поэтому закройте беспарольный доступ по инструкции по закрытию беспарольного доступа к PostgreSQL.

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

  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'

Примечание

В приведенных примерах используется внутренняя PostgreSQL, развернутая в Kubernetes. При восстановлении во внешнюю СУБД укажите параметры подключения к внешнему экземпляру PostgreSQL:

  • -h – IP-адрес или FQDN сервера PostgreSQL;

  • -p – порт PostgreSQL.

Пример для интерактивного режима внутри временного пода:

pg_restore --clean --create \
  -h postgres.example.local \
  -p 5432 \
  -U postgres \
  -d template1 \
  controller/controller.pgc

В этом случае pg_restore запросит пароль администратора PostgreSQL.

Пример для неинтерактивного запуска через kubectl exec -i. Пароль администратора передавайте не через аргументы команды, а через файл .pgpass внутри временного пода:

kubectl exec -i -n astra-automation postgres-restore-temp -- \
  env PGPASSFILE=/tmp/.pgpass \
  pg_restore --clean --create \
  -h postgres.example.local \
  -p 5432 \
  -U postgres \
  -d template1 \
  /artifact/controller/controller.pgc

При восстановлении в управляемую PostgreSQL, например в облачную СУБД, в выводе pg_restore могут появляться ошибки о том, что роли исходного кластера не существуют, например роль "mdb_*" не существует или роль "monitor" не существует. Такие ошибки относятся к командам GRANT и REVOKE из исходного кластера и не являются критичными, если основные таблицы восстановлены успешно.

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

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

  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+'