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

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

  • Статья

Это важно

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

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

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

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

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

База данных SQL

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

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

Примечание.

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

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

Примечание.

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

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

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

Это важно

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

Примечание.

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

Для получения сведений о расходах на активную георепликацию см. раздел "Активная георепликация" в ценообразовании Azure SQL Database.

Для переноса баз данных с активной георепликацией требуется логический сервер SQL Azure в глобальной среде 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 представляет имя базы данных на сервере SQL Azure в Германии.
  • public-server.database.windows.net представляет имя сервера SQL Azure, существующее в глобальной среде 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, указывающего логический сервер SQL Azure в глобальной среде Azure, остальная часть активного процесса георепликации идентична существующему выполнению в локальном облаке. Подробные инструкции по созданию активной георепликации см. в статье "Создание и использование активной георепликации", за исключением того, что вторичная база данных создается на вторичном сервере баз данных, который создан в глобальной среде Azure.

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

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

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

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

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

Чтобы перенести базу данных из Azure Для Германии в глобальную среду Azure:

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

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

  3. Запустите активную георепликацию из Azure в Германию в глобальную Azure, выполнив эту команду T-SQL на сервере в Azure в Германии. Обратите внимание, что полностью квалифицированное DNS-имя используется для публичного сервера globalazureserver.database.windows.net. Это означает, что целевой сервер находится в глобальной среде 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];

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

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

командование Описание
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте аргумент ADD SECONDARY ON SERVER для создания вторичной базы данных для существующей базы данных и запуска репликации данных.
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS для переключения вторичной базы данных на основную для инициирования переключения.
ИЗМЕНИТЬ БАЗУ ДАННЫХ Используйте 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 Germany. Чтобы перенести существующие долгосрочные резервные копии хранения в целевой глобальный регион Azure, можно использовать процедуру резервного копирования с длительным хранением.

Примечание.

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

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

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

Ограничения

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

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

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

  1. Копирование резервной копии LTR с использованием названия резервной копии В следующем примере показано, как скопировать резервную копию LTR из Azure Германия в глобальные регионы Azure, используя название резервной копии.
# 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 с помощью идентификатора ресурса резервного копирования В следующем примере показано, как скопировать резервную копию 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 Germany с помощью Geo-DR резервные копии PITR начнут создаваться на новом основном сервере после переключения. Однако существующие резервные копии PITR (на предыдущем первичном сервере в Azure в Германии) не будут перенесены. Если требуется резервное копирование PITR для поддержки любых сценариев восстановления на определенный момент времени, необходимо восстановить базу данных из резервных копий PITR в Azure в Германии, а затем перенести восстановленную базу данных в глобальную azure.
  • Долгосрочные политики хранения не переносятся с базой данных. Если у вас есть политика долгосрочного хранения (LTR) в базе данных в Azure в Германии, необходимо вручную скопировать и повторно создать политику LTR в новой базе данных после миграции.

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

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

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

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

  2. На вкладке "Основные сведения" введите Geo-DR миграция в качестве Сводки, а затем нажмите «Далее: Решения».

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

  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 доступно в виде графического интерфейса или в качестве средства командной строки. Исходный код доступен в инструменте миграции данных Azure Cosmos DB на репозитории GitHub. скомпилированная версия средства доступна в Центре загрузки Майкрософт.

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

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

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

Кэш Azure для Redis

У вас есть несколько вариантов, если вы хотите перенести экземпляр Azure Cache для Redis из Azure Germany в глобальный 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 в целевой экземпляр кэша Azure для Redis: источник инструмента и ссылка для скачивания инструмента.

Примечание.

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

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

Этот подход использует преимущества функций, доступных только на уровне "Премиум".

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

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

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

    Примечание.

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

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

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

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

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

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

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

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

PostgreSQL и MySQL

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

PostgreSQL и MySQL

Дальнейшие действия

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