Обновление базы данных PostgreSQL

Развернуть всё | Свернуть всё

В Kaspersky Container Security вы можете реализовать полуавтоматический процесс обновления базы данных PostgreSQL с версии 15 до версии 18 с помощью механизма логической репликации.

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

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

Этот способ обновления не является обязательным и предоставляется как инструмент для упрощенного и контролируемого перехода на новую версию PostgreSQL в составе Kaspersky Container Security. Решение о применении механизма логической репликации принимается командой эксплуатации. Процесс обновления предполагает параллельную работу старой и новой баз данных PostgreSQL до момента завершения синхронизации и выполненного вручную подтверждения перехода.

Обновление базы данных PostgreSQL состоит из следующих этапов:

1. Подготовка к обновлению базы данных

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

   1. Подготовка условий для обновления

      Необходимо обеспечить следующие условия для обновления:

      • Установлено решение версии 2.1.0 или более новая версия Kaspersky Container Security с PostgreSQL 15.
      • Kaspersky Container Security функционирует нормально.
      • Места для хранилища ресурсов в кластере Kubernetes достаточно для запуска еще одного экземпляра базы данных, по потреблению ресурсов идентичного существующему.
      • Места для хранилища и ресурсов в ĸластере Kubernetes достаточно для переноса нежурналируемых таблиц. По умолчанию на перенос заложен объект PVC размером 10 Gi (в большинстве случаев этого достаточно). Вы можете проверить общий размер нежурналируемых таблиц с помощью следующего сĸрипта:

        -- Size of unlogged tables

        SELECT

        ROUND(SUM(pg_total_relation_size(quote_ident(t.table_name))) / 1024, 2) AS "TotalKB"

        FROM

        information_schema.tables AS t

        LEFT OUTER JOIN pg_catalog.pg_class AS pgc

        ON t.table_name = pgc.relname

        LEFT OUTER JOIN pg_catalog.pg_namespace AS pgn

        ON pgn.oid = pgc.relnamespace

        AND t.table_schema = pgn.nspname

        WHERE

        t.table_schema = 'public'

        AND pgc.relpersistence = 'u';

      • Для всех таблиц в исходной базе данных включена Replica Identity. Вы можете проверить наличие таблиц без Replica Identity с помощью следующего запроса:

        --Tables without replica identity

        SELECT

        t.table_schema,

        t.table_name,

        CASE c.relreplident

        WHEN 'd' THEN 'DEFAULT'

        WHEN 'n' THEN 'NOTHING'

        WHEN 'f' THEN 'FULL'

        WHEN 'i' THEN 'USING INDEX'

        ELSE 'UNKNOWN'

        END AS replica_identity_setting,

        CASE

        WHEN c.relreplident = 'n' THEN 'Explicitly NOTHING'

        WHEN c.relreplident = 'd' AND pk.conname IS NULL THEN 'DEFAULT without Primary Key (effectively NOTHING)'

        ELSE 'Has Replica Identity'

        END AS replica_identity_status

        FROM

        information_schema.tables t

        JOIN

        pg_class c ON c.relname = t.table_name AND c.relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = t.table_schema)

        LEFT JOIN

        pg_constraint pk ON pk.conrelid = c.oid AND pk.contype = 'p'

        WHERE

        t.table_schema NOT IN ('pg_catalog', 'information_schema')

        AND t.table_type = 'BASE TABLE'

        AND (c.relreplident = 'n' OR (c.relreplident = 'd' AND pk.conname IS NULL));

        Для всех найденных таблиц нужно выполнить следующую команду:

        ALTER TABLE ${table_schema}.${table_name} REPLICA IDENTITY FULL;

        где

        `${table_schema}` и `${table_name}` – подстановка из соответствующих столбцов в таблице с результатами предыдущего запроса.

   2. Подготовка новых компонентов для обновления

      Для обновления базы данных нужно подготовить следующие новые компоненты:

      • Отдельный пакет Helm Chart для копирования содержимого базы данных PostgreSQL с версии 15 на версию 18 с помощью логической репликации (далее – англ. Upgrade Helm Chart). Вы можете скачать Helm Chart с помощью следующей команды:

        helm pull oci://repo.kcs.kaspersky.com/charts/kcs-postgres-upgrade --version 2.4.0

      • Новые образы контейнеров, необходимые для включения репликации и переезда базы данных на PostgreSQL 18:
        • initer:v2.4.0
        • external/postgresql:18.2.0

2. Переезд базы данных PostgreSQL
   1. Установка специального пакета Helm Chart kcs-postgres-upgrade v2.4.0

      Вам нужно установить специальный пакет Helm Chart kcs-postgres-upgrade v2.4.0 в пространство имен (англ. namespace), где развернуто ядро Kaspersky Container Security.

      Запускается только новый экземпляр PostgreSQL 18.

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

      При установке пакета Helm Chart нужно учитывать следующее:

      • Учетные и конфигурационные данные, указываемые при установке kcs-db-upgrade, должны совпадать с существующими в PostgreSQL 15.
      • Для организации логической репликации вам также нужно указать учетные данные для доступа к существующей базе (пользователь repuser). Эти учетные данные отсутствуют и их нужно сгенерировать. Для этого используются переменные REPLICATION_POSTGRES_USER и REPLICATION_POSTGRES_PASSWORD.

        helm upgrade --install kcs-postgres-upgrade kcs-postgres-upgrade-2.4.0.tgz \

        --timeout=31m \

        --namespace <namespace> \

        --set secret.pginfracreds.envs.POSTGRES_USER="pguser" \

        --set secret.pginfracreds.envs.POSTGRES_PASSWORD="***" \

        --set secret.pginfracreds.envs.REPLICATION_POSTGRES_USER="repuser" \

        --set secret.pginfracreds.envs.REPLICATION_POSTGRES_PASSWORD="***" \

        --set configmap.pginfraconfig.envs.TLS_INTERNAL=true \

        --set persistentVolume.pvc-pg.size="20Gi" \

        --set persistentVolume.pvc-pg-dump.size="10Gi" \

        --set default.registryRoot="repo.kcs.kaspersky.com/images" \

        --set job.postgresql-upgrade-replication-on.enabled=true

      После установки нового пакета Helm Chart по соседству с экземпляром PostgreSQL со старой версией 15 появляется экземпляр PostgreSQL с новой версией 18. Имя пода (англ. pod) нового экземпляра: kcs-postgresql-0.

      Обратите внимание на незначительное отличие в имени нового экземпляра: postgresql вместо postgres.
      Также обратите внимание на размер persistentVolume.pvc-pg-dump.size. Этот объект Persistent Volume необходим для переноса нежурналируемых таблиц, ĸоторые невозможно перенести с помощью реплиĸации. Он подĸлючается в Jobs при вĸлючении и выĸлючении реплиĸации.

   2. Запуск объекта Job для включения репликации

      Для включения репликации нужно запустить объект Job. Это действие можно совместить с установкой пакета Helm Chart в пункте 2.1.

      Если при первой установке объект Job не был включен, нужно обновить Helm Chart с новым параметром:

      --set job.postgresql-upgrade-replication-on.enabled=true

      Создается и запускается объект Job для включения репликации.

      Job запустится после старта всей рабочей нагрузки. Вместе с включением Job создается соответствующая сетевая политика (англ. NetworkPolicy), чтобы разрешить Job и новому экземпляру PostgreSQL доступ к существующему экземпляру PostgreSQL 15 для включения логической репликации.

      Когда Job запустится, нужно подключиться к выводу лог-данных пода postgresql-upgrade-replication-on-job-????? и контролировать процесс включения репликации. Сценарий выполнит необходимые настройки старой базы PostgreSQL 15 и остановится в ожидании, когда старая база данных сможет принимать подключения.

      Затем нужно вручную перезапустить старую базу данных как описано в пункте 2.3.

   3. Перезапуск старой базы данных

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

      Мы рекомендуем выполнить это действие в соседнем терминале. В текущем терминале рекомендуется продолжить наблюдение за логом объекта Job, запущенным на предыдущем этапе.

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

      Database kcs-postgres. Wal level: replica

      WAL is not logical, waiting...

      Как только такое сообщение появилось в первый раз, необходимо перезапустить старый экземпляр PostgreSQL 15 для применения параметров репликации, которые были выполнены объектом Job, с помощью команды pg_ctl stop:

      kubectl -n <namespace> exec pod/kcs-postgres-0 -- pg_ctl stop

      Удаление или перезапуск пода другим образом может привести к потере данных.

   4. Наблюдение за логами объекта Job. Окончание работы скрипта

      К старой базе PostgreSQL подключены потребители, поэтому ее перезапуск занимает определенное время. В скрипте выставлено время ожидания 1800 секунд (0,5 часа). Вы можете настроить для объекта Job переменную окружения `SCRIPT_TIMEOUT` в секундах.

      Нормальная работа скрипта заканчивается сообщением об успешном запуске логической репликации Logical replication is turned on successfully.

      После успешного выполнения объект Job удалится через 24 часа.
      Поскольку приходится останавливать сервис PostgreSQL 15, ожидаемо появление ошибок вида FATAL: the database system is shutting down.

   5. Просмотр результата репликации

      Вам нужно убедиться, что репликация осуществилась. В логах пода kcs-postgresql-0 появляются записи следующего вида:

      2025-11-17 09:09:54.801 UTC [1123] LOG: logical replication table synchronization worker for subscription "kcssub", table "settings" has started

      2025-11-17 09:09:54.859 UTC [1123] LOG: logical replication table synchronization worker for subscription "kcssub", table "settings" has finished

      В приведенном примере рассматривается одна таблица, но в логе представлены записи для всех таблиц.

      В логах старой и новой баз данных PostgreSQL не должно быть ошибок.

      Также результат выполнения репликации можно примерно оценить по размеру базы данных. Вы можете запустить команду sh в поде с базами данных и посмотреть размеры баз:

      psql -U postgres -c "\l+ api"

      Значения в столбце size должны быть примерно одинаковыми.

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

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

      Остановка рабочей нагрузки рассматривается в пункте 2.6.

      # Последняя отправленная транзакция. Выполнять на старой базе PostgreSQL 15.

      psql -U postgres api -c "SELECT pg_current_wal_lsn();"

      # Последняя полученная и примененная транзакция. Выполнять на новой базе PostgreSQL 18.

      psql -U postgres api -c "SELECT received_lsn, latest_end_lsn FROM pg_catalog.pg_stat_subscription;"

      При выключенной рабочей нагрузке и отсутствии обновлений в старой базе данных идентификатор транзакции не должен меняться.
      Идентификатор транзакции должен быть одинаковый в старой (PostgreSQL 15) и новой (PostgreSQL 18) базах данных.

   6. Масштабирование рабочей нагрузки, которая использует базу данных

      Вам нужно масштабировать в 0 рабочую нагрузку, которая использует базу данных, следующим образом:

      kubectl -n <namespace> scale deployment kcs-ab --replicas=0

      kubectl -n <namespace> scale deployment kcs-middleware --replicas=0

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

   7. Запуск объекта Job для выключения репликации

      Для выключения репликации нужно запустить объект Job. После остановки микросервисов идентификатор транзакции на обеих базах данных станет одинаковым и вам нужно запустить задание на остановку репликации. В рамках этого задания требуется выполнить следующие действия:

      • Синхронизация последовательностей и удаление публикаций и подписок.

        Количество реплик для kcs-ab и kcs-middleware должно быть 0 до перехода на новую базу данных.

      • Обновление пакета Helm Chart со следующими параметрами:

        --set job.postgresql-upgrade-replication-on.enabled=false \

        --set job.postgresql-upgrade-replication-off.enabled=true \

        Значение этих переменных не может быть true одновременно, Helm Chart не установится.

      Нормальная работа скрипта заканчивается сообщением об успешном выключении логической репликации Logical replication is turned off successfully.

   8. Удаление пакета Upgrade Helm Chart

      Для удаления используется следующая команда:

      helm -n <namespace> uninstall kcs-postgres-upgrade

   9. Обновление и запуск Kaspersky Container Security на новой базе данных

      После удаления пакета Upgrade Helm Chart от новой базы данных остались PVC и PV. Они используются для запуска новой постоянной базы данных на PostgreSQL 18.

      Для запуска требуется пакет Helm Chart версии 2.4.0 или новее.

      Необходимо убедиться, что в конфигурационном файле values.yaml (если используется values, не входящий в состав Helm Chart) отсутствуют следующие старые конструкции:

      • default.postgresql
      • persistentVolume.postgresql
      • addCerts.kcs-postgres
      • component.kcs-postgres

      Один из основных конфигурационных параметров – это переменная с адресом объекта Service для всех подов, подключающихся к базе данных:

      configmap:

      infraconfig:

      envs:

      POSTGRES_HOST: kcs-postgresql

      Параметры, начинающиеся с --set job., нужно убрать из конфигурационного файла. Они нужны только для логической репликации, которая уже завершилась. Job присутствует только в служебном Helm Chart для обновления.

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

      • Остановленная ранее рабочая нагрузка в виде подов kcs-ab и kcs-middleware активируется.
      • Старая база данных PostgreSQL 15 перестает работать.
      • PV и PVC сохраняются.

   10. Подключение к консоли управления и проверка работоспособности

       На этом этапе также нужно посмотреть логи пода с базой данных и удостовериться в отсутствии ошибок.

   11. Действия с объектом PVC PostgreSQL версии 15

       После обновления от старой базы данных PostgreSQL версии 15 останутся PVC с данными старой версии решения и PVC с данными для переноса нежурналируемых таблиц. Все дальнейшие действия с PVC и PV осуществляются на усмотрение администратора безопасности.

   12. Удаление объектов Job

       После репликации базы данных останутся объекты Job postgresql-upgrade-replication-on-job и postgresql-upgrade-replication-off-job. Вы можете удалить их вручную, либо они удалятся самостоятельно через 24 часа после выполнения Job.