Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
© 2022 ООО «Яндекс.Облако»
Yandex Managed Service for PostgreSQL
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к базе данных
    • Остановка и запуск кластера
    • SQL-запросы в консоли управления
    • Обновление версии PostgreSQL
    • Изменение настроек кластера и базы данных
    • Подключение к DataLens
    • Управление хостами PostgreSQL
    • Управление базами данных
    • Управление PostgreSQL-расширениями
    • Управление пользователями БД
    • Назначение привилегий и ролей
    • Управление резервными копиями
    • Просмотр логов кластера
    • Удаление кластера
    • Диагностика производительности
    • Мониторинг состояния кластера и хостов
  • Практические руководства
    • Создание кластера PostgreSQL для 1С
    • Выгрузка базы данных в Yandex Data Proc
    • Анализ производительности и оптимизация
    • Репликация и миграция
      • Логическая репликация PostgreSQL
      • Миграция базы данных в Managed Service for PostgreSQL
      • Миграция базы данных из Managed Service for PostgreSQL
      • Создание логической реплики Amazon RDS для PostgreSQL в Managed Service for PostgreSQL
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Yandex Data Transfer
    • Поставка данных в Yandex Managed Service for Apache Kafka® с помощью Debezium
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
      • Действующие классы хостов
      • Архив
        • До 1 июня 2020 года
      • Использование устаревших классов хостов
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Хранилище в Managed Service for PostgreSQL
    • Резервные копии
    • Назначение ролей
    • Управление соединениями
    • Репликация
    • Техническое обслуживание
    • Поддерживаемые клиенты
    • Настройки PostgreSQL
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 января 2019 года
      • С 1 января до 1 марта 2019 года
      • С 1 марта 2019 года до 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC (англ.)
      • Overview
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST (англ.)
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • Database
        • Overview
        • create
        • delete
        • get
        • list
        • update
      • ResourcePreset
        • Overview
        • get
        • list
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • История изменений
  • Вопросы и ответы
    • Общие вопросы
    • Подключение
    • Изменение кластера
    • Настройки параметров кластера
    • Перемещение и восстановление кластера
    • Мониторинг и логи
    • Все вопросы на одной странице
  1. Практические руководства
  2. Репликация и миграция
  3. Миграция базы данных в Managed Service for PostgreSQL

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

Статья создана
Yandex Cloud
  • Перед началом работы
  • Перенос данных с использованием сервиса Yandex Data Transfer
  • Перенос данных с помощью логической репликации
    • Настройте кластер-источник
    • Экспортируйте схему БД в кластере-источнике
    • Восстановите схему БД в кластере-приемнике
    • Создайте публикацию и подписку
    • Перенесите PostgreSQL-sequences после репликации
    • Удалите подписку и перенесите нагрузку
  • Перенос данных через создание и восстановление логического дампа
    • Создайте дамп базы данных
    • (опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп на нее
    • Восстановите данные из дампа в кластер-приемник

Чтобы перенести вашу базу данных в сервис Managed Service for PostgreSQL, нужно непосредственно перенести данные, закрыть старую базу данных на запись и перенести нагрузку на кластер БД в Yandex Cloud.

Перенести данные из стороннего кластера-источника в кластер-приемник Managed Service for PostgreSQL можно тремя способами:

  • Перенос данных с использованием сервиса Yandex Data Transfer.

    Этот способ позволяет:

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

    Чтобы использовать этот способ, разрешите подключение к кластеру-источнику из интернета.

    Подробнее см. в разделе Какие задачи решает сервис Yandex Data Transfer.

  • Перенос данных с помощью логической репликации.

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

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

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

    Логический дамп — файл с набором команд, последовательное выполнение которых позволяет восстановить состояние базы данных. Он создается с помощью утилиты pg_dump. Чтобы обеспечить полноту логического дампа, перед его созданием кластер-источник следует перевести в режим только чтение.

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

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

Создайте кластер Managed Service for PostgreSQL любой подходящей конфигурации. При этом:

  • Версия PostgreSQL должна быть не ниже чем в кластере-источнике. Для способа с использованием логического дампа версии должны совпадать.

    Миграция с понижением версии PostgreSQL невозможна.

  • При создании кластера укажите то же имя базы данных, что и в кластере-источнике.

  • Включите те же расширения PostgreSQL, что и в кластере-источнике.

Перенос данных с использованием сервиса Yandex Data Transfer

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

  2. Подготовьте кластер-приемник.

  3. Создайте эндпоинт для источника со следующими параметрами:

    • Тип базы данных — PostgreSQL.

    • Параметры эндпоинта → Настройки подключения — Пользовательская инсталляция.

      Укажите параметры подключения к кластеру-источнику.

  4. Создайте эндпоинт для приемника со следующими параметрами:

    • Тип базы данных — PostgreSQL.

    • Параметры эндпоинта → Настройки подключения — Кластер MDB.

      Укажите идентификатор кластера-приемника.

  5. Создайте трансфер типа Копировать и реплицировать, использующий созданные эндпоинты.

  6. Активируйте трансфер.

    Важно

    Избегайте любых изменений в схеме данных в кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.

  7. Дождитесь перехода трансфера в статус Реплицируется.

  8. Переведите кластер-источник в режим только чтение и переключите нагрузку на кластер-приемник.

  9. На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum lag on delivery. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.

  10. Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.

    Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.

  11. Удалите остановленный трансфер.

  12. Удалите эндпоинты для источника и приемника.

Перенос данных с помощью логической репликации

Логическая репликация поддерживается PostgreSQL с версии 10. Кроме миграции данных между одинаковыми версиями PostgreSQL, логическая репликация позволяет мигрировать на более новые версии PostgreSQL.

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

Этапы миграции:

  1. Настройте кластер-источник.
  2. Экспортируйте схему БД в кластере-источнике.
  3. Восстановите схему БД в кластере-приемнике.
  4. Создайте публикацию и подписку PostgreSQL.
  5. Перенесите PostgreSQL-sequence после репликации.
  6. Отключите репликацию и перенесите нагрузку.

Настройте кластер-источник

  1. Укажите нужные настройки SSL и WAL в файле postgresql.conf. В ОС Debian и Ubuntu путь к этому файлу по умолчанию — /etc/postgresql/<версия PostgreSQL>/main/postgresql.conf.

    1. Для миграции данных рекомендуется использовать SSL: это поможет не только шифровать данные, но и сжимать их. Подробнее в разделах документации PostgreSQL, SSL Support и Database Connection Control Functions.

      Чтобы включить использование SSL, задайте нужное значение в конфигурации:

      ssl = on                   # on, off
      
    2. Измените уровень логирования для Write Ahead Log (WAL), чтобы добавить в него информацию, необходимую для логической репликации. Для этого установите значение logical для настройки wal_level.

      Настройку можно изменить в файле postgresql.conf. Найдите строку с настройкой wal_level, раскомментируйте ее при необходимости и установите значение logical:

      wal_level = logical                    # minimal, replica, or logical
      
  2. Настройте аутентификацию хостов в кластере-источнике. Для этого нужно внести хосты кластера в Yandex Cloud в файл pg_hba.conf (на дистрибутивах Debian и Ubuntu по умолчанию расположен по пути /etc/postgresql/<версия PostgreSQL>/main/pg_hba.conf).

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

    • Если вы используете SSL:

      hostssl         all            all             <адрес хоста>      md5
      hostssl         replication    all             <адрес хоста>      md5
      
    • Если вы не используете SSL:

      host         all            all             <адрес хоста>      md5
      host         replication    all             <адрес хоста>      md5
      
  3. Если в кластере-источнике работает файервол, разрешите входящие соединения с хостов кластера Managed Service for PostgreSQL. Например, для Ubuntu 18:

    sudo ufw allow from <адрес хоста кластера-приемника> to any port <порт>
    
  4. Перезапустите сервис PostgreSQL, чтобы применить все сделанные настройки:

    sudo systemctl restart postgresql
    
  5. Проверьте статус сервиса PostgreSQL после перезапуска:

    sudo systemctl status postgresql
    

Экспортируйте схему БД в кластере-источнике

С помощью утилиты pg_dump создайте файл со схемой БД, которую нужно будет применить в кластере-приемнике.

pg_dump -h <IP-адрес или FQDN хоста-мастера кластера-источника> \
        -U <имя пользователя> \
        -p <порт> \
        --schema-only \
        --no-privileges \
        --no-subscriptions \
        -d <имя базы данных> \
        -Fd -f /tmp/db_dump

В этой команде при экспорте исключаются все данные, связанные с привилегиями и ролями, чтобы не возникало конфликтов с настройками БД в Yandex Cloud. Если вашей БД нужны дополнительные пользователи, создайте их.

Восстановите схему БД в кластере-приемнике

С помощью утилиты pg_restore восстановите схему БД в кластере-приемнике:

pg_restore -h <IP-адрес или FQDN хоста-мастера кластера-приемника> \
           -U <имя пользователя> \
           -p 6432 \
           -Fd -v \
           --single-transaction \
           -s --no-privileges \
           -d <имя базы данных> /tmp/db_dump

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

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

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

    Примечание

    Для создания публикации на все таблицы потребуются права суперпользователя, а для переноса выбранных таблиц — нет. Более подробно о создании публикации см. в документации PostgreSQL.

    Запрос:

    CREATE PUBLICATION p_data_migration FOR ALL TABLES;
    
  2. На хосте кластера Managed Service for PostgreSQL создайте подписку со строкой подключения к публикации. Более подробно о создании подписок см. в документации PostgreSQL.

    Запрос с включенным SSL:

    CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес кластера-источника> port=<порт> user=<имя пользователя> sslmode=verify-full dbname=<имя базы данных>' PUBLICATION p_data_migration;
    

    Без SSL:

    CREATE SUBSCRIPTION s_data_migration CONNECTION 'host=<адрес кластера-источника> port=<порт> user=<имя пользователя> sslmode=disable dbname=<имя базы данных>' PUBLICATION p_data_migration;
    
  3. Чтобы получить статус репликации, обратитесь к каталогам pg_subscription_rel. Общий статус репликации в кластере-приемнике можно получить через pg_stat_subscription, в кластере-источнике — через pg_stat_replication.

    SELECT * FROM pg_subscription_rel;
    

    Прежде всего обратите внимание на поле srsubstate. Значение r в нем означает, что синхронизация завершилась и базы готовы к репликации.

Перенесите PostgreSQL-sequences после репликации

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

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

  2. Создайте дамп с PostgreSQL-sequences в кластере-источнике:

    pg_dump -h <IP-адрес или FQDN хоста-мастера кластера-источника> \
            -U <имя пользователя> \
            -p <порт> \
            -d <имя базы данных> \
            --data-only -t '*.*_seq' > /tmp/seq-data.sql
    

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

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

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

    psql -h <IP-адрес или FQDN хоста-мастера кластера-приемника> \
         -U <имя пользователя> \
         -p 6432 \
         -d <имя базы данных> \
         < /tmp/seq-data.sql
    

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

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

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

Перенос данных через создание и восстановление логического дампа

Создайте дамп нужной базы в кластере-источнике с помощью утилиты pg_dump. Для восстановления дампа в кластере-приемнике используйте утилиту pg_restore.

Примечание

Для использования утилиты pg_restore может понадобиться расширение базы данных pg_repack.

Этапы миграции:

  1. Создайте дамп переносимой базы.
  2. (опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп БД на нее.
  3. Восстановите данные из дампа в кластер-приемник.

Создайте дамп базы данных

  1. Переключите базу в режим только чтение.

  2. Создайте дамп с помощью утилиты pg_dump. Для ускорения процесса запустите ее в многопоточном режиме, передав в аргументе -j количество доступных ядер процессора:

    pg_dump -h <IP-адрес или FQDN хоста-мастера кластера-источника> \
            -U <имя пользователя> \
            -j <количество ядер процессора> \
            -Fd -d <имя базы данных> \
            -f ~/db_dump
    
  3. Упакуйте дамп в архив:

    tar -cvzf db_dump.tar.gz ~/db_dump
    

(опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп на нее

Переносить данные на промежуточную виртуальную машину в Compute Cloud нужно, если:

  • К вашему кластеру Managed Service for PostgreSQL нет доступа из интернета.
  • Ваше оборудование или соединение с кластером в Yandex Cloud недостаточно надежны.

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

Чтобы подготовить виртуальную машину для восстановления дампа:

  1. В консоли управления создайте новую виртуальную машину из образа Ubuntu 20.04. Параметры виртуальной машины должны зависеть от размера базы, которую вы хотите перенести. Минимальной конфигурации (1 ядро, 2 ГБ RAM, 10 ГБ дискового пространства) должно хватить для переноса базы до 1 ГБ. Чем больше переносимая база, тем больше должно быть оперативной памяти, и тем больше должно быть дискового пространства (как минимум в два раза больше, чем размер базы).

    Виртуальная машина должна находиться в той же сети и зоне доступности, что и кластер PostgreSQL. Кроме того, виртуальной машине должен быть присвоен публичный IP-адрес, чтобы вы могли загрузить дамп извне Yandex Cloud.

  2. Настройте apt-репозиторий PostgreSQL.

  3. Установите клиент PostgreSQL и дополнительные утилиты для работы с СУБД:

    sudo apt install postgresql-client-common
    
    # Для PostgreSQL 10
    sudo apt install postgresql-client-10
    
    # Для PostgreSQL 11
    sudo apt install postgresql-client-11
    
    # Для PostgreSQL 12
    sudo apt install postgresql-client-12
    
    # Для PostgreSQL 13
    sudo apt install postgresql-client-13
    
    # Для PostgreSQL 14
    sudo apt install postgresql-client-14
    
  4. Перенесите дамп базы данных на виртуальную машину, например, используя утилиту scp:

    scp ~/db_dump.tar.gz <имя пользователя ВМ>@<публичный адрес ВМ>:/tmp/db_dump.tar.gz
    
  5. Распакуйте дамп:

    tar -xzf /tmp/db_dump.tar.gz
    

Восстановите данные из дампа в кластер-приемник

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

Версия pg_restore должна совпадать с версией pg_dump, а мажорная версия должна быть не меньше, чем у базы на которую дамп разворачивается.

Таким образом, для восстановления дампа PostgreSQL 10, PostgreSQL 11, PostgreSQL 12, PostgreSQL 13 и PostgreSQL 14 используйте pg_restore 10, pg_restore 11, pg_restore 12, pg_restore 13, pg_restore 14 соответственно.

Если нужно восстановить только одну схему, добавьте флаг -n <имя схемы> (без этого флага команда сработает только от лица владельца базы данных). Восстановление лучше всего проводить с флагом --single-transaction, чтобы избежать неопределенного состояния базы в случае ошибки:

pg_restore -h <IP-адрес или FQDN хоста-мастера кластера-приемника> \
           -U <имя пользователя>
           -d <имя базы данных> \
           -p 6432 \
           -Fd -v \
           /tmp/db_dump \
           --single-transaction \
           --no-privileges

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

Language / Region
© 2022 ООО «Яндекс.Облако»
В этой статье:
  • Перед началом работы
  • Перенос данных с использованием сервиса Yandex Data Transfer
  • Перенос данных с помощью логической репликации
  • Настройте кластер-источник
  • Экспортируйте схему БД в кластере-источнике
  • Восстановите схему БД в кластере-приемнике
  • Создайте публикацию и подписку
  • Перенесите PostgreSQL-sequences после репликации
  • Удалите подписку и перенесите нагрузку
  • Перенос данных через создание и восстановление логического дампа
  • Создайте дамп базы данных
  • (опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп на нее
  • Восстановите данные из дампа в кластер-приемник