Перенос ресурсов базы данных в глобальную среду Azure

  • Статья

Важно!

С августа 2018 г. мы не принимаем новых клиентов и не развертываем новые функции и службы в исходных расположениях Microsoft Cloud Germany.

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

Кроме того, 30 сентября 2020 г. мы объявили, что Microsoft Cloud Germany будет закрыто 29 октября 2021 г. Дополнительные сведения можно найти здесь: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

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

В этой статье содержатся полезные сведения о миграции ресурсов баз данных Azure из Azure для Германии в глобальную среду Azure.

База данных SQL

Чтобы перенести небольшие рабочие нагрузки Базы данных SQL Azure без сохранения подключения к базе, создайте BACPAC-файл с помощью функции экспорта. BACPAC-файл — это сжатый (в ZIP-архиве) файл, содержащий метаданные и данные из базы данных SQL Server. После создания BACPAC-файла можно скопировать файл в целевую среду (например, с помощью AzCopy) и использовать функцию импорта для перестроения базы данных. Обязательно учитывайте следующие важные сведения:

  • Чтобы транзакция экспорта была согласованной, убедитесь, что выполняется одно из следующих условий:
    • Во время экспорта не происходит никаких действий записи.
    • Выполняется экспорт из транзакционно согласованной копии вашей базы данных SQL.
  • Для экспорта в хранилище BLOB-объектов Azure размер BACPAC-файла ограничен 200 ГБ. Для архивации BACPAC-файла большего размера выполняйте экспорт в локальное хранилище.
  • Если операция экспорта из базы данных SQL занимает больше 20 часов, операция может быть отменена. Чтобы получить советы по повышению производительности, ознакомьтесь со следующими статьями.

Примечание

Строка подключения изменяется после операции экспорта, так как DNS-имя сервера изменяется во время экспорта.

Дополнительные сведения

Примечание

Мы рекомендуем использовать модуль Azure Az PowerShell для взаимодействия с Azure. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.

Миграция базы данных SQL с помощью активной георепликации

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

Важно!

Настройка активной георепликации для переноса баз данных в глобальную среду Azure поддерживается только с использованием Transact-SQL (T-SQL), и перед миграцией вы должны подать запрос на включение поддержки миграции в глобальную среду Azure для вашей подписки. Чтобы отправить такой запрос, используйте эту ссылку запроса на поддержку.

Примечание

Для активной георепликации с облаком Azure для Германии поддерживаются регионы глобальной облачной среды облака Azure, Центрально-Западная Германия и Северная Германия. Если в качестве окончательного места назначения базы данных вам необходим другой регион Azure, то после завершения миграции в глобальную среду Azure рекомендуется настроить дополнительную связь георепликации из региона "Центрально-Западная Германия" или "Северная Германия" в нужный регион глобальной среды Azure.

Дополнительные сведения об затратах на активную георепликацию см. в разделе Активная георепликация страницы с ценами на Базу данных SQL Azure.

Для миграции баз данных с активной георепликацией требуется логический сервер Azure SQL в глобальной среде Azure. Вы можете создать сервер с помощью портала, Azure PowerShell, Azure CLI и т. д., но настроить активную георепликацию для миграции из Azure для Германии в глобальную среду Azure можно только с помощью Transact-SQL (T-SQL).

Важно!

При переходе между облаками префиксы имени основного (Azure для Германии) и вторичного (глобальная среда Azure) сервера должны различаться. Если имена серверов совпадают, инструкция ALTER DATABASE будет успешно выполнена, но миграция завершится ошибкой. Например, если префикс имени сервера-источника — myserver (myserver.database.cloudapi.de), префикс имени сервера-получателя в глобальной среде Azure не может быть myserver.

Инструкция ALTER DATABASE позволяет задать целевой сервер в глобальной среде Azure, используя полное имя DNS-сервера на стороне назначения.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbпредставляет имя базы данных на сервере Azure SQL в Azure для Германии.
  • public-server.database.windows.net представляет имя сервера Azure SQL, которое существует в глобальной среде Azure, куда требуется перенести базу данных. Требуется пространство имен database.windows.net; замените public-server именем логического сервера SQL в глобальной среде Azure. Имя сервера в глобальной среде Azure должно отличаться от имени сервера-источника в Azure для Германии.

Команда выполняется в базе данных master на сервере Azure для Германии с локальной базой данных, для которой выполняется миграция.

  • API запуска копирования T-SQL проверяет подлинность вошедшего в систему пользователя на общедоступном облачном сервере путем поиска пользователя с тем же именем входа SQL или именем пользователем в базе данных master этого сервера. Этот подход не зависит от облака.; таким словами, для запуска копирования между облаками используется API T-SQL. Разрешения и дополнительные сведения для этого раздела см. в статьях Создание и использование активной георепликации и ALTER DATABASE (Transact-SQL).

  • За исключением начального расширения команды T-SQL, указывающего на логический сервер Azure SQL в глобальной среде Azure, оставшаяся часть процедуры активной георепликации идентична существующей процедуре в локальном облаке. Подробные инструкции по созданию активной георепликации см. в статьях Создание и использование активной георепликации за исключением того, что база данных-получатель создается на вторичном логическом сервере, созданном в глобальной среде Azure.

  • Когда база данных-получатель появится в глобальной среде Azure (в виде подключенной копии базы данных Azure для Германии), клиент может инициировать для этой базы данных отработку отказа из Azure для Германии в глобальную среду Azure с помощью команды T-SQL ALTER DATABASE (см. таблицу ниже).

  • После отработки отказа, когда получатель станет базой данных-источником в глобальной среде Azure, вы можете в любое время остановить активную георепликацию и удалить базу данных-получатель на стороне Azure для Германии (см. таблицу ниже и шаги, представленные на схеме).

  • После отработки отказа для базы данных-получателя в Azure для Германии будет продолжать начисляться плата до момента ее удаления.

  • Использование команды ALTER DATABASE — единственный способ настроить активную георепликацию для переноса базы данных Azure для Германии в глобальную среду Azure.

  • Для настройки активной георепликации для этой миграции нельзя использовать портал Azure, Azure Resource Manager, PowerShell или CLI.

Чтобы перенести базу данных из Azure для Германии в глобальную среду Azure, выполните указанные ниже действия.

  1. Выберите пользовательскую базу данных в Azure для Германии, например azuregermanydb.

  2. Создайте логический сервер в глобальной среде Azure (общедоступном облаке), например globalazureserver. Его полное доменное имя (FQDN) — globalazureserver.database.windows.net.

  3. Запустите активную георепликацию из Azure для Германии в глобальную среду Azure, выполнив эту команду T-SQL на сервере в Azure для Германии. Обратите внимание, что для общедоступного сервера globalazureserver.database.windows.net используется полное имя DNS. Это означает, что целевой сервер находится в глобальной среде Azure, а не в Azure для Германии.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Когда репликация готова к переносу рабочей нагрузки для чтения и записи на глобальный сервер Azure, инициируйте плановую отработку отказа в глобальную среду Azure, выполнив эту команду T-SQL на глобальном сервере Azure.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Связь активной георепликации может быть разорвана до или после отработки отказа. При запуске следующей команды T-SQL после плановой отработки отказа удаляется связь георепликации с базой данных в глобальной среде Azure, которая является копией для чтения и записи. Ее нужно выполнить на логическом сервере текущей базы данных-источника георепликации (т. е. на глобальном сервере Azure). В результате процесс миграции будет завершен.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    Следующая команда T-SQL, выполняемая перед запланированной отработкой отказа, также останавливает процесс миграции, но в этом случае база данных в Azure для Германии остается копией для чтения и записи. Эта команда T-SQL также запускается на логическом сервере текущей базы данных-источника георепликации (в данном случае — на сервере Azure для Германии).

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Эти инструкции по переносу баз данных Azure SQL из Azure для Германии в глобальную среду Azure также можно использовать при активной георепликации.

Дополнительные сведения с командами T-SQL для управления отработкой отказа см. в таблицах ниже. Следующие команды поддерживаются для активной георепликации между облаком Azure для Германии и глобальной средой Azure:

Команда Описание
ALTER DATABASE Используйте аргумент ADD SECONDARY ON SERVER, чтобы создать базу данных-получатель для существующей базы данных и начать репликацию данных.
ALTER DATABASE Используйте аргумент FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS, чтобы задать базу данных-получатель в качестве базы данных-источника для запуска отработки отказа.
ALTER DATABASE Используйте аргумент REMOVE SECONDARY ON SERVER, чтобы завершить репликацию данных между базой данных SQL и указанной базой данных-получателем.

Системные представления мониторинга активной георепликации

Команда Описание
sys.geo_replication_links Возвращает сведения о всех существующих связях репликации для каждой базы данных на сервере Базы данных SQL Azure.
sys.dm_geo_replication_link_status Получает время последней репликации, задержку при последней репликации и другие сведения о связи репликации для заданной базы данных SQL.
sys.dm_operation_status Показывает состояние всех операций с базой данных, включая состояние связей репликации.
sp_wait_for_database_copy_sync Указывает приложению ждать, пока все зафиксированные транзакции не будут реплицированы и подтверждены активной базой данных-получателем.

Миграция резервных копий долгосрочного хранения базы данных SQL

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

Примечание

Описанные здесь методы копирования резервных копий LTR позволяют копировать из Azure для Германии в глобальную среду Azure только резервные копии LTR. Копирование резервных копий PITR с помощью этих методов не поддерживается.

Предварительные требования

  1. До начала копирования резервных копий в глобальной среде Azure должна существовать целевая база данных, в которую копируются резервные копии LTR. Рекомендуется сначала выполнить миграцию базы данных-источника с помощью активной георепликации, а затем инициировать копирование резервных копий LTR. Это обеспечит копирование резервных копий базы данных в правильную целевую базу. Этот шаг не является обязательным, если выполняется копирование резервных копий LTR удаленной базы. При копировании резервных копий LTR удаленной базы данных в целевом регионе будет создана база с фиктивным DatabaseID.
  2. Установите этот модуль PowerShell Az.
  3. Прежде чем начинать, убедитесь, что в области подписки или группы ресурсов предоставлены необходимые роли Azure RBAC. Обратите внимание: для доступа к резервным копиям LTR, относящимся к удаленному серверу, разрешение должно быть предоставлено в области подписки этого сервера. .

Ограничения

  • Группы отработки отказа не поддерживаются. Это означает, что клиенты, выполняющие миграцию баз данных Azure для Германии, должны будут управлять во время отработки отказа собственными строками подключения.
  • Не поддерживаются портал Azure, Azure Resource Manager API, PowerShell и CLI. Это означает, что в рамках каждой миграции из Azure для Германии управлять конфигурацией активной георепликации и отработкой отказа необходимо с помощью T-SQL.
  • Клиенты не могут создавать несколько географических получателей в глобальной среде Azure для баз данных в Azure для Германии.
  • Создание географического получателя должно инициироваться из региона Azure для Германии.
  • Клиенты могут переносить базы данных из Azure для Германии только в глобальную среду Azure. В настоящее время миграция между облаками не поддерживается.
  • Пользователи Azure AD в пользовательских базах данных Azure для Германии переносятся, но оказываются недоступны в новом арендаторе Azure AD, где находится перенесенная база. Чтобы сделать этих пользователей доступными, их необходимо удалить вручную и создать повторно с применением текущих пользователей Azure AD, доступных в новом арендаторе Azure AD, где находится только что перенесенная база данных.

Копирование резервных копий долгосрочного хранения с помощью PowerShell

Появилась новая команда PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup, которая позволяет копировать резервные копии долгосрочного хранения из Azure для Германии в глобальные регионы Azure.

  1. Копирование резервных копий LTR по имени В примере ниже показано, как скопировать резервную копию LTR из Azure для Германии в глобальный регион Azure с помощью backupname.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. Копирование резервных копий LTR по resourceId В примере ниже показано, как скопировать резервную копию LTR из Azure для Германии в глобальный регион Azure по ИД ресурса резервной копии. Этот пример также можно использовать для копирования резервных копий удаленных баз.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Ограничения

  • Резервные копии восстановления до точки во времени (PITR) создаются только в базе данных-источнике (так задумано). При миграции баз данных из Azure для Германии путем аварийного восстановления посредством георепликации резервные копии PITR после отработки отказа будут создаваться на новом первичном ресурсе. Однако существующие резервные копии PITR (на предыдущем первичном ресурсе в Azure для Германии) не будут перенесены. Если вам нужно реализовать все сценарии восстановления на момент времени на основе резервных копий PITR, необходимо восстановить базу данных из резервных копий PITR в Azure для Германии, а затем перенести ее в восстановленном виде в глобальную среду Azure.
  • Политики долгосрочного хранения вместе с базой данных не переносятся. При наличии в базе данных в Azure для Германии политики долгосрочного хранения (LTR) необходимо вручную скопировать и повторно создать политику LTR в новой базе после миграции.

Запрос доступа

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

Чтобы включить подписку Azure для Германии, создайте запрос на поддержку миграции с помощью следующей ссылки:

  1. Найдите следующий запрос на поддержку миграции.

  2. На вкладке "Основные" введите Миграция путем аварийного восстановления посредством георепликации в поле сводки, а затем выберите Далее: решения

    новая форма запроса на поддержку

  3. Просмотрите Рекомендуемые действия и выберите Далее: подробные сведения.

    необходимые сведения для запроса на поддержку

  4. На странице сведений укажите следующее:

    1. В поле "Описание" укажите идентификатор подписки глобальной среды Azure для миграции. Чтобы перенести базы данных в несколько подписок, добавьте список идентификаторов глобальной среды Azure, в которые вы хотите их перенести.
    2. Укажите контактные данные: имя, название организации, адрес электронной почты или номер телефона.
    3. Заполните форму и выберите Далее: проверка и создание.

    подробности запроса на поддержку

  5. Проверьте свой запрос на поддержку и выберите Создать.

После обработки запроса с вами свяжутся.

Azure Cosmos DB

С помощью средства переноса данных Azure Cosmos DB вы можете перенести данные в Azure Cosmos DB. Средство переноса данных Azure Cosmos DB — это решение с открытым исходным кодом, которое импортирует данные в Azure Cosmos DB из различных источников, включая JSON-файлы, MongoDB, SQL Server, CSV-файлы, хранилище таблиц Azure, Amazon DynamoDB, HBase и контейнеры Azure Cosmos.

Средство переноса данных Azure Cosmos DB доступно в виде инструмента с графическим интерфейсом или программы командной строки. Его исходный код доступен в репозитории GitHub Azure Cosmos DB Data Migration Tool. Скомпилированная версия средства доступна в Центре загрузки Майкрософт.

Чтобы перенести ресурсы Azure Cosmos DB, рекомендуется выполнить следующие действия.

  1. Ознакомьтесь с требованиями к работоспособности приложений и конфигурациями учетных записей, чтобы определить оптимальный план действий.
  2. Клонируйте конфигурацию учетных записей из Azure для Германии в новый регион, запустив средство переноса данных.
  3. Если возможно использовать период обслуживания, скопируйте данные из источника в место назначения, запустив средство переноса данных.
  4. Если сделать это в период обслуживания невозможно, скопируйте данные из источника в место назначения, запустив средство, а затем выполните следующие действия.
    1. Используя конфигурацию, чтобы внесите изменения в приложение, чтобы обеспечить чтение и запись.
    2. Выполните первоначальную синхронизацию.
    3. Настройте добавочную синхронизацию и подключите канал изменений.
    4. Направьте считываемые данные в новую учетную запись и проверьте приложение.
    5. Остановите запись в старую учетную запись, проверьте, подключен ли канал изменений, а затем настройте запись в новую учетную запись.
    6. Остановите средство и удалите старую учетную запись.
  5. Запустите средство, чтобы проверить согласованность данных в старой и новой учетных записях.

Дополнительные сведения

Кэш Redis для Azure

Если вы хотите перенести экземпляр Кэша Azure для Redis из Azure для Германии в глобальную среду Azure, есть несколько вариантов. Их выбор зависит от ваших требований.

Вариант 1. Потеря данных, создание нового экземпляра

Этот подход имеет смысл, если выполняются оба следующих условия:

  • Вы используете Кэш Azure для Redis в качестве временного кэша данных.
  • Приложение автоматически заполнит данные кэша в новом регионе.

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

  1. Создайте новый экземпляр Кэша Azure для Redis в новом целевом регионе.
  2. Внесите в приложение изменения для использования нового экземпляра.
  3. Удалите старый экземпляр Кэша Azure для Redis в исходном регионе.

Вариант 2. Копирование данных из исходного экземпляра в целевой

Сотрудник команды Кэш Azure для Redis создал инструмент с открытым исходным кодом, который копирует данные из одного экземпляра Кэша Azure для Redis в другой без использования функций импорта или экспорта. Сведения об этом средстве см. на шаге 4 ниже.

Чтобы скопировать данные из исходного экземпляра в целевой:

  1. Создайте виртуальную машину в исходном регионе. Если набор данных в Кэше Azure для Redis большой, убедитесь, что выбран относительно мощный типоразмер виртуальной машины, чтобы минимизировать время копирования.
  2. Создайте новый экземпляр Кэша Azure для Redis в целевом регионе.
  3. Запишите на диск данные из целевого экземпляра. (Убедитесь, что не выполняется очистка из исходного экземпляра. Очистка требуется, так как средство копирования не перезаписывает существующие ключи в целевом расположении.)
  4. Для автоматического копирования данных из исходного экземпляра Кэша Azure для Redis в целевой используйте следующий инструмент: исходный код средства, файлы для загрузки.

Примечание

Этот процесс может длиться долго в зависимости от размера набора данных.

Вариант 3. Экспорт из исходного экземпляра, импорт в целевой экземпляр

Этот подход использует функции, доступных только на уровне Premium.

Чтобы экспортировать данные из исходного экземпляра и импортировать их в целевой:

  1. Создайте новый экземпляра Кэша Azure для Redis ценового уровня Premium в целевом регионе. Используйте тот же размер, что и в исходном экземпляре Кэша Azure для Redis.

  2. Экспортируйте данные из исходного кэша или используйте командлет PowerShell Export-AzRedisCache.

    Примечание

    Учетная запись экспорта служба хранилища Azure должна находиться в том же регионе, что и экземпляр кэша.

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

  4. Импортируйте данные в целевой кэш или используйте командлет PowerShell Import-AzRedisCAche.

  5. Перенастройте приложение так, чтобы оно использовало целевой экземпляр Кэша Azure для Redis.

Вариант 4. Запись данных в два экземпляра Кэша Azure для Redis, чтение из одного экземпляра

Для этого подхода потребуется внести изменения в приложение. Приложение должно записывать данные в несколько экземпляров кэша при чтении из одного экземпляра. Такой подход имеет смысл, если данные, хранящиеся в Кэше Azure для Redis, соответствуют следующим критериям:

  • Данные регулярно обновляются.
  • Все данные записываются в целевой экземпляр Кэша Azure для Redis.
  • У вас достаточно времени для обновления всех данных.

Дополнительные сведения

PostgreSQL и MySQL

Дополнительные сведения см. в статьях, приведенных в разделе "Резервное копирование и миграция данных" для PostgreSQL и MySQL.

PostgreSQL и MySQL

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

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