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
  • Публичные материалы
  • История изменений
  • Обучающие курсы

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

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

Миграция базы данных из Managed Service for PostgreSQL

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

Кластер Managed Service for PostgreSQL поддерживает логическую репликацию. Это позволяет мигрировать базы данных встроенными средствами PostgreSQL между разными кластерами PostgreSQL версий 10 и выше. В том числе поддерживается миграция между разными версиями: например, можно перенести базы из PostgreSQL версии 11 в версию 13.

Примечание

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

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

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

  1. Перенесите схему базы данных.
  2. Настройте пользователя для управления репликацией на кластере-источнике.
  3. Создайте публикацию на кластере-источнике.
  4. Создайте подписку на кластере-приемнике.
  5. Отслеживайте процесс миграции до его завершения.
  6. Закончите миграцию.

Если созданные ресурсы вам больше не нужны, удалите их.

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

  1. Убедитесь, что все хосты кластера-источника доступны по публичному IP-адресу, чтобы кластер-приемник мог подключаться к источнику. Подробнее см. в разделе Создание кластера.

  2. Установите на хосты кластера-приемника клиентские SSL-сертификаты Managed Service for PostgreSQL. Они требуются для успешного подключения к публично доступному кластеру-источнику.

  3. При необходимости настройте межсетевой экран (firewall) и группы безопасности, чтобы можно было подключаться из кластера-приемника к кластеру-источнику, а также к каждому кластеру в отдельности (например, с помощью утилиты psql).

  4. Убедитесь, что с хостов кластера-приемника можно подключиться к хостам кластера-источника.

  5. Убедитесь, что можно подключиться к кластеру-источнику с помощью SSL и к кластеру-приемнику.

  6. Убедитесь, что на кластере-приемнике создана пустая база данных, в которую будет проведена миграция.

  7. Убедитесь, что в кластере-приемнике существует пользователь с полными правами на доступ к этой базе.

Перенесите схему базы данныхПеренесите схему базы данных

Для успешной работы логической репликации необходимо, чтобы и на источнике, и на приемнике была одинаковая схема базы данных. Чтобы перенести схему базы данных:

  1. Сделайте дамп схемы базы данных кластера-источника с помощью утилиты pg_dump:

    pg_dump "host=<FQDN_хоста_кластера-источника> port=6432 sslmode=verify-full dbname=<имя_БД> user=<имя_пользователя-владельца_БД>" --schema-only --no-privileges --no-subscriptions --no-publications -Fd -f <директория_для_дампа>
    

    FQDN хоста можно получить со списком хостов в кластере.

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

  3. Восстановите схему базы данных из дампа на кластере-приемнике с помощью утилиты pg_restore:

    pg_restore -Fd -v --single-transaction -s --no-privileges -h <FQDN_хоста-мастера_кластера-приемника> -U <имя_пользователя-владельца_БД> -p 5432 -d <имя_БД> <директория_с_дампом>
    

Настройте пользователя для управления репликацией на кластере-источникеНастройте пользователя для управления репликацией на кластере-источнике

PostgreSQL использует модель «публикация-подписка» при выполнении логической репликации: кластер-приемник подписывается на публикацию кластера-источника, чтобы перенести данные. Чтобы успешно подписаться на публикацию, к кластеру-источнику Managed Service for PostgreSQL нужно обращаться от имени пользователя, которому назначена роль для управления логической репликацией. Чтобы настроить такого пользователя:

  1. Создайте пользователя.
  2. Назначьте роль mdb_replication этому пользователю.
  3. Подключитесь к базе данных, которую нужно мигрировать, от имени владельца базы.
  4. Выдайте созданному пользователю привилегию на выполнение операции SELECT над всеми таблицами базы данных.

После создания подписки подключение к кластеру-источнику со стороны приемника будет осуществляться от имени этого пользователя.

Создайте публикацию на кластере-источникеСоздайте публикацию на кластере-источнике

  1. Подключитесь к хосту-мастеру и к базе данных, которую нужно мигрировать, от имени владельца базы.

  2. Создайте публикацию, на которую будет подписываться кластер-приемник:

    CREATE PUBLICATION <имя_публикации>;
    
  3. Включите в созданную публикацию все таблицы базы данных:

    ALTER PUBLICATION <имя_публикации> ADD TABLE <имя_таблицы_1>;
    ...
    ALTER PUBLICATION <имя_публикации> ADD TABLE <имя_таблицы_N>;
    

    Примечание

    В кластере Managed Service for PostgreSQL запрещено создание публикации сразу для всех таблиц CREATE PUBLICATION ... FOR ALL TABLES;, т.к. это требует привилегий суперпользователя.

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

  1. Подключитесь к хосту-мастеру и базе данных, в которую нужно выполнить миграцию, от имени суперпользователя (например, postgres).

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

    CREATE SUBSCRIPTION <имя_подписки> CONNECTION 'host=<FQDN_хоста_кластера-источника> port=6432 sslmode=verify-full dbname=<имя_БД_которую_нужно_мигрировать> user=<имя_пользователя_для_управления_репликацией> password=<пароль_пользователя>' PUBLICATION <имя_публикации>;
    

Начнется процесс миграции данных из базы кластера-источника в базу кластера-приемника.

Отслеживание процесса миграцииОтслеживание процесса миграции

Следите за миграцией с помощью каталога pg_subscription_rel, который показывает статус репликации:

SELECT * FROM pg_subscription_rel;

 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+----------
...

Рекомендуется следить за статусом репликации по полю srsubstate этого каталога на кластере-приемнике.

Общий статус репликации на кластере-приемнике можно получить с помощью представления (view) pg_stat_subscription, на источнике — с помощью представления pg_stat_replication.

Закончите миграциюЗакончите миграцию

После завершения процесса репликации:

  1. Запретите запись в смигрированную базу данных на кластере-источнике.

  2. Перенесите последовательности (sequences), если они есть, из кластера-источника на кластер-приемник с помощью утилит pg_dump и psql:

    pg_dump "host=<FQDN_хоста-мастера_кластера-источника> port=6432 sslmode=verify-full dbname=<имя_БД> user=<имя_пользователя-владельца_БД>" --data-only -t '*.*_seq' > <имя_файла_с_sequences>
    
    psql -h <FQDN_хоста-мастера_кластера-приемника> -U <имя_пользователя-владельца_БД> -p 5432 -d <имя_БД> < <имя_файла_с_sequences>
    
  3. Удалите подписку на кластере-приемнике:

    DROP SUBSCRIPTION <имя_подписки>;
    
  4. Удалите публикацию на кластере-источнике:

    DROP PUBLICATION <имя_публикации>;
    
  5. Удалите пользователя для управления репликацией на кластере-источнике.

Удалите созданные ресурсыУдалите созданные ресурсы

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

  • Удалите виртуальную машину.
  • Если вы зарезервировали для виртуальной машины публичный статический IP-адрес, удалите его.
  • Удалите кластер Yandex Managed Service for PostgreSQL.

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

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