Как выполнить миграцию данных: лучшие практики и рекомендации на примере Greenplum. Особенности и принципы работы утилит gpbackup, gprestore и gpcopy.
Миграция данных из Greenplum на 7 с утилитами gpbackup и gprestore
Независимо от причины миграции данных из прикладной системы или корпоративного хранилища данных на новую технологию, эта процедура всегда остается болезненной. Прежде чем выбирать новое решение и начинать процесс перехода, следует оценить связанные с этим риски. В частности, данные из прежних СУБД можно перенести в новые, но нельзя синхронизировать. Если во время миграции данных записываются новые данные, необходимо выполнить обратную засыпку (backfilling), т.е. заполнение данных за прошлые периоды. Поэтому лучше выполнять миграцию данных, предварительно приостановив операции записи. Иначе производительность сервиса снизится, а миграция данных замедлится. Однако, для производственных систем длительный простой может быть недопустим. В этом случае следует тщательно выбирать наиболее подходящий паттерн развертывания новой платформы данных, о чем мы писали здесь.
Хотя реализации этих паттернов различаются, их все можно разделить на 2 основные стратегии: «большой взрыв» и «ручеек». Первая стратегия переносит все связанные данные в течение заданного временного окна. Это обходится дешевле, быстрее и не очень сложно технически. Недостатком этой стратегии является необходимость простоя системы на протяжении всей миграции. Также существует риск потери данных, если заранее не выполнить их резервную копию. Стратегия ручеек выполняет миграцию данных поэтапно. Во время миграции старая и новая системы работают одновременно, поэтому простоев нет, а значит, меньше риска потери данных. Однако, такая миграция более сложна и требует тщательного планирования и времени для правильной реализации. Также необходимо обеспечить синхронизацию старой и новой СУБД.
Эти советы остаются актуальными, даже если речь идет о плановом обновлении, т.е. переводе СУБД на более свежий релиз. Обычно для этого в наборе инструментов СУБД есть соответствующие утилиты. Например, для Greenplum это gpupgrade и gpcopy. Однако, выполнить обновление VMware Greenplum до версии 7.0.0 с помощью утилиты gpupgrade не получится. Чтобы обновить Greenplum с версии 6 до версии 7, следует переместить данные с помощью утилит резервного копирования и восстановления gpbackup/gprestore и утилиты копирования данных gpcopy.
Процесс резервного копирования выглядит так:
- сперва надо запустить утилиту gpbackupдля резервного копирования данных из кластера Greenplum 6 во внешнее место хранения данных, например, смонтированные каталоги, или облачное хранилище;
- далее следует инициализировать кластер Greenplum 7 на целевом оборудовании с помощью команды .gpinitsystem;
- перед восстановлением резервной копии надо установить все внешние модули, используемые в Greenplum 6, в 7-ю версию СУБД, например, расширения MADlib или PostGIS. Если версии внешних модулей несовместимы, придется исключать таблицы, которые ссылаются на них, при восстановлении резервной копии данных из 6-ой версии Greenplum в 7-ю.
- Наконец, следует запустить утилиту gprestore для восстановления данных в кластере Greenplum 7 из внешнего хранилища.
Перед фактическим запуском резервного копирования, с помощью утилиты gpbackup следует создать резервную копию метаданных исходной БД (—metadata-only). При выполнении этого действия в файл журнала gprestore будут записаны сообщения об ошибках, которые рекомендуется исправить в исходной БД до копирования. Если VMware Greenplum 7 устанавливается на то же оборудование, где работает версия 6, нужно убедиться в наличии свободного пространства. Обычно для миграции с помощью утилит gpbackup и gprestore требуется в 5 раз больше пространства, чем размер исходного набора данных, поскольку создается две полные копии основного и зеркального наборов данных, а также исходные данные резервной копии в формате ASCII. Для резервных данных ASCII потребуется больше дискового пространства, чем для исходных данных, которые могут храниться в сжатом двоичном формате.
При восстановлении UDF-функций общий объектный файл должен находиться в расположении, указанном в команде CREATE FUNCTION SQL, и он подлежит перекомпиляции в Greenplum 7. Это относится к пользовательским функциям, пользовательским типам и любым другим объектам, использующим пользовательские функции, например агрегатам, созданным с помощью команды CREATE AGGREGATE.
Утилита резервного копирования gpbackup сохраняет политику распространения и ключ распределения для каждой таблицы в резервной копии, чтобы данные можно было восстановить в тот же сегмент. Если ключ распределения таблицы в Greenplum 6 несовместим с 7-ой версией, утилита резервного копирования gprestore не сможет восстановить таблицу в правильный сегмент. Это может произойти, если ключ распределения в более старой версии Greenplum содержит столбцы с типами данных, недопустимыми для использования в ключах распределения в более свежем релизе. Также подобная ситуация может случиться, если представление данных для типов данных изменилось или Greenplum 7 не может сгенерировать то же самое хэш-значение для ключа распределения. Эти ошибки надо исправить, изменив ключи распределения в таблицах исходной БД, прежде чем создавать резервную копию.
Использование gpcopy
Кроме вышерассмотренных утилит, также для миграции данных между разными БД Greenplum можно использовать CLI-инструмент gpcopy. Она может быстро копировать метаданные и данные, причем как все содержимое базы данных или только выбранные таблицы. С помощью gpcopy можно переносить данные между разными версиями Greenplum. В частности, gpcopy поддерживает миграцию данных из Greenplum 4.23.6 или позднее в версии 5.9.x и 6.x. Причем gpcopy может переносить данные между СУБД Greenplum, где исходная и целевая системы настроены на разное количество экземпляров сегментов. При этом можно изменять данные исходной таблицы во время копирования данных, поскольку исходные таблицы не блокируются. Из-за этого потенциально может произойти рассинхрон между исходной и целовой базой. Чтобы избежать этого, рекомендуется запускать процедуру миграции данных тогда, когда они не будут подвергаться изменениям.
Полная передача базы данных включает в себя схему базы данных, данные таблицы, индексы, представления, роли, определяемые пользователем функции, очереди ресурсов и группы ресурсов. Если скопированная таблица или база данных не существует в целевой системе, утилита gpcopy создает ее автоматически вместе с необходимыми индексами.
Для этого файлы конфигурации, включая postgresql.conf и pg_hba.conf, должны быть перенесены администратором вручную. А расширения, установленные в исходной базе с помощью gppkg, надо также установить в целевой БД. Утилита gpcopy включает опцию —truncate-source-after, помогающую перенести данные из одной БД VMware Greenplum в другую на том же оборудовании, требуя минимального свободного места.
Чтобы запустить миграцию данных с gpcopy , исходная и целевая БД Greenplum должны существовать, иметь сетевой доступ между всеми хостами, а также иметь хосты координатора и основного сегмента в обеих системах. При копировании данных между Greenplum разных версий, в каждой СУБД надо установить утилиту gpcopy локально. А поскольку эта утилита зависит от утилит pg_dump, pg_dumpall и psql, их тоже надо установить. Впрочем, в большинстве случаев gpcopy запускается из хост-системы Greenplum, поэтому зависимости выполняются автоматически. Если нужно запустить gpcopy на удаленном сервере, надо скопировать двоичный файл gpcopy и установите совместимый пакет клиентов Greenplum.
Отметим следующие ограничения gpcopy:
- Утилита копирует данные только из пользовательских баз, а системные базы postgres, template0и template1 перенести невозможно;
- максимальный размер строки для копирования ограничен 1 ГБ;
- gpcopy не поддерживает проверку распределения данных при копировании многораздельной внешней таблицы, или если конечная таблица определена с политикой распределения, отличной от корневой многораздельной таблицы. Обойти это можно, запустив gpcopy с опцией —no-distribution-check, чтобы отключить проверку распределения данных. Однако, при этом следует убедиться, в наличии резервной копии целевой базы данных и в том, что политики распределения копируемых таблиц совпадают в исходной и целевой БД. Копирование данных в экземпляры сегментов с неправильным распределением данных может привести к неверным результатам запроса и повреждению базы данных.
Если в файле pg_hba.conf указана аутентификация по паролю, утилита gpcopy может использовать значение переменной среды PGPASSWORD или PGPASSFILE для получения пароля подключения для исходного и/или целевого кластера Greenplum. Когда в pg_hba.conf указан тип соединения SSL/TLS, можно настроить gpcopy для инициирования зашифрованного соединения как с источником, так и с пунктом назначения Greenplum. В этом сценарии gpcopy является клиентом SSL, а исходный и целевой кластеры Greenplum — серверами SSL. Утилита gpcopy поддерживает SSL-шифрование при подключении к Greenplum, аналогично PostgreSQL.
Также gpcopy поддерживает использование шифрования SSL/TLS во время передачи данных из источника в целевой кластер Greenplum. При этом TLS-соединение устанавливается между gpcopy_helper, работающим в исходном кластере Greenplum, и gpcopy_helper, работающим в целевом кластере Greenplum, а копируемые данные отправляются по этому соединению.
Чтобы избежать копирования изменений данных при работе gpcopy, можно выполнить эту операцию в моментальном снимке транзакции, указав это утилите. Это возможно только для Greenplum версии 6 или 7, но не 5.x.
Степень параллелизма при запуске gpcopy определяется опцией —jobs. Этот параметр контролирует количество процессов, gpcopy выполняемых параллельно. По умолчанию их количество равно 4, но может меняться от 1 до 64512. Значение этого параметра, равное n, создает 2*n+1 соединения с базой данных. Например, значение —jobs по умолчанию, равное 4, создает 9 подключений. Копирование многораздельных таблиц по умолчанию выполняется параллельно. Значение —jobs может влиять на количество конечных разделов, копируемых параллельно. Увеличение значения —jobs может повысить производительность в зависимости количества хостов и сегментов Greenplum, количество конечных разделов и объем передаваемых данных. При увеличении параметра –jobs важно убедиться, что СУБД Greenplum настроены с достаточным максимальным значением одновременного подключения для gpcopy и других соединения, например, пользовательских. Для этого надо проверить значение параметра конфигурации сервера СУБД max_connections.
По умолчанию gpcopy не проверяет передаваемые данные. Можно запросить проверку, используя опцию —validate=*type*. Это надо сделать обязательно, если включена опция —truncate-source-after. Тип проверки (*type*) может быть одним из следующих:
- count— сравнивает количество строк в исходной и целевой таблицах;
- md5xor — проверяется путем выбора всех строк исходной и целевой таблиц, преобразования всех столбцов в строке в текст и последующего вычисления значения md5 для каждой строки. Утилита gpcopy затем выполняет XOR над значениями MD5, чтобы убедиться, что все строки таблицы были успешно скопированы.
Не стоит использовать опцию —append ни с одним из вариантов проверки, т.к. команда не будет выполнена из-за разного количества строк в исходной и целевой таблицах.
Когда утилита gpcopy обнаруживает ошибки и завершает работу или отменяется пользователем, текущие операции копирования таблиц в целевой базе данных откатываются. Завершенные операции копирования не откатываются. Если в процессе копирования таблицы возникает ошибка или проверка таблицы не удалась, gpcopy продолжает копирование других указанных таблиц. После завершения работы gpcopy отображается список таблиц, в которых произошли ошибки или проверка не удалась, а также отображается сама команда gpcopy, чтобы повторить попытку копирования неудавшихся таблиц.
Утилита gpcopy регистрирует сообщения в файле журнала gpcopy_date.log в каталоге ~/gpAdminLogs на хосте координатора. Если несколько операций копирования команд были запущены в один и тот же день, утилита gpcopy добавит сообщения в файл журнала этого дня.
Читайте в нашей новой статье, как повысить эффективность утилизации диска в Greenplum с расширением Diskquota.
Освойте администрирование и эксплуатацию ClickHouse и Greenplum с Arenadata DB для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://www.techtarget.com/searchstorage/definition/data-migration
- https://www.alibabacloud.com/help/en/analyticdb-for-postgresql/user-guide/migrate-data-from-a-self-managed-greenplum-cluster-to-an-analyticdb-for-postgresql-instance
- https://docs.vmware.com/en/VMware-Greenplum-Data-Copy-Utility/2.6/greenplum-copy/gpcopy-migrate.html
- https://docs.vmware.com/en/VMware-Greenplum/7/greenplum-database/install_guide-upgrading_6_to_7.html
