Часто задаваемые вопросы о службе Azure Database Migration Service

Azure Database Migration Service — это полностью управляемая служба, которая выполняет непрерывную миграцию из множества источников баз данных на платформы данных Azure с минимальным временем простоя. Эта служба сейчас предоставляется в режиме общедоступной версии. Основное внимание уделяется оптимизации следующих возможностей:

• надежность и производительность;
• итеративное добавление пар исходного и целевого объектов;
• работа над функциями непрерывной миграции.

В настоящее время служба поддерживает различные пары источника и целевого объекта или сценарии миграции. Полный список состояний всех доступных сценариев миграции см. в статье Состояние сценариев миграции, поддерживаемых службой Azure Database Migration Service.

При миграции с SQL Server поддерживаемые источники для Azure Database Migration Service — ЭТО SQL Server 2008 и более поздние версии. Если вы используете Azure Data Studio с расширением миграции SQL, поддерживаются источники SQL Server 2008 по SQL Server 2022.

Вы можете использовать службу Azure Database Migration Service для автономной миграции или миграции по сети. При автономной миграции простой приложения начинается с момента начала переноса. При использовании миграции по сети простой приложения ограничен только временем переключения в конце переноса. Мы рекомендуем выполнить тестирование автономной миграции, чтобы определить, допустим ли простой, и, если нет, выполнить миграцию с подключением к сети.

Служба Azure Database Migration Service является предпочтительным методом переноса базы данных в Microsoft Azure в нужном масштабе. Дополнительные сведения о сравнении Azure Database Migration Service с другими средствами миграции баз данных Майкрософт и рекомендациями по использованию службы для различных сценариев см. в разделе "Различные средства миграции баз данных Майкрософт и службы".

Служба "Миграция Azure" помогает выполнять миграцию локальных виртуальных машин в Azure IaaS. Оценивается пригодность для миграции, показатели производительности, на основе которых определяется требуемый размер, и расходы на работу локальных виртуальных машин в Azure. Служба "Миграция Azure" подходит для переноса рабочих нагрузок на локальных виртуальных машинах на виртуальные машины IaaS Azure методом lift-and-shift. Однако в отличие от Azure Database Migration Service миграция Azure не является специализированной службой миграции базы данных для платформ реляционных баз данных Azure PaaS, таких как База данных SQL Azure или Управляемый экземпляр SQL Azure.

№ Database Migration Service не хранит данные клиента.

Для виртуальных машин SQL Azure и целевых объектов SQL Azure DMS использует физическую миграцию, т. е. с помощью резервного копирования и восстановления. Как описано ниже, выбранный режим миграции определяет, как данные хранятся согласованно между источником и целевым объектом.

• Автономная миграция: во время автономной миграции на виртуальную машину SQL Azure и целевые объекты SQL Azure, время простоя приложения начинается при запуске миграции. DMS восстановит все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в S МБ сетевое хранилище или контейнер BLOB-объектов Azure (согласно конфигурации миграции). Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. В отсутствие проверка sum целостность резервной копии явно проверка перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все файлы резервного копирования, включая последнее имя файла резервной копии из источника, используя примененный или восстановленный файл резервного копирования на целевой странице мониторинга миграции DMS, и проверить соответствующие проверка sum.

• Миграция через Интернет: во время миграции в интернет-виртуальную машину SQL Azure и целевые показатели SQL Azure, время простоя начинается после запуска отрезка миграции вместе с остановкой приложения. DMS восстановит все файлы резервной копии в целевой объект, если последняя версия файла резервного копирования из источника была передана в S МБ сетевое хранилище или контейнер BLOB-объектов Azure (согласно конфигурации миграции). После нажатия кнопки переключение DMS показывает количество ожидающих файлов резервного копирования (если таковые имеются), которые присутствуют в сетевом хранилище S МБ или контейнере BLOB-объектов Azure и еще не будут применены или восстановлены на целевом объекте. Если резервная копия выполняется с параметром CHECKSUM, операция восстановления DMS автоматически выполняет проверку. В отсутствие проверка sum целостность резервной копии явно проверка перед восстановлением. Это гарантирует, что файл восстановления идентичен файлу резервной копии и, следовательно, имеет одинаковые данные. Вы можете проверить все файлы резервного копирования, включая последнее имя файла резервной копии из источника, используя примененный или восстановленный файл резервного копирования на целевой странице мониторинга миграции DMS, и проверить соответствующие проверка sum.

Для целевых объектов базы данных SQL Azure DMS выполняет логическую миграцию в случае базы данных SQL Azure, т. е. копирует данные из таблиц базы данных SQL источника и записывает его в таблицы целевой базы данных SQL Azure. Так как DMS поддерживает только автономную миграцию в базу данных SQL Azure, время простоя приложения начинается при запуске миграции. Вы можете отслеживать и проверять количество строк( из исходной таблицы базы данных) и скопировано (записано в целевую таблицу базы данных SQL Azure) на странице мониторинга миграции. В качестве дополнительного подтверждения можно запустить приведенный ниже TSQL, чтобы получить проверка sum как в исходных, так и в целевых базах данных, а также проверить исходные и восстанавливаемые данные идентичны.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

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

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

• Azure Monitor
• Azure
• Хранилище Azure
• Служебная шина Azure
• Azure Data Factory

Внутри dmS поддерживает хранилище метаданных, включающее сведения о сетевых расположениях, учетных данных, файлах резервного копирования и задачах. Учетные данные и выбранные поля, такие как ключи учетной записи, шифруются. Данные, такие как имена таблиц, которые могут быть включены в телеметрию, хэшируются. Имена пользователей могут отображаться в журналах служб в виде обычного текста, но пароли никогда не будут. Данные телеметрии разложены по регионам, управляются политиками хранения и доступны только авторизованным сотрудникам корпорации Майкрософт в целях устранения неполадок. Имена ресурсов Azure, такие как имена серверов и баз данных, следуйте правилам для ресурсов Azure.

DMS (классическая модель) использует Служебная шина Azure разделы для упрощения взаимодействия между вычислительными слоями. Разделы Служебная шина Azure уникальны для каждого экземпляра DMS, а все персональные данные шифруются.

Управляемый экземпляр SQL Azure и SQL Server в Azure Виртуальные машины

Схема и данные переносятся с помощью резервного копирования и восстановления. У клиентов есть выбор восстановления из сетевой папки или непосредственно из контейнера хранилища. Файл, содержащий данные о производительности Windows, может использоваться для предоставления необязательных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки.

База данных SQL Azure

Миграция в База данных SQL Azure выполняется двумя шагами. Первым шагом является миграция схемы. DMS (классическая модель) использует объекты управления SQL (SMO) для миграции схем. Второй шаг — это фактическая миграция данных. SqlBulkCopy используется для переноса данных. DMS не поддерживает миграцию схемы. Данные переносятся с помощью Фабрика данных Azure. При необходимости, но настоятельно рекомендуется использовать файл, содержащий данные о производительности Windows, для предоставления рекомендаций по размеру рабочей нагрузки.

База данных Azure для PostgreSQL

В этом сценарии конечный пользователь извлекает метаданные в данном случае схему с помощью служебных программ командной строки и pg_restore командной pg_dump строки. При настройке отслеживания измененных данных для PostgreSQL DMS внутренне использует pg_dump и pg_restore выполняет начальное начальное засеяние для CDC. Данные хранятся в зашифрованном временном хранилище, доступном только экземпляру DMS. Файл, содержащий данные о производительности Windows, может использоваться для предоставления необязательных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки.

База данных Azure для MySQL

В этом сценарии извлечение схемы и миграция выполняются DMS (классической) с помощью mysql-net/MySql Подключение or. По возможности реплика бинлога MySQL используется для реплика изменения данных и схемы. Пользовательский код используется для синхронизации изменений, в которых невозможно использовать реплика бинлога.

Из MongoDB в Azure Cosmos DB

DMS извлекает и вставляет данные из MongoDB в Cosmos DB. Он также предлагает возможность извлечь данные из дампа BSON или JSON.

Для дампов BSON DMS использует данные в формате в bsondump той же папке в контейнере BLOB-объектов. DMS ищет только файлы метаданных с помощью формата collection.metadata.json.

Для дампов JSON DMS считывает файлы в папках контейнеров BLOB-объектов с именем содержащихся баз данных. В каждой папке базы данных DMS использует только файлы данных, помещенные в вложенную папку data . DMS смотрит только на файлы, помещенные в metadata вложенную папку, и именуется с помощью формата collection.json метаданных.

Oracle для База данных SQL Azure

В этом сценарии отчет AWR или файл Windows perfmon используются для предоставления дополнительных рекомендаций по размеру рабочей нагрузки (но настоятельно рекомендуется). Пользователь, выполняющий миграцию, использует Набор средств для преобразования схемы данных для выполнения миграции схемы для подготовки целевой базы данных.

Oracle для База данных Azure для PostgreSQL

Как и Oracle для База данных SQL Azure, в этом сценарии отчет AWR или файл Windows perfmon используется для предоставления дополнительных (но настоятельно рекомендуемых) рекомендаций по размеру рабочей нагрузки. Библиотека ora2pg используется для извлечения схемы и переноса данных вручную пользователем, выполняющим миграцию.

DMS (классическая модель) зависит от конфигурации сети клиента. Если источник миграции использует частные конечные точки, мы используем частные конечные точки, что является предпочтительной конфигурацией. Мы используем общедоступные конечные точки, если они являются единственным вариантом.

DMS использует ADF в значительной степени за кулисами для планирования и координации перемещения данных. Кроме того, локальная среда выполнения интеграции отличается от того, который, вероятно, уже используется для собственных конвейеров ADF. Дополнительные сведения о проблемах брандмауэра и прокси-сервера см. в статье "Создание и настройка локальной среды выполнения интеграции".

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

Все передаваемые данные защищены с помощью шифрования TLS 1.2 по умолчанию. Устаревшие клиенты, требующие более старых версий TLS, нуждаются в необходимых версиях, включенных на странице портала DMS (классический). Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить необходимые параметры TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в КБ 3135244 . Поддержка TLS 1.2 для Microsoft SQL Server.

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

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

Все данные при передаче шифруются с помощью шифрования TLS 1.2 по умолчанию. Страница портала DMS (классическая) позволяет использовать старые версии TLS для устаревших клиентов. Для DMS компьютер, на котором установлена локальная среда выполнения интеграции, можно настроить, чтобы разрешить управление параметрами TLS для размещения устаревших клиентов. Дополнительные сведения о конфигурации TLS для SQL Server см. в КБ 3135244 . Поддержка TLS 1.2 для Microsoft SQL Server.

Мы не предоставляем возможность шифрования данных на уровне управления или плоскости данных с помощью ключей, управляемых клиентом. Все данные клиента удаляются при удалении экземпляра DMS, кроме журналов служб. Журналы служб DMS хранятся только в течение 30 дней.

TDE

DMS поддерживает миграцию управляемых клиентом ключей (CMK) в SQL Azure для прозрачного шифрования баз данных (TDE). Пошаговые инструкции по переносу ключей TDE см. в руководстве по переносу баз данных с поддержкой TDE (предварительная версия) в SQL Azure в Azure Data Studio.

Шифрование ячеек

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

Always Encrypted

DMS в настоящее время не поддерживает миграцию Always Encrypted с помощью сценариев, когда отдельные строки данных переносятся между источником и целевым объектом. Столбцы, зашифрованные с помощью Always Encrypted, переносятся должным образом в сценариях, использующих резервное копирование и восстановление, например переход на виртуальную машину SQL Azure или Управляемый экземпляр SQL Azure из существующего экземпляра SQL Server.

Мы не реализуем никакого контроля доступа, учитываемого расположением, за пределами того, что уже доступно в Azure. Все данные, связанные с экземпляром DMS, находятся в том же регионе, что и ресурс DMS.

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

Внедрение виртуальной сети — это действие добавления ресурса Azure, который находится в клиенте Майкрософт, в подсеть в виртуальной сети в клиенте клиента. Этот подход был принят с DMS, чтобы позволить нам управлять вычислительными ресурсами от имени клиента, сохраняя доступ к ресурсам клиентов. Так как сеть находится в подписке клиента, корпорация Майкрософт не может управлять виртуальной машиной, не выдавая команды "Пуск", "Остановка", "Удалить" или "Развернуть". Все остальные действия управления, требующие доступа к виртуальной машине, требуют запроса и утверждения, инициированного клиентом.

Есть несколько предварительных требований, которые необходимо выполнить, чтобы служба Azure Database Migration Service работала без проблем при переносе баз данных. Одни предварительные требования применяются во всех сценариях (с парами исходного и целевого объектов), поддерживаемых службой, другие уникальны и используются в определенных сценариях.

Ниже приведены предварительные требования для использования службы Azure Database Migration Service, которые применяются во всех поддерживаемых сценариях миграции.

• Создайте виртуальную сеть Microsoft Azure для Azure Database Migration Service с помощью модели развертывания Azure Resource Manager. Она обеспечивает подключение "сеть — сеть" к локальным исходным серверам через ExpressRoute или VPN.
• Убедитесь, что правила группы безопасности сети для виртуальной сети не блокируют порт 443 для тегов Служебной шины, службы хранилища и Azure Monitor. См. дополнительные сведения о фильтрации трафика, предназначенного для виртуальной сети, с помощью групп безопасности сети.
• Если перед исходными базами данных развернуто устройство брандмауэра, вам может понадобиться добавить правила брандмауэра, чтобы позволить службе Azure Database Migration Service обращаться к исходным базам данных для выполнения миграции.

Список всех необходимых компонентов, необходимых для конкуренции с конкретными сценариями миграции с помощью Azure Database Migration Service, см. в связанных руководствах в документации по Службе миграции базы данных Azure.

Вам может потребоваться добавить правила брандмауэра, позволяющие службе Azure Database Migration Service получать доступ к исходной базе данных для выполнения переноса. IP-адрес для этой службы является динамическим, однако при использовании ExpressRoute этот адрес будет в закрытом порядке назначен корпоративной сети. Самый простой способ определить соответствующий IP-адрес — перейти в ту же группу ресурсов, в которой подготовлен ресурс службы Azure Database Migration Service, чтобы найти связанный сетевой интерфейс. Обычно имя ресурса сетевого интерфейса начинается с префикса сетевого адаптера, за которым следует уникальный символ и последовательность чисел, например NIC-jj6tnztnmarpsskr82rbndyp'. Выбрав этот ресурс сетевого интерфейса, вы увидите IP-адрес, который необходимо включить в список разрешений на странице обзора ресурсов портал Azure.

Кроме того, может потребоваться включить источник порта, прослушивающий SQL Server в списке разрешений. По умолчанию — это порт 1433, однако исходный SQL Server также можно настроить на ожидание передачи данных с других портов. В этом случае необходимо также включить эти порты в список разрешений. Определить порт, который SQL Server прослушивает, можно с помощью запроса динамического административного представления:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

Вы также можете определить порт, который SQL Server прослушивает, запросив журнал ошибок SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

В нескольких руководствах корпорации Майкрософт приведены пошаговые инструкции по настройке виртуальной сети, а официальную документацию можно найти в этой статье.

Во время обычного переноса базы данных вы:

1. Создаете целевую базу данных.
2. Оцениваете базы данных-источники.
   • В случае однородной миграции оцените существующие базы данных с помощью DMA.
   • В случае разнородной миграции (из конкурирующих источников) оцените существующие базы данных с помощью SSMA. Помощник SSMA также можно использовать для преобразования объектов баз данных и переноса схемы на целевую платформу.
3. Создайте экземпляр Azure Database Migration Service.
4. Создаете проект миграции, указав исходные базы данных, целевые базы данных и таблицы для переноса.
5. Запускаете полную загрузку.
6. Выбираете последующую проверку.
7. Вручную переключаете рабочую среду на использование новой облачной базы данных.

Если при подготовке миграции у вас возникли проблемы с подключением к системе базы данных-источника, создайте виртуальную машину в той же подсети виртуальной сети, где настроен экземпляр DMS. На виртуальной машине вы сможете запустить тест подключения, например с помощью файла UDL, чтобы проверить связь с SQL Server, или скачав Robo 3T для проверки подключений MongoDB. Если проверка подключения завершилась успешно, у вас не должно возникнуть проблем с подключением к базе данных-источнику. Если проверка подключения завершилась ошибкой, обратитесь к администратору сети.

Если пользователь явно останавливает Azure Database Migration Service (DMS) или если служба неактивна в течение 24 часов, служба находится в состоянии остановленной или автоматической приостановки. В каждом случае служба недоступна и в остановленном состоянии. Чтобы возобновить активную миграцию, перезапустите службу.

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

• используйте ценовую категорию общего назначения с несколькими ЦП при создании экземпляра службы, чтобы обеспечить параллелизацию и ускоренную передачу данных благодаря использованию нескольких ЦП;
• Временно масштабируйте целевой экземпляр База данных SQL Azure до номера SKU уровня Premium во время операции миграции данных, чтобы свести к минимуму База данных SQL Azure регулирование, которое может повлиять на действия передачи данных при использовании номеров SKU нижнего уровня.

Следующие шаги

• Что такое Azure Database Migration Service.