Рекомендации по простой миграции в База данных Azure для PostgreSQL

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

Проверка предварительной подготовки

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

Конфигурация гибкого сервера целевого объекта

Во время начальной базовой копии данных на целевом объекте выполняются несколько инструкций вставки, которые создают журналы перед записью (WALs). Пока эти WA-адреса не архивируются, журналы используют хранилище в целевом объекте и хранилище, необходимое для базы данных.

Чтобы вычислить число, войдите в исходный экземпляр и выполните следующую команду для переноса всех баз данных:

SELECT pg_size_pretty( pg_database_size('dbname') );

Рекомендуется выделить достаточное хранилище на гибком сервере, эквивалентное 1,25 раза или 25 % больше хранилища, чем то, что используется для выходных данных предыдущей команды. Вы также можете использовать автоматическое увеличение хранилища.

Краткое руководство по созданию экземпляра База данных Azure для PostgreSQL — гибкий сервер является отличным местом для начала. Дополнительные сведения о каждой конфигурации сервера см. в разделе "Параметры вычислений и хранилища" в База данных Azure для PostgreSQL — гибкий сервер.

Временная шкала миграции

Каждая миграция имеет максимальное время существования семи дней (168 часов) после начала, и время ожидания истекает через семь дней. Вы можете завершить миграцию и переход приложения после проверки данных и всех проверок, чтобы избежать истечения времени ожидания миграции. После завершения начальной базовой копии окно отрезки длится три дня (72 часа) до истечения времени ожидания. В автономных миграциях приложения должны прекратить запись в базу данных, чтобы предотвратить потерю данных. Аналогичным образом, для миграции через Интернет трафик сохраняется низко на протяжении всей миграции.

Большинство непроизводственных серверов (разработки, UAT, тестирования и промежуточного хранения) переносятся с помощью автономных миграций. Так как эти серверы имеют меньше данных, чем рабочие серверы, миграция выполняется быстро. Для миграции рабочего сервера необходимо знать время, необходимое для завершения миграции, чтобы заранее планировать ее.

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

Для вычисления общего времени простоя для выполнения миграции рабочего сервера рассматриваются следующие этапы.

• Миграция PITR. Лучший способ получить хорошую оценку времени, необходимого для миграции сервера рабочей базы данных, заключается в том, чтобы выполнить восстановление на определенный момент времени (PITR) рабочего сервера и запустить автономную миграцию на этом восстановленном сервере.

• Миграция буфера. После завершения предыдущего шага можно запланировать фактическую миграцию рабочей среды в течение определенного периода времени, когда трафик приложения невысок. Эта миграция может быть запланирована в тот же день или, вероятно, неделю. К этому времени размер исходного сервера может увеличиться. Обновите предполагаемое время миграции для рабочего сервера на основе объема этого увеличения. Если увеличение значительно, рассмотрите возможность выполнения другого теста с помощью сервера PITR. Но для большинства серверов увеличение размера не должно быть достаточно значительным.

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

  • Счетчик строк для всех таблиц, участвующих в миграции.

  • Счетчики сопоставления для всех объектов базы данных (таблицы, последовательности, расширения, процедуры и индексы).

  • Сравнение максимальных или минимальных идентификаторов ключевых столбцов, связанных с приложением.

    Примечание.

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

• Миграция параметров сервера: все пользовательские параметры сервера, правила брандмауэра (если применимо), теги и оповещения должны быть скопированы вручную из исходного экземпляра в целевой объект.

• Изменение строка подключения: приложение должно изменить строка подключения на гибкий сервер после успешной проверки. Это действие координируется с командой приложений, чтобы изменить все ссылки на строка подключения, указывающие на исходный экземпляр. На гибком сервере параметр пользователя можно использовать в формате user=username в строка подключения.

Например: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

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

Тестирование скорости миграции

В следующей таблице показано время, необходимое для выполнения миграции для баз данных различных размеров с помощью службы миграции. Миграция была выполнена с помощью гибкого сервера с номером SKU Standard_D4ds_v4 (4 ядра, 16 ГБ памяти).

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

Повышение скорости миграции: параллельная миграция таблиц

Рекомендуется использовать мощный номер SKU для целевого объекта, так как служба миграции PostgreSQL выходит из контейнера на гибком сервере. Мощный номер SKU позволяет параллельно переносить больше таблиц. Вы можете выполнить масштабирование номера SKU обратно в предпочитаемую конфигурацию после миграции. В этом разделе содержатся шаги по повышению скорости миграции, если распределение данных между таблицами должно быть более сбалансированным или более мощным SKU не влияет на скорость миграции.

Если распределение данных в источнике сильно смещено, при этом большинство данных, присутствующих в одной таблице, выделенные вычислительные ресурсы для миграции должны быть полностью использованы, что создает узкие места. Таким образом, разделение больших таблиц на небольшие блоки, которые затем переносятся параллельно. Эта функция применяется к таблицам размером более 20 ГБ. Разделение таблицы на небольшие блоки возможно, если выполняется одно из следующих условий:

• Таблица должна иметь столбец с простым (не составным) первичным ключом или уникальным индексом типа smallintили integer big int.

  Примечание.

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

• Если в таблице нет простого первичного ключа или уникального индекса типа smallintили integer big int имеется столбец, соответствующий критериям типа данных, столбец можно преобразовать в уникальный индекс с помощью следующей команды. Для этой команды не требуется блокировка таблицы.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• Если в таблице нет smallintinteger первичного ключа или big int уникального индекса или любого столбца, соответствующего критериям типа данных, можно добавить такой столбец с помощью ALTER и удалить его после миграции. ALTER Для выполнения команды требуется блокировка таблицы.

      alter table <table name> add column <column name> big serial unique;
  

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

Принцип работы

• Служба миграции ищет размер таблицы, чтобы проверить, превышает ли она 20 ГБ.
• Если размер превышает 20 ГБ, и существует smallintinteger big int первичный ключ или уникальный индекс, таблица разбивается на несколько частей, и каждая часть переносится параллельно.

В итоге служба миграции PostgreSQL переносит таблицу в параллельных потоках и сокращает время миграции, если:

• В таблице есть столбец с простым первичным ключом или уникальным индексом типа smallintinteger илиbig int.
• Размер таблицы превышает 20 ГБ.
• Номер SKU, используемый, имеет неактивные ядра, которые можно использовать для параллельного переноса таблицы.

Вакуумный blat в базе данных PostgreSQL

Со временем при добавлении, обновлении и удалении данных PostgreSQL может накапливать мертвые строки и свободное место в хранилище. Это может привести к увеличению требований к хранилищу и снижению производительности запросов. Очистка является важной задачей обслуживания, которая помогает восстановить это пустое пространство и обеспечивает эффективную работу базы данных. Вакуумирование устраняет такие проблемы, как мертвые строки и большие двоичные объекты, чтобы обеспечить эффективное использование хранилища. Это также помогает обеспечить более быструю миграцию, так как время миграции является функцией размера базы данных.

PostgreSQL предоставляет VACUUM команду для освобождения хранилища, занятого мертвыми строками. Этот ANALYZE параметр также собирает статистику для дальнейшего оптимизации планирования запросов. Для таблиц с большим действием VACUUM записи процесс может быть более агрессивным с помощью VACUUM FULL, но для выполнения требуется больше времени.

• Стандартный вакуум

  VACUUM your_table;
  

• Вакуум с анализом

  VACUUM ANALYZE your_table;
  

• Агрессивный вакуум для тяжелых таблиц записи

  VACUUM FULL your_table;
  

В этом примере замените your_table фактическим именем таблицы. Команда VACUUM без FULL эффективного восстановления пространства, а оптимизирует VACUUM ANALYZE планирование запросов. Этот VACUUM FULL вариант следует использовать разумно из-за его более сильного влияния на производительность.

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

• Вакуум больших объектов

  VACUUMLO;
  

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

Особое внимание

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

Миграция по сети

Миграция через Интернет использует pgcopydb, а некоторые из логического декодирования применяются . Мы также рекомендуем использовать первичный ключ во всех таблицах базы данных, которая проходит миграцию через Интернет. Если первичный ключ отсутствует, недостаток приводит к отражению только insert операций во время миграции, исключая обновления или удаления. Добавьте временный первичный ключ в соответствующие таблицы, прежде чем продолжить миграцию через Интернет.

Альтернативой является использование ALTER TABLE команды, в которой действие — РЕПЛИКА IDENTIY с параметром FULL . Параметр FULL записывает старые значения всех столбцов в строке, чтобы даже в отсутствие первичного ключа все операции CRUD отражаются на целевом объекте во время онлайн-миграции. Если ни один из этих вариантов не работает, выполните автономную миграцию в качестве альтернативы.

База данных с расширением postgres_fdw

Модуль postgres_fdw предоставляет внешние оболочки данных postgres_fdw, которые можно использовать для доступа к данным, хранящимся на внешних серверах PostgreSQL. Если база данных использует это расширение, необходимо выполнить следующие действия, чтобы обеспечить успешную миграцию.

1. Временно удалите (отменить связь) внешнего оболочку данных в исходном экземпляре.
2. Выполните миграцию остальных данных с помощью службы миграции.
3. Восстановите внешние роли оболочки данных, пользователя и ссылки на целевой объект после миграции.

База данных с расширением postGIS

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

Очистка подключения к базе данных

Иногда при запуске миграции может возникнуть эта ошибка:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

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

Связанный контент

• Служба миграции
• Известные проблемы и ограничения