Поделиться через


Известные проблемы и ограничения, связанные с миграцией по сети из PostgreSQL в Базу данных Azure для PostgreSQL

Внимание

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

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

Настройка миграции в подключенном режиме

  • На исходном сервере должен использоваться PostgreSQL версии 9.4, 9.5, 9.6, 10 или 11. Дополнительные сведения см. в статье Поддерживаемые версии базы данных PostgreSQL.

  • Поддерживаются только миграции на ту же или более позднюю версию. Например, миграция PostgreSQL 9.5 на базу данных Azure для PostgreSQL 9.6 или 10 поддерживается. Миграция с PostgreSQL 11 на PostgreSQL 9.6 не поддерживается.

  • Чтобы включить логическую репликацию в исходном файле PostgreSQL postgresql.conf, задайте следующие параметры:

    • wal_level. Задайте значение "логический".
    • max_replication_slots. Задайте, как минимум, максимальное количество баз данных для миграции. Если вы хотите выполнить миграцию четырех баз данных, заданное значение должно быть, как минимум, 4.
    • max_wal_senders: задайте число параллельно работающих баз данных. Мы рекомендуем использовать значение 10.
  • Добавьте IP-адрес агента DMS в исходный файл PostgreSQL pg_hba.conf.

    1. Запишите IP-адрес DMS после того, как завершите подготовку экземпляра Azure Database Migration Service.

    2. Добавьте IP-адрес в файл pg_hba.conf :

          host    all    172.16.136.18/10    md5
          host    replication postgres    172.16.136.18/10     md5
      
  • Пользователю должна быть присвоена роль РЕПЛИКАЦИИ на сервере, на котором размещается база данных-источник.

  • Схемы исходной и целевой баз данных должны совпадать.

Ограничения размера

  • Из PostgreSQL в базу данных Azure для PostgreSQL с помощью одной службы DMS можно выполнить миграцию до 1 ТБ данных.
  • DMS позволяет пользователям выбирать таблицы в базе данных, которую они хотят перенести. Снимок экрана: экран D M S, на котором показан параметр выбора таблиц.

За кулисами есть команда pg_dump , которая используется для дампа выбранных таблиц с помощью одного из следующих параметров:

  • -T , чтобы включить имена таблиц, выбранные в пользовательском интерфейсе
  • -t , чтобы исключить имена таблиц, не выбранные пользователем

Существует максимальное ограничение в 7500 символов, которые могут быть включены в состав команды pg_dump после параметра -t или -T . Команда pg_dump использует количество символов для выбранных или неизбранных таблиц, в зависимости от того, что ниже. Если количество символов для выбранных и невыбранных таблиц превышает 7500, команда pg_dump завершается ошибкой.

В предыдущем примере команда pg_dump будет:

pg_dump -h hostname -u username -d databasename -T "\"public\".\"table_1\"" -T "\"public\".\"table_2\""

В предыдущей команде число символов равно 55 (включает в себя двойные кавычки, пробелы, -T и косую черту).

Ограничения типа данных

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

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

Ограничения при миграции по сети из AWS RDS PostgreSQL

При попытке выполнить миграцию по сети из PostgreSQL реляционной базы данных (RDS) в Amazon Web Service (AWS) на базу данных Azure для PostgreSQL могут возникать следующие ошибки.

  • Ошибка. Значение по умолчанию столбца "{column}" в таблице "{table}" в базе данных "{database}" отличается на исходных и целевых серверах. It's '{value on source}' on source and '{value on target}' on target" (Значение по умолчанию столбца "{столбец}" в таблице "{таблица}" в базе данных "{база данных}" на исходном сервере не совпадает с таким же параметром на целевом сервере. Это значение "{значение на исходном сервере}" на исходном сервере и "{значение на целевом сервере}" на целевом).

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

    Обходное решение. Убедитесь, что схема в целевом объекте соответствует схеме источника. Дополнительные сведения о миграции схемы см. в разделе Документация по миграции по сети базы данных Azure для PostgreSQL.

  • Ошибка: целевая база данных "{database}" имеет таблицы "{число таблиц}", а исходная база данных "{database}" имеет "{число таблиц}". The number of tables on source and target databases should match" (Количество таблиц в целевой базе данных "{база данных}": {количество таблиц}. Количество таблиц в базе данных-источнике "{база данных}": {количество таблиц}. Количество таблиц в базах данных-источнике и целевой базе данных должно совпадать).

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

    Обходное решение. Убедитесь, что схема в целевом объекте соответствует схеме источника. Дополнительные сведения о миграции схемы см. в разделе Документация по миграции по сети базы данных Azure для PostgreSQL.

  • Ошибка. База данных-источник {database} пуста.

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

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

  • Ошибка. Целевая база данных {база_данных} пуста. Перенос схемы.

    Ограничение: эта ошибка возникает, когда в целевой базе данных нет схемы. Схема в целевой базе данных должна соответствовать схеме в базе данных-источнике.

    Обходное решение. Убедитесь, что схема в целевом объекте соответствует схеме источника. Дополнительные сведения о миграции схемы см. в разделе Документация по миграции по сети базы данных Azure для PostgreSQL.

Другие ограничения

  • Имя базы данных не может содержать точку с запятой (;).
  • Записываемая таблица должна иметь первичный ключ. Если в таблице нет первичного ключа, результат операций записи DELETE и UPDATE будет непредсказуемым.
  • Обновление сегмента первичного ключа игнорируется. Применение такого обновления будет определяться целевым объектом как обновление, которое не обновило ни одну строку. Результатом является запись, записанная в таблицу исключений.
  • Если в таблице есть столбец JSON, любые операции удаления или обновления в этой таблице могут привести к сбою при миграции.
  • Миграция нескольких таблиц с одинаковым именем, указанным в разных регистрах, может привести к непредсказуемому поведению и не поддерживается. Например, это относится к следующим именам: таблица1, ТАБЛИЦА1 и Таблица1.
  • Обработка изменений таблицы DDL [CREATE | ALTER | DROP | TRUNCATE] не поддерживается.
  • В Database Migration Service одно действие миграции поддерживает работу не более чем с четырьмя базами данных.
  • Миграция таблицы pg_largeobject не поддерживается.