Миграция базы данных в Managed Service for PostgreSQL
Чтобы перенести вашу базу данных в сервис 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
-
Создайте эндпоинт для источника со следующими параметрами:
-
Тип базы данных —
PostgreSQL
. -
Параметры эндпоинта → Настройки подключения —
Пользовательская инсталляция
.Укажите параметры подключения к кластеру-источнику.
-
-
Создайте эндпоинт для приемника со следующими параметрами:
-
Тип базы данных —
PostgreSQL
. -
Параметры эндпоинта → Настройки подключения —
Кластер MDB
.Укажите идентификатор кластера-приемника.
-
-
Создайте трансфер типа Копировать и реплицировать, использующий созданные эндпоинты.
-
Важно
Избегайте любых изменений в схеме данных в кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.
-
Дождитесь перехода трансфера в статус Реплицируется.
-
Переведите кластер-источник в режим
только чтение
и переключите нагрузку на кластер-приемник. -
На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum lag on delivery. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.
-
Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.
Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.
-
Удалите эндпоинты для источника и приемника.
Перенос данных с помощью логической репликации
Логическая репликация поддерживается PostgreSQL с версии 10. Кроме миграции данных между одинаковыми версиями PostgreSQL, логическая репликация позволяет мигрировать на более новые версии PostgreSQL.
В кластерах Managed Service for PostgreSQL подписки может использовать владелец базы данных (пользователь, созданный одновременно с кластером) и пользователи с ролью mdb_admin
для этого кластера.
Этапы миграции:
- Настройте кластер-источник.
- Экспортируйте схему БД в кластере-источнике.
- Восстановите схему БД в кластере-приемнике.
- Создайте публикацию и подписку PostgreSQL.
- Перенесите PostgreSQL-sequence после репликации.
- Отключите репликацию и перенесите нагрузку.
Настройте кластер-источник
-
Укажите нужные настройки SSL и WAL в файле
postgresql.conf
. В ОС Debian и Ubuntu путь к этому файлу по умолчанию —/etc/postgresql/<версия PostgreSQL>/main/postgresql.conf
.-
Для миграции данных рекомендуется использовать SSL: это поможет не только шифровать данные, но и сжимать их. Подробнее в разделах документации PostgreSQL, SSL Support и Database Connection Control Functions.
Чтобы включить использование SSL, задайте нужное значение в конфигурации:
ssl = on # on, off
-
Измените уровень логирования для Write Ahead Log (WAL), чтобы добавить в него информацию, необходимую для логической репликации. Для этого установите значение
logical
для настройки wal_level.Настройку можно изменить в файле
postgresql.conf
. Найдите строку с настройкойwal_level
, раскомментируйте ее при необходимости и установите значениеlogical
:wal_level = logical # minimal, replica, or logical
-
-
Настройте аутентификацию хостов в кластере-источнике. Для этого нужно внести хосты кластера в 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
-
-
Если в кластере-источнике работает файервол, разрешите входящие соединения с хостов кластера Managed Service for PostgreSQL. Например, для Ubuntu 18:
sudo ufw allow from <адрес хоста кластера-приемника> to any port <порт>
-
Перезапустите сервис PostgreSQL, чтобы применить все сделанные настройки:
sudo systemctl restart postgresql
-
Проверьте статус сервиса 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
Создайте публикацию и подписку
Для работы логической репликации необходимо создать публикацию (группу логически реплицируемых таблиц) в кластере-источнике и подписку (описание соединения с другой базой) в кластере-приемнике.
-
В кластере-источнике создайте публикацию для всех таблиц базы данных. При переносе нескольких баз для каждой из них нужно создать отдельную публикацию.
Примечание
Для создания публикации на все таблицы потребуются права суперпользователя, а для переноса выбранных таблиц — нет. Более подробно о создании публикации см. в документации PostgreSQL.
Запрос:
CREATE PUBLICATION p_data_migration FOR ALL TABLES;
-
На хосте кластера 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;
-
Чтобы получить статус репликации, обратитесь к каталогам
pg_subscription_rel
. Общий статус репликации в кластере-приемнике можно получить черезpg_stat_subscription
, в кластере-источнике — черезpg_stat_replication
.SELECT * FROM pg_subscription_rel;
Прежде всего обратите внимание на поле
srsubstate
. Значениеr
в нем означает, что синхронизация завершилась и базы готовы к репликации.
Перенесите PostgreSQL-sequences после репликации
Чтобы завершить синхронизацию кластера-источника и кластера-приемника:
-
Переведите кластер-источник в режим
только чтение
. -
Создайте дамп с PostgreSQL-sequences в кластере-источнике:
pg_dump -h <IP-адрес или FQDN хоста-мастера кластера-источника> \ -U <имя пользователя> \ -p <порт> \ -d <имя базы данных> \ --data-only -t '*.*_seq' > /tmp/seq-data.sql
Обратите внимание на используемый паттерн
*.*_seq
. Если в переносимой базе есть не соответствующие ему sequences, то для их выгрузки укажите другой паттерн.Подробнее о паттернах см. в документации PostgreSQL.
-
Восстановите дамп с sequences в кластере-приемнике:
psql -h <IP-адрес или FQDN хоста-мастера кластера-приемника> \ -U <имя пользователя> \ -p 6432 \ -d <имя базы данных> \ < /tmp/seq-data.sql
Удалите подписку и перенесите нагрузку
-
Удалите подписку в кластере-приемнике:
DROP SUBSCRIPTION s_data_migration;
-
Перенесите нагрузку на кластер-приемник.
Перенос данных через создание и восстановление логического дампа
Создайте дамп нужной базы в кластере-источнике с помощью утилиты pg_dump
. Для восстановления дампа в кластере-приемнике используйте утилиту pg_restore
.
Примечание
Для использования утилиты pg_restore
может понадобиться расширение базы данных pg_repack
.
Этапы миграции:
- Создайте дамп переносимой базы.
- (опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп БД на нее.
- Восстановите данные из дампа в кластер-приемник.
Создайте дамп базы данных
-
Переключите базу в режим
только чтение
. -
Создайте дамп с помощью утилиты pg_dump. Для ускорения процесса запустите ее в многопоточном режиме, передав в аргументе
-j
количество доступных ядер процессора:pg_dump -h <IP-адрес или FQDN хоста-мастера кластера-источника> \ -U <имя пользователя> \ -j <количество ядер процессора> \ -Fd -d <имя базы данных> \ -f ~/db_dump
-
Упакуйте дамп в архив:
tar -cvzf db_dump.tar.gz ~/db_dump
(опционально) Создайте виртуальную машину в Yandex Cloud и загрузите дамп на нее
Переносить данные на промежуточную виртуальную машину в Compute Cloud нужно, если:
- К вашему кластеру Managed Service for PostgreSQL нет доступа из интернета.
- Ваше оборудование или соединение с кластером в Yandex Cloud недостаточно надежны.
Нужное количество оперативной памяти и ядер процессора зависит от объема переносимых данных и требуемой скорости переноса.
Чтобы подготовить виртуальную машину для восстановления дампа:
-
В консоли управления создайте новую виртуальную машину из образа Ubuntu 20.04. Параметры виртуальной машины должны зависеть от размера базы, которую вы хотите перенести. Минимальной конфигурации (1 ядро, 2 ГБ RAM, 10 ГБ дискового пространства) должно хватить для переноса базы до 1 ГБ. Чем больше переносимая база, тем больше должно быть оперативной памяти, и тем больше должно быть дискового пространства (как минимум в два раза больше, чем размер базы).
Виртуальная машина должна находиться в той же сети и зоне доступности, что и кластер PostgreSQL. Кроме того, виртуальной машине должен быть присвоен публичный IP-адрес, чтобы вы могли загрузить дамп извне Yandex Cloud.
-
Настройте apt-репозиторий PostgreSQL.
-
Установите клиент 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
-
Перенесите дамп базы данных на виртуальную машину, например, используя утилиту
scp
:scp ~/db_dump.tar.gz <имя пользователя ВМ>@<публичный адрес ВМ>:/tmp/db_dump.tar.gz
-
Распакуйте дамп:
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