Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for PostgreSQL
  • Начало работы
    • Все руководства
    • Создание кластера PostgreSQL для 1С
    • Создание кластера Linux-серверов «1С:Предприятия» с кластером Managed Service for PostgreSQL
    • Выгрузка базы данных в Yandex Data Processing
    • Поиск проблем с производительностью кластера
    • Анализ производительности и оптимизация
    • Настройка подключения из контейнера Serverless Containers
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Поставка данных в Yandex Managed Service for YDB с помощью Yandex Data Transfer
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Debezium
    • Захват изменений PostgreSQL и поставка в YDS
    • Поставка данных из Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Перенос данных из Yandex Object Storage с использованием Yandex Data Transfer
    • Настройка отказоустойчивой архитектуры в Yandex Cloud
    • Мониторинг состояния географически распределенных устройств
    • Запись логов балансировщика в PostgreSQL
    • Создание сервера MLFlow для логирования экспериментов и артефактов
    • Работа с данными с помощью Query
    • Федеративные запросы к данным с помощью Query
    • Решение проблем с сортировкой строк после обновления glibc
    • Запись данных с устройства в базу данных
      • Логическая репликация PostgreSQL
      • Миграция базы данных в Managed Service for PostgreSQL
      • Миграция базы данных из Managed Service for PostgreSQL
      • Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL
      • Миграция базы данных из Yandex Managed Service for PostgreSQL в Yandex Object Storage
      • Миграция данных из Yandex Managed Service for MySQL® в Managed Service for PostgreSQL с помощью Yandex Data Transfer
      • Миграция данных из Managed Service for PostgreSQL в Yandex Managed Service for MySQL® с помощью Yandex Data Transfer
      • Миграция данных из AWS RDS for PostgreSQL в Managed Service for PostgreSQL с помощью Yandex Data Transfer
      • Миграция базы данных из Greenplum® в PostgreSQL
      • Миграция данных из Managed Service for PostgreSQL в Managed Service for OpenSearch с помощью Yandex Data Transfer
      • Асинхронная репликация данных из PostgreSQL в ClickHouse®
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Публичные материалы
  • История изменений
  • Обучающие курсы

В этой статье:

  • Необходимые платные ресурсы
  • Особенности использования логической репликации
  • Перед началом работы
  • Настройте Amazon RDS
  • Настройте кластер-приемник и создайте подписку
  • Перенесите последовательности
  • Удалите подписку и переключите нагрузку на кластер-приемник
  1. Практические руководства
  2. Репликация и миграция
  3. Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL

Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL

Статья создана
Yandex Cloud
Обновлена 18 марта 2025 г.
  • Необходимые платные ресурсы
  • Особенности использования логической репликации
  • Перед началом работы
  • Настройте Amazon RDS
  • Настройте кластер-приемник и создайте подписку
    • Перенесите последовательности
    • Удалите подписку и переключите нагрузку на кластер-приемник

Перенести базу данных из кластера-источника Amazon RDS для PostgreSQL в кластер-приемник Managed Service for PostgreSQL можно с помощью логической репликации.

Логическая репликация использует механизм подписки (subscription). Это позволяет перенести данные в кластер-приемник с минимальным временем простоя. Логическая репликация доступна в Amazon RDS для PostgreSQL версии 10.4 и выше.

Используйте логическую репликацию в том случае, если перенос данных с помощью Yandex Data Transfer по каким-либо причинам невозможен.

Чтобы перенести базу данных из кластера-источника Amazon RDS для PostgreSQL в кластер-приемник Managed Service for PostgreSQL:

  1. Настройте Amazon RDS.
  2. Настройте кластер-приемник и создайте подписку.
  3. Перенесите последовательности.
  4. Удалите подписку и переключите нагрузку на кластер-приемник.

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость поддержки описываемого решения входят:

  • Плата за кластер Managed Service for PostgreSQL: использование вычислительных ресурсов, выделенных хостам, и дискового пространства (см. тарифы Managed Service for PostgreSQL).
  • Плата за использование публичных IP-адресов для хостов кластера (см. тарифы Virtual Private Cloud).

Особенности использования логической репликацииОсобенности использования логической репликации

  • Изменения схемы базы данных и DDL не реплицируются.

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

  • Последовательности (SEQUENCES) не реплицируются.

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

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

    ALTER SEQUENCE serial RESTART WITH <новое_значение>;
    
  • По умолчанию при создании подписки происходит полное копирование данных из исходных таблиц.

    Для ускорения копирования создайте только первичный ключ (PRIMARY KEY), а после его завершения создайте все остальные индексы.

  • Если в таблице отсутствует первичный ключ, во время репликации появятся ошибки:

    ERROR: 55000: cannot update table "<имя_таблицы>" because it does not have a replica identity and publishes updates
    HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE.
    

    Для работы репликации UPDATE и DELETE в таблицах без первичного ключа необходимо изменить REPLICA IDENTITY:

    ALTER TABLE <имя_таблицы> REPLICA IDENTITY FULL;
    
  • Внешние таблицы не реплицируются.

  • Если потребуется пересоздать подписку, то для предотвращения ошибок ограничения первичного ключа очистите таблицы в кластере-приемнике.

  • Ошибки, связанные с работой логической репликации, смотрите в логах Managed Service for PostgreSQL.

Перед началом работыПеред началом работы

Создайте необходимые ресурсы:

Вручную
Terraform

Создайте кластер Managed Service for PostgreSQL с публичным доступом к хостам. При этом:

  • Версия PostgreSQL должна быть не ниже, чем в кластере-источнике. Миграция с понижением версии PostgreSQL невозможна.
  • Имя базы данных должно быть такое же, как и в кластере-источнике.
  • Включите те же расширения PostgreSQL, что и в базе-источнике.
  1. Если у вас еще нет Terraform, установите его.

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

  3. Настройте и инициализируйте провайдер. Чтобы не создавать конфигурационный файл с настройками провайдера вручную, скачайте его.

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

  5. Скачайте в ту же рабочую директорию файл конфигурации logical-replica-amazon-rds-to-postgresql.tf.

    В этом файле описаны:

    • сеть;
    • подсеть;
    • группа безопасности и правило, разрешающее подключение к кластеру;
    • кластер Managed Service for PostgreSQL с публичным доступом из интернета.
  6. Укажите параметры инфраструктуры в файле конфигурации logical-replica-amazon-rds-to-postgresql.tf в блоке locals:

    • pg_version — версия PostgreSQL. Она должна быть не ниже, чем в Amazon RDS.
    • db_name — имя базы данных в кластере-приемнике. Должно совпадать с именем базы-источника.
    • username и password — имя и пароль пользователя-владельца базы данных.
    • Имена и версии расширений PostgreSQL, используемых в Amazon RDS. Для этого раскомментируйте и размножьте блок extension.
  7. Проверьте корректность файлов конфигурации Terraform с помощью команды:

    terraform validate
    

    Если в файлах конфигурации есть ошибки, Terraform на них укажет.

  8. Создайте необходимую инфраструктуру:

    1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

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

    2. Если вас устраивают планируемые изменения, внесите их:

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

        terraform apply
        
      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

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

Настройте Amazon RDSНастройте Amazon RDS

Важно

Экземпляр БД должен иметь публичный доступ — Public accessibility = yes.

  1. Настройте логическую репликацию.

    1. Установите параметр в parameter group вашего экземпляра БД:

      rds.logical_replication = 1
      
    2. Перезапустите кластер для применения изменений.

  2. Создайте отдельного пользователя с ролью rds_replication. Для этого выполните от имени пользователя с ролью rds_superuser:

    CREATE ROLE <имя_пользователя> WITH LOGIN PASSWORD <пароль>;
    GRANT rds_replication TO <имя_пользователя>;
    
  3. Предоставьте привилегию SELECT на все таблицы, участвующие в репликации:

    GRANT SELECT ON <таблица_1>, <таблица_2>, ..., <таблица_n> TO <имя_пользователя>;
    
  4. Создайте публикацию:

    CREATE PUBLICATION pub FOR TABLE <таблица_1>, <таблица_2>, ..., <таблица_n>;
    

    Примечание

    Не рекомендуется использовать публикации FOR ALL TABLES из-за невозможности отредактировать список таблиц в будущем.

  5. Добавьте правило для входящего трафика в VPC security groups. Например:

    protocol: tcp, port: 5432, source: 84.201.175.90/32
    

    Где 84.201.175.90 — публичный IP-адрес.

Настройте кластер-приемник и создайте подпискуНастройте кластер-приемник и создайте подписку

В кластерах Managed Service for PostgreSQL подписки может использовать владелец базы данных (пользователь, созданный одновременно с кластером) и пользователи с ролью mdb_admin или mdb_superuser для этого кластера.

  1. (Опционально) Назначьте пользователю кластера Managed Service for PostgreSQL роль mdb_admin или mdb_superuser.

  2. Создайте подписку со строкой подключения к кластеру-источнику:

    CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес_кластера-источника> port=<порт> user=<имя_пользователя> sslmode=prefer dbname=<имя_БД>' PUBLICATION pub;
    

    Подробнее о создании подписок см. в документации PostgreSQL.

  3. Чтобы получить статус репликации, обратитесь к каталогам pg_subscription_rel.

    SELECT * FROM pg_subscription_rel;
    

    Значение r в поле srsubstate означает, что репликация завершилась.

Перенесите последовательностиПеренесите последовательности

Чтобы завершить синхронизацию кластера-источника и кластера-приемника:

  1. Переведите кластер-источник в режим только чтение.

  2. Создайте дамп с последовательностями:

    pg_dump --host=<адрес_кластера-источника> \
            --username=<имя_пользователя> \
            --port=<порт> \
            --dbname=<имя_БД> \
            --data-only \
            --table='*.*_seq' > /tmp/seq-data.sql
    

    Обратите внимание на используемый паттерн *.*_seq. Если в переносимой базе есть не соответствующие ему последовательности, то для их выгрузки укажите другой паттерн.

    Подробнее о паттернах см. в документации PostgreSQL.

  3. Восстановите дамп с последовательностями в кластере-приемнике:

    psql \
        --host=<FQDN_хоста-мастера_кластера-приемника> \
        --username=<имя_пользователя> \
        --port=6432 \
        --dbname=<имя_БД> < /tmp/seq-data.sql
    

Удалите подписку и переключите нагрузку на кластер-приемникУдалите подписку и переключите нагрузку на кластер-приемник

  1. Удалите подписку в кластере-приемнике:

    DROP SUBSCRIPTION s_data_migration;
    
  2. Перенесите нагрузку на кластер-приемник.

Была ли статья полезна?

Предыдущая
Миграция базы данных из Managed Service for PostgreSQL
Следующая
Миграция базы данных из Yandex Managed Service for PostgreSQL в Yandex Object Storage
Проект Яндекса
© 2025 ООО «Яндекс.Облако»