Перейти к основному содержимому

Уровень 2.0

Предусловие:

  • Изучены материалы лекции 7 «Логическая репликация»

В этом задании вы узнаете:

  • О причинах миграции в СУБД Pangolin
  • Способах миграции из СУБД Pangolin или PostgreSQL
  • Подходах к миграции из других СУБД

Миграция в Pangolin​

Миграция данных в СУБД Pangolin может выполняться по разным причинам и во многом зависит от источника данных.

Можно выделить несколько случаев.

Во-первых, миграция необходима для обновления с одной мажорной (основной) версии Pangolin на другую.

Различные мажорные версии Pangolin не являются двоично совместимыми. В этом случае недостаточно обновления исполняемых файлов — также требуется преобразование данных из одного формата в другой.

Процедура обновления Pangolin рассматривается в лекции «Обновление Pangolin».

Во-вторых, миграция требуется при переносе кластера баз данных Pangolin на несовместимую платформу. Например, с одной операционной системы на другую.

В-третьих, миграция данных необходима при переходе с оригинальной версии PostgreSQL на Pangolin. В этом случае также отсутствует двоичная совместимость СУБД.

И наконец, миграция требуется для перехода на Pangolin с других СУБД, не являющихся версиями PostgreSQL.

Миграция с Pangolin/PostgreSQL​

Сначала рассмотрим миграцию данных в Pangolin. Она выполняется, когда источником данных также является кластер Pangolin или PostgreSQL.

В этом случае миграцию можно выполнить с использованием:

  • Утилит логического резервного копирования и восстановления (pg_dumpall, pg_dump и pg_restore)
  • Утилиты pg_upgrade
  • Логической репликации

1. Миграция путем логического резервного копирования и восстановления

Перенос данных между двумя кластерами Pangolin можно выполнить путем создания логической резервной копии с исходного кластера и ее восстановления на целевом кластере.

Вспомните из Лекции 3 «Логическое резервное копирование», что для создания логической копии всех баз данных и глобальных объектов кластера используется утилита pg_dumpall, а для восстановления данных из нее достаточно psql.

При этом логической копией является набор команд SQL по созданию объектов кластера и баз данных, а также наполнения их данными.

Логическое резервное копирование можно использовать не только для обновления мажорной версии Pangolin, но также для смены платформы или кодировки баз данных.

Однако, перенос больших объемов данных таким способом может занимать продолжительное время. Сначала необходимо создать логическую копию, просканировав все таблицы. Затем — восстановить из нее данные с пересозданием всех необходимых индексов.

При этом в pg_dumpall параллельная выгрузка не поддерживается, также как в psql не поддерживается параллельное восстановление данных.

Однако, в pg_dumpall можно выгружать только глобальные объекты (опция -g), тогда каждую базу данных можно выгружать отдельно с помощью pg_dump. В этом случае при использовании формата directory (опция -F d) выгрузка может выполняться с использованием нескольких потоков (опция -j число_потоков).

Восстановление данных из такой копии выполняется с использованием утилиты pg_restore и также возможно в параллельном режиме (опция -j число_потоков).

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

До выполнения восстановления данных необходимо позаботиться о создании на узле целевого экземпляра каталогов для табличных пространств, используемых в исходном кластере баз данных, а также об установке необходимых расширений (подробнее в лекции 1 «Управление расширениями» курса DBA3). После выполнения восстановления при необходимости выполняется обновление расширений на целевом экземпляре.

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

Таким же образом логическое резервное копирование можно использовать для переноса данных с PostgreSQL на Pangolin.

2. Миграция с использованием утилиты pg_upgrade

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

Однако, в случае обновления мажорной версии Pangolin не требуется выполнение переноса всех данных в виде логической копии.

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

Поэтому достаточно выполнить перенос таблиц системного каталога с сохранением в неизменном виде основной части файлов данных.

Для этого предназначена утилита pg_upgrade.

Для переноса таблиц системного каталога утилита pg_upgrade использует те же утилиты pg_dump, pg_dumpall и pg_restore. Остальные файлы данных pg_upgrade либо копирует как есть, либо создает жесткие ссылки на них.

Для применения pg_upgrade кластеры Pangolin должны быть развернуты на совместимых платформах, а также быть совместимы по кодировке и локалям.

Помимо этого, pg_upgrade не поддерживает перенос данных кластера, если в одной из его баз данных есть таблицы со столбцами системных типов reg*, за исключением типов regclass, regrole и regtype.

Для проверки возможности переноса данных в pg_upgrade предусмотрена опция --check. Например, команда проверки возможности переноса данных между двумя кластерами Pangolin разных версий может выглядеть так:

[postgres@ServerName ~]$  /usr/pangolin-major.minor/bin/pg_upgrade --check -b /usr/pangolin-{pangolin_version}/bin/ -B /usr/pangolin-major.minor/bin -d /pgdata/{pangolin_version}/data/ -D /pgdata/major.minor/data/

С использованием ключей -b и -B указываются каталоги с исполняемыми файлами старого и нового экземпляра Pangolin соответственно, а с использованием ключей -d и -D — соответствующие каталоги с конфигурацией.

Если окажется, например, что в новой версии Pangolin изменилось двоичное представление какого-либо типа данных, то pg_upgrade предупредит об этом. В этом случае перенос с использованием pg_upgrade будет возможен только после устранения использования "проблемного" типа данных в исходном кластере.

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

[postgres@ServerName ~]$  /usr/pangolin-major.minor/bin/pg_upgrade --link -b /usr/pangolin-\{pangolin_version\}/bin/ -B /usr/pangolin-major.minor/bin -d /pgdata/\{pangolin_version\}/data/ -D /pgdata/major.minor/data/

Для переноса данных использованы те же ключи -b, -B, -d и -D, а также ключ --link, который дает указание по созданию жестких ссылок на старые файлы данных вместо их копирования на новый кластер. Использование ключа --link позволяет значительно сократить время миграции.

На время переноса данных с использованием pg_upgrade оба экземпляра Pangolin должны быть остановлены.

После выполнения миграции так же, как и в случае логического резервного копирования, целесообразно выполнить команду ANALYZE и обновить расширения на целевом экземпляре.

Стоит отметить, что оригинальная версия утилиты pg_upgrade была доработана до возможности миграции данных в Pangolin.

При этом миграция с использованием доработанной утилиты pg_upgrade также возможна с оригинальной версии PostgreSQL Для переноса данных с PostgreSQL на Pangolin в pg_upgrade необходимо использовать опцию --old-original.

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

3. Миграция путем логической репликации

Также миграция данных при обновлении Pangolin может быть выполнена с использованием логической репликации (читайте лекцию «Логическая репликация»).

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

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

И наконец, на целевом экземпляре создать соответствующие подписки с синхронизацией данных.

После переноса данных созданные публикации и подписки могут быть удалены.

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

Таким же образом логическая репликация может быть использована для переноса данных с PostgreSQL на Pangolin.

Миграция с других СУБД​

Процесс перехода на Pangolin с других СУБД, отличных от Pangolin или PostgreSQL, во многом зависит от особенностей их реализации.

Так или иначе для выполнения перехода в общем случае требуется решить ряд задач, которые условно можно разделить на две категории:

  • Перенос данных
  • Перенос объектов

Задача переноса данных, как правило, решается значительно проще, чем перенос объектов, поскольку большинство СУБД поддерживают язык SQL.

Перенос данных​

Если СУБД, с которой требуется выполнить перенос данных, поддерживает язык SQL, то данные могут быть выгружены в виде набора SQL-команд.

Для выгрузки могут использоваться программные средства СУБД-источника, схожие по функциональности с утилитами pg_dump и pg_dumpall. Загрузка данных в Pangolin выполняется путем проигрывания SQL-команд в psql.

Такой способ является наиболее универсальным, однако имеет существенные недостатки.

Во-первых, диалекты языка SQL в различных СУБД могут отличаться. В связи с этим, прямое проигрывание SQL-команд в Pangolin может оказаться невозможным и потребуется предварительное преобразование данных.

Во-вторых, перенос данных таким способом может выполняться неприемлемо долго.

Другой способ — механизм оберток сторонних данных (Foreign Data Wrappers, FDW), реализованный в Pangolin.

Вспомним из курса DBA1 «Введение в администрирование Pangolin», что обертки сторонних данных позволяют обращаться к внешним источникам данных так, как будто они хранятся в таблицах базы данных кластера Pangolin.

Существует большое количество готовых оберток для различных внешних источников данных (не только реляционных СУБД), например:

  • oracle_fdw — обертка для СУБД Oracle
  • tds_fdw — обертка для СУБД MS SQL Server и Sybase
  • mysql_fdw — обертка для СУБД MySQL
  • odbc_fdw — обертка для доступа к данным через интерфейс ODBC
  • jdbc_fdw — обертка для доступа к данным через интерфейс JDBC
  • clickhouse_fdw — обертка для колоночной СУБД ClickHouse
  • mongo_fdw — обертка для документоориентированной СУБД MongoDB
  • file_fdw— обертка для файлов в формате команды COPY

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

Перенос объектов​

Перенос объектов является более сложной задачей из-за различий в функциональности разных СУБД.

В частности, СУБД обычно имеет свой процедурный язык. Если в PostgreSQL и Pangolin — это язык PL/PgSQL, то в Oracle — PL/PSQL, а в MS SQL Server — T-SQL.

По этой причине перенос таких объектов как функции, процедуры и триггеры является плохо автоматизируемой задачей.

Тем не менее, перенос объектов, предусмотренных стандартом SQL, таких как таблицы, индексы, представления и последовательности, относительно прост и может быть автоматизирован.

Каждый конкретный случай миграции необходимо рассматривать отдельно.

Существуют сторонние средства, в некоторой степени автоматизирующие процесс миграции в PostgreSQL и Pangolin.

В качестве примера можно привести утилиту pgloader, предназначенную для переноса данных из СУБД MS SQL Server, MySQL и SQLite, а также утилиту ora2pg, предназначенную для переноса данных из СУБД Oracle.

Подведем итоги​

  • Миграция данных в Pangolin может выполняться по разным причинам: обновление мажорной версии Pangolin, переход на другую платформу, переход с PostgreSQL, переход с других СУБД
  • Миграция при обновлении Pangolin или переходе с PostgreSQL может быть выполнена путем логического резервного копирования, применения утилиты pg_upgrade или логической репликации
  • Процесс миграции с других СУБД в Pangolin зависит от каждого отдельно взятого случая

Самопроверка​

Вопрос 1

Какие из перечисленных средств не требуют совместимости форматов файлов данных исходного и целевого экземпляров Pangolin? Выберите все правильные варианты:

Вопрос 2

Какие ограничения применения имеет утилита pg_upgrade? Выберите все правильные варианты:

Вопрос 3

Какие из перечисленных средств могут быть использованы для переноса данных с СУБД MS SQL Server в СУБД PostgreSQL/Pangolin? Выберите все правильные варианты:

Вопрос 4

Какие из перечисленных объектов обычно представляют наибольшую сложность для миграции в СУБД Pangolin c СУБД, отличных от Pangolin и PostgreSQL?