Недавно один из наших клиентов обратился к нам с одной интересной задачей: ему нужно было перенести весь свой кластер PostgreSQL с DBaaS (Database as a Service) на дроплет в рамках DigitalOcean. Причиной их перехода с DBaaS на дроплеты была их более низкая стоимость. Эта задача оказалась довольно сложной, поскольку в документации DigitalOcean четко сказано, что “в настоящее время мы не поддерживаем миграцию баз данных из одних кластеров DigitalOcean в другие кластеры в рамках DigitalOcean”.
Короче говоря, нам нужно было переносить базу данных своими силами, и мы предоставили клиенту два варианта решения этой задачи:
Для миграции с помощью логической репликации все таблицы, которые необходимо реплицировать, должны иметь первичный или уникальный ключ.
Получить Root-права: Для подготовки базы данных к миграции и для проведения самой миграции нам нужны root-права в исходной базе данных.
Сделать базу данных общедоступной: Для миграции базы данных имя хоста или IP-адрес исходной базы данных должны быть доступны из публичного интернета. Информация о публичном подключении к базам данных DigitalOcean находится в разделе “Connection Details” на панели управления базой данных.
Разрешить удаленные подключения: Во-первых, убедитесь, что база данных разрешает все удаленные подключения. Это определяется переменной базы данных listen_addresses, которая разрешает все удаленные подключения, если ее значение равно. Чтобы проверить ее текущее значение, выполните в терминале PostgreSQL (psql) следующий запрос:
SHOW listen_addresses;
If enabled, the command line returns:
listen_addresses
-----------
*
(1 row)
Если ваш результат будет другим, вы можете разрешить удаленные подключения в вашей базе данных, выполнив следующий запрос:
ALTER SYSTEM SET listen_addresses = '*';
Мы также должны изменить ваше локальное IPv4-соединение, чтобы разрешить все входящие IP-адреса. Для этого вам нужно найти файл конфигурации pg_hba.conf с помощью следующего запросом:
SHOW hba_file;
Откройте pg_hba.conf в текстовом редакторе по вашему выбору, например, nano: nano pg_hba.conf
В разделе “IPv4 local connections” найдите и замените IP-адрес на 0.0.0.0/0, что разрешат все IPv4-адреса:
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::/0 md5
Чтобы убедиться, что логическая репликация включена, выполните следующий запрос в терминале PostgreSQL (psql):
show wal_level;
If enabled, the output returns:
wal_level
-----------
logical
(1 row)
If the output is different, enable logical replication in your database by setting wal_level to logical:
ALTER SYSTEM SET wal_level = logical;
show max_replication_slots;
Вывод будет выглядеть следующим образом:
max_replication_slots
-----------
(1 row)
Если это значение меньше, чем количество баз данных на нашем PostgreSQL сервере, измените его, выполнив следующий запрос, где use_your_number — это количество баз данных на нашем сервере:
ALTER SYSTEM SET max_replication_slots = use_your_number;
И перезагрузите сервер.
Этот метод реализуется с помощью того же самого набора шагов, который мы собираемся здесь выполнить. Его технические аспекты также аналогичны. Просто вместо первичного ключа обновления будут происходить по уникальному ключу.
После того, как данные из форка DBaaS будут синхронизированы на новую виртуальную машину на дроплете, нам нужно выполнить методы pg_dump и pg_restore для последовательностей. У вас может возникнуть вопрос: зачем нам дамп последовательности и почему мы не можем реплицировать ее с помощью логической репликации?
Логическая репликация предназначена отслеживания изменений WAL и информирования подписчиков о текущих состояниях и значениях. Было бы довольно противоречиво реплицировать последовательность, потому что текущее значение последовательности не равно значению, хранящемуся в WAL. Чтобы компенсировать это, документация PostgreSQL предлагает вручную скопировать значения последовательности или использовать для копирования такую утилиту, как pg_dump.
Исходный кластер: DBasS Digital Ocean
Место назначения: дроплеты Digital Ocean
Процесс:
habr.com
Короче говоря, нам нужно было переносить базу данных своими силами, и мы предоставили клиенту два варианта решения этой задачи:
- pg_dump
- Логическая репликация
Для миграции с помощью логической репликации все таблицы, которые необходимо реплицировать, должны иметь первичный или уникальный ключ.
Предварительные требования для миграции
Чтобы перенести существующую базу данных в кластер базы данных DigitalOcean, нам необходимо убедиться, что в исходной базе данных включена логическая репликация, получить учетные данные для подключения к исходной базы данных и отключить или обновить любые файрволы между базами данных.Получить Root-права: Для подготовки базы данных к миграции и для проведения самой миграции нам нужны root-права в исходной базе данных.
Сделать базу данных общедоступной: Для миграции базы данных имя хоста или IP-адрес исходной базы данных должны быть доступны из публичного интернета. Информация о публичном подключении к базам данных DigitalOcean находится в разделе “Connection Details” на панели управления базой данных.
Разрешить удаленные подключения: Во-первых, убедитесь, что база данных разрешает все удаленные подключения. Это определяется переменной базы данных listen_addresses, которая разрешает все удаленные подключения, если ее значение равно. Чтобы проверить ее текущее значение, выполните в терминале PostgreSQL (psql) следующий запрос:
SHOW listen_addresses;
If enabled, the command line returns:
listen_addresses
-----------
*
(1 row)
Если ваш результат будет другим, вы можете разрешить удаленные подключения в вашей базе данных, выполнив следующий запрос:
ALTER SYSTEM SET listen_addresses = '*';
Мы также должны изменить ваше локальное IPv4-соединение, чтобы разрешить все входящие IP-адреса. Для этого вам нужно найти файл конфигурации pg_hba.conf с помощью следующего запросом:
SHOW hba_file;
Откройте pg_hba.conf в текстовом редакторе по вашему выбору, например, nano: nano pg_hba.conf
В разделе “IPv4 local connections” найдите и замените IP-адрес на 0.0.0.0/0, что разрешат все IPv4-адреса:
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::/0 md5
Включение логической репликации
У большинства поставщиков облачных баз данных логическая репликация включена по умолчанию. Логическая репликация может быть не включена, если вы переносите базу данных с локального сервера. Если ваша база данных не подготовлена для логической репликации, то процесс миграции не будет работать, поскольку база данных может перемещать только ваши схемы, а не сами данные.Чтобы убедиться, что логическая репликация включена, выполните следующий запрос в терминале PostgreSQL (psql):
show wal_level;
If enabled, the output returns:
wal_level
-----------
logical
(1 row)
If the output is different, enable logical replication in your database by setting wal_level to logical:
ALTER SYSTEM SET wal_level = logical;
Изменение максимального количества слотов репликации
После включения логической репликации нам нужно убедиться, что значение max_replication_slots вашей базы данных равно или превышает количество баз данных на вашем PostgreSQL сервере. Чтобы проверить текущее значение, выполните следующий запрос в терминале PostgreSQL (psql):show max_replication_slots;
Вывод будет выглядеть следующим образом:
max_replication_slots
-----------
(1 row)
Если это значение меньше, чем количество баз данных на нашем PostgreSQL сервере, измените его, выполнив следующий запрос, где use_your_number — это количество баз данных на нашем сервере:
ALTER SYSTEM SET max_replication_slots = use_your_number;
И перезагрузите сервер.
Проблемы, с которыми мы можем столкнуться во время миграции
Когда мы реализуем логическую репликацию без первичного ключа, мы можем столкнуться с некоторыми проблемами. Существует два разных метода реализации логической репликации без столбца с первичным ключом, один из которых — с использованием уникального ключа.Этот метод реализуется с помощью того же самого набора шагов, который мы собираемся здесь выполнить. Его технические аспекты также аналогичны. Просто вместо первичного ключа обновления будут происходить по уникальному ключу.
Предостережения
- Он не поддерживает DELETE/UPDATE без репликационного идентификатора.
- Уникальный индекс нельзя использовать с репликационным идентификатором, если разрешены NULL-значения.
- Используется REPLICA IDENTITY FULL.
- Если для репликационного идентификатора не найден подходящий индекс, мы можем установить для него значение FULL. В этом случае все столбцы таблицы коллективно выступают в роли первичного ключа.
- Из-за дополнительного логирования создается огромное количество WAL.
- Этот метод может быть медленнее, чем традиционный.
Что следует учитывать
И так, нам нужно установить репликационный идентификатор FULL для таблиц, которые переносятся логически только по UNIQUE ключу, иначе DELETE/UPDATE не будет поддерживаться.После того, как данные из форка DBaaS будут синхронизированы на новую виртуальную машину на дроплете, нам нужно выполнить методы pg_dump и pg_restore для последовательностей. У вас может возникнуть вопрос: зачем нам дамп последовательности и почему мы не можем реплицировать ее с помощью логической репликации?
Логическая репликация предназначена отслеживания изменений WAL и информирования подписчиков о текущих состояниях и значениях. Было бы довольно противоречиво реплицировать последовательность, потому что текущее значение последовательности не равно значению, хранящемуся в WAL. Чтобы компенсировать это, документация PostgreSQL предлагает вручную скопировать значения последовательности или использовать для копирования такую утилиту, как pg_dump.
- Сделайте дамп последовательностей из форка БД DBaaS
- Остановите форк БД DBaaS
- Восстановите последовательности на новом дроплете
- Отключите логические подписки
Исходный кластер: DBasS Digital Ocean
Место назначения: дроплеты Digital Ocean
Процесс:
- Клиент выбрал миграцию посредством логической репликации, чтобы сократить время простоя.
- На целевой виртуальной машине мы установили дистрибутив Percona для PostgreSQL 13.7.
- Перенесли в место назначения роли из исходного кластера, т.е. DBasS.
- Сформировали список таблиц, у которых нет первичного ключа, и проинформировал их.
- Для некоторых таблиц клиент добавил первичный ключ, а для остальных таблиц сформировал уникальный ключ.
- Установили на виртуальную машину расширения, которые были в исходном кластере.
- Сформировали дамп схемы из исходного кластера, т.е. DBasS.
- Восстановили схему на месте назначения, т.е. на дроплетых.
- Скорректировали в исходном кластере и месте назначения параметры, связанные с логической репликацией, такие как max_replication_slots, max_logical_replication_workers и max_wal_senders.
- Настроили логическую репликацию, создав публикацию и подписку между исходным кластером и местом назначения.
- Как только место назначения было синхронизировано, отключили подписчиков.
- Сформировали дамп последовательностей из исходного кластера и восстановили их в месте назначения.
- Скорректировали файлы listen_address, pg_hba на месте назначения.
- Сбросили подписчиков на месте назначения.
Заключение
Как мы все знаем, PostgreSQL — это объектно-реляционная система управления базами данных с открытым исходным кодом, созданная с упором на расширяемость, скорость и целостность данных. Ее поддержка параллелизма делает ее полностью совместимой с ACID. Мы смогли реализовать миграцию данных клиентов с DBasS на дроплеты, используя одну из замечательных фич PostgreSQL, то есть логическую репликацию. Мы также смогли сформировать дамп последовательностей из исходного кластера и восстановить их на месте назначения.
Миграция PostgreSQL с DBaaS на дроплет Digital Ocean
Недавно один из наших клиентов обратился к нам с одной интересной задачей: ему нужно было перенести весь свой кластер PostgreSQL с DBaaS (Database as a Service) на дроплет в рамках DigitalOcean....
habr.com