[Перевод] Непрерывная репликация из старой в новую версию PostgreSQL с помощью Slony01.07.2019 15:19

c-eoj8fosll1jnolz9jlnmi1wrg.jpeg

Нативная потоковая репликация в PostgreSQL работает только между серверами с одинаковой основной версией. О логической репликации мы говорили в предыдущем посте. Мы увидели, как логическая репликация помогает перенести данные из одной версии PostgreSQL в другую. Но логическая репликация подходит только для поддерживаемых версий PostgreSQL, например, для PostgreSQL 9.4 и PostgreSQL 11. Что делать с версиями до 9.4? Использовать Slony-I.

Используйте репликацию с помощью Slony-I, чтобы перенести данные из старых баз в последнюю версию PostgreSQL. Что такое Slony и как он работает?

Это четвертый пост из нашей серии Обновление или миграция старых версий PostgreSQL в новые, где мы изучаем разные методы обновления баз данных PostgreSQL.


Slony

Slony — это реализация логической репликации на уровне приложений для PostgreSQL. Или, скорее, это сторонний инструмент репликации, который требует отдельной установки и настройки. Slony существует уже давно. Последняя версия поддерживает PostgreSQL с 8.4 по 11.

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

Кстати, Slony, если вы не догадались, — это «слоны». И у них действительно отличная память. Не случайно на логотипе PostgreSQL красуется строгий, но симпатичный слоник.


Slon

Slon — это демон, который работает на каждом узле PostgreSQL в репликации Slony-I. Эти демоны используются для обработки конфигурации и событий репликации для каждого сервера PostgreSQL. Каждый сервер PostgreSQL называется узлом. Все узлы вместе образуют кластер Slony.

Узел-издатель — это источник изменений, а узел-подписчик получает и применяет изменения от издателя.

Для настройки репликации нужно указать все реплицируемые таблицы, или набор репликации. Подписка работает для определенного набора. Изменения в реплицируемых таблицах объединяются в SYNC — группу транзакций, которые применяются вместе на подписчиках.


События

Изменения передаются от издателя в виде событий. Когда событие обрабатывается демоном Slon на удаленном узле, создается подтверждение. А еще события уведомляют узлы об изменениях конфигурации, например о добавлении или удалении новых узлов, новых подписках или изменениях DDL.

У каждого события свой уникальный идентификатор источника, порядковый номер, идентификатор транзакции для снимка на узле события, несколько аргументов и метка времени с часовым поясом.
Триггеры, записанные в PL/pgSQL, регистрируют все изменения в реплицируемых таблицах. К сожалению, пока нет надежного способа обрабатывать изменения BLOB-объектов, DDL или изменения пользователей и ролей.


slonik

Это утилита командной строки с анализатором и интерпретатором, которая принимает скрипты slonik — простого декларативного языка. Она создана, чтобы преодолевать ограничения процедурного языка. С помощью команд slonik можно настраивать или изменять репликацию в Slony, и их можно встраивать в shell-скрипты. Она принимает команды из стандартного ввода или из файлов. В примере ниже видно, как скрипт slonik передается утилите slonik и встраивается в shell-скрипты.

Скрипт, который создает начальную конфигурацию для простой схемы «ведущий-ведомый» в нашей базе данных pgbench, выглядит так: 

#!/bin/sh
slonik <<_EOF_
 cluster name = percona_pg;
 node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user';
 node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user';
 #--
 # Creates a _$(clustername), this example, _percona_pg schema
 #--
 init cluster ( id=1, comment = 'Legacy PG Node');
 #--
 # Add a list of tables being replicated to a set.
 #--
create set (id=1, origin=1, comment='pgbench');
 set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts');
 set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches');
 set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers');
 set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history');
 #--
 # Create the second node (the slave) tell the 2 nodes how to connect to
 # each other and how they should listen for events.
 #--
 store node (id=2, comment = 'Target node', event node=1);
 store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user');
 store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user');
_EOF_


Почему Slony удобно использовать для миграций?

Несмотря на преимущества внутренней логической репликации, для версий до PostgreSQL 9.4 приходится использовать это стороннее решение. Подход на основе триггеров зависит от API базы данных — обе версии должны быть совместимы для использования синтаксиса PL/pgSQL и SQL.


Как адаптировать базу данных для использования со Slony?


  • У таблиц должны быть первичные ключи. Добавьте поле serial во все таблицы без первичного ключа.
  • Изменения в OID blob не реплицируются. Если у вас есть столбцы с короткими значениями, преобразуйте их в BYTEA. Если объекты очень большие, — например, изображения, — лучше хранить данные во внешнем хранилище (скажем, S3 в облаке Amazon). Если изменить приложение слишком сложно, применяйте изменения blob на последнем этапе миграции.
  • ALTER TABLE и другие операции DDL. Slony не определяет изменения структуры таблицы. Используйте команду slonik EXECUTE SCRIPT, чтобы применить файл SQL со строками SQL или DDL ко всему кластеру репликации.


Онлайн-миграция из предыдущих версий PostgreSQL


  1. Создайте пользователя репликации с правами суперпользователя. Можно детально настроить права, но это гораздо сложнее.
  2. Создайте базу данных в месте назначения с доступом по TCP/IP.
  3. Скопируйте определения таблиц из ведущего в ведомых.
  4. Установите Slony-I. На серверах со старой версией ОС проще будет установить Slony-I из исходного кода.
  5. Определите кластер, набор таблиц и сведения о подключении к узлам в виде списка команд slonik.
  6. Запустите демон slon на каждом сервере PostgreSQL. Проверьте стандартные выходные данные или файлы логов на наличие ошибок соединения.
  7. Выполните команды подписки slonik, чтобы запустить синхронизацию.
  8. Протестируйте запросы только для чтения в новой версии Postgres.
  9. Когда все данные будут реплицированы и синхронизированы, остановите приложения и направьте их на новый сервер Postgres.
  10. Используйте uninstall node в новой версии PostgreSQL, чтобы удалить все следы репликации Slony.


Переход на предыдущие версии

Для перехода на предыдущие версии используйте ту же процедуру. Со Slony можно выполнять репликацию с любой версии и на любую версию PosgreSQL, которую поддерживает версия Slony. Минимальная поддерживаемая версия — 8.4.


Итоги

Мы в общих чертах увидели, как можно перейти на новую версию с минимальным простоем с помощью Slony. Узнайте больше на нашем вебинаре.

© Habrahabr.ru