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

Перемещение ресурсов в новый регион — База данных SQL Azure

  • Статья

Применимо к: База данных SQL Azure

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

Примечание.

  • Чтобы переместить базы данных и эластичные пулы в другой регион Azure, можно также использовать рекомендуемый объект Azure Resource Mover.
  • Эта статья относится к миграции в общедоступном облаке Azure или в том же независимом облаке.

Обзор

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

Общий рабочий процесс для перемещения ресурсов в другой регион состоит из следующих шагов:

  1. проверка предварительных требований для перемещения;
  2. подготовка к перемещению ресурсов в области;
  3. мониторинг процесса подготовки;
  4. тестирование процесса перемещения;
  5. запуск процесса перемещения;

Проверка необходимых компонентов для перемещения базы данных

  1. Создайте целевой сервер для каждого исходного сервера.
  2. Настройте правильные исключения брандмауэра с помощью PowerShell.
  3. Настройте оба сервера с правильными именами входа. Если вы не администратор подписки и не администратор сервера SQL, свяжитесь с администратором, чтобы получить необходимые разрешения. Дополнительные сведения см. в разделе Управление безопасностью базы данных SQL после аварийного восстановления.
  4. Если базы данных зашифрованы с помощью прозрачного шифрования данных (TDE) и в Azure Key Vault используется собственный ключ шифрования (BYOK или ключ, управляемый клиентом), убедитесь в том, что в целевых регионах подготовлен правильный материал шифрования.
    • Самый простой способ сделать это — добавить ключ шифрования из существующего хранилища ключей (который используется в качестве средства защиты TDE на исходном сервере) на целевой сервер, а затем задать ключ в качестве предохранителя TDE на целевом сервере, так как сервер в одном регионе теперь может быть подключен к хранилищу ключей в любом другом регионе.
    • Рекомендуется убедиться, что целевой сервер имеет доступ к старым ключам шифрования (требуется для восстановления резервных копий базы данных), выполните командлет Get-AzSqlServerKeyVaultKey на исходном сервере, чтобы вернуть список доступных ключей и добавить эти ключи на целевой сервер.
    • Дополнительные сведения и рекомендации по настройке управляемого клиентом TDE на целевом сервере см. в разделе Прозрачное шифрование данных Azure SQL с ключом, управляемым клиентом, в Azure Key Vault.
    • Сведения о перемещении хранилища ключей в новый регион см. в статье "Перемещение хранилища ключей Azure в разных регионах".
  5. Если включен аудит на уровне базы данных, отключите его и включите аудит на уровне сервера. После отработки отказа аудит на уровне базы данных требует трафика между регионами, который не требуется или возможен после перемещения.
  6. Для аудита на уровне сервера убедитесь, что:
    • Контейнер хранилища, Log Analytics или концентратор событий с существующими журналами аудита перемещен в целевой регион.
    • Аудит настроен на целевом сервере. Дополнительные сведения см. в разделе Начало работы с аудитом базы данных SQL.
  7. Если сервер имеет долгосрочную политику хранения (LTR), существующие резервные копии LTR остаются связанными с текущим сервером. Так как целевой сервер отличается, вы можете получить доступ к старым резервным копиям LTR в исходном регионе с помощью исходного сервера, даже если сервер удаляется.

Примечание.

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

Подготовка ресурсов

  1. Создайте группу отработки отказа между сервером источника и сервером целевого объекта.
  2. Добавьте базы данных, которые необходимо переместить в группу отработки отказа. Репликация всех добавленных баз данных инициируется автоматически. Дополнительные сведения см. в разделе Использование групп отработки отказа с Базой данных SQL.

Мониторинг процесса подготовки

Вы можете периодически вызывать Get-AzSqlDatabaseFailoverGroup , чтобы отслеживать репликацию баз данных из источника на целевой сервер. Выходной объект Get-AzSqlDatabaseFailoverGroup включает свойство для ReplicationState:

  • ReplicationState = 2 (CATCH_UP) указывает, что база данных синхронизирована и для нее можно выполнить безопасную отработку отказа.
  • ReplicationState = 0 (SEEDING) указывает, что база данных еще не заполнена и попытка отработки отказа завершится ошибкой.

Тестирование синхронизации

Когда ReplicationState перейдет в состояние 2, подключитесь к каждой базе данных или подмножеству баз данных с помощью вторичной конечной точки <fog-name>.secondary.database.windows.net и отправьте любой запрос к базам данных, чтобы обеспечить возможность подключения, правильную конфигурацию безопасности и репликацию данных.

Начало перемещения

  1. Подключитесь к целевому серверу с помощью вторичной конечной точки <fog-name>.secondary.database.windows.net.
  2. Используйте Switch-AzSqlDatabaseFailoverGroup , чтобы переключить вторичный сервер на основной сервер с полной синхронизацией. Эта операция завершается успешно или откатывается.
  3. Убедитесь, что команда выполнена успешно, с помощью nslook up <fog-name>.secondary.database.windows.net. Так можно проверить, ссылается ли запись DNS CNAME на IP-адрес целевого региона. Если команда Switch завершилась неуспешно, запись CNAME не обновляется.

Удаление баз данных-источников

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

  1. Удалите группу отработки отказа с помощью команды Remove-AzSqlDatabaseFailoverGroup.
  2. Удалите базы данных-источники, выполнив команду Remove-AzSqlDatabase для каждой базы данных на исходном сервере. Это автоматически завершает связи георепликации.
  3. Удалите исходный сервер с помощью команды Remove-AzSqlServer.
  4. Удалите хранилище ключей, контейнеры хранилища аудита, концентратор событий, клиент Microsoft Entra и другие зависимые ресурсы, чтобы остановить выставление счетов за них.

Проверка необходимых компонентов для перемещения пула

  1. Создайте целевой сервер для каждого исходного сервера.
  2. Настройте правильные исключения брандмауэра с помощью PowerShell.
  3. Настройте правильные учетные данные для серверов. Если вы не администратор подписки и не администратор сервера, свяжитесь с администратором, чтобы получить необходимые разрешения. Дополнительные сведения см. в разделе Управление безопасностью базы данных SQL после аварийного восстановления.
  4. Если базы данных зашифрованы с помощью прозрачного шифрования данных и в Azure Key Vault используется собственный ключ шифрования, убедитесь в том, что в целевом регионе подготовлен правильный материал шифрования.
  5. Создайте целевой эластичный пул для каждого исходного эластичного пула на том же уровне служб, с таким же именем и размером.
  6. Если включен аудит на уровне базы данных, отключите его и включите аудит на уровне сервера. После отработки отказа аудит на уровне базы данных потребует трафика между регионами, который не требуется или возможен после перемещения.
  7. Для аудита на уровне сервера убедитесь, что:
    • Контейнер хранилища, Log Analytics или концентратор событий с существующими журналами аудита перемещен в целевой регион.
    • Конфигурация аудита настраивается на целевом сервере. Дополнительные сведения см. в статье Аудит базы данных SQL.
  8. Если сервер имеет долгосрочную политику хранения (LTR), существующие резервные копии LTR остаются связанными с текущим сервером. Так как целевой сервер отличается, вы можете получить доступ к старым резервным копиям LTR в исходном регионе с помощью исходного сервера, даже если сервер удаляется.

Примечание.

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

Подготовка к переносу

  1. Создайте отдельную группу отработки отказа между каждым эластичным пулом на исходном сервере и его аналогом на целевом сервере.

  2. Добавьте все базы данных из этого пула в группу отработки отказа. Репликация добавленных баз данных инициируется автоматически. Дополнительные сведения см. в разделе Использование групп отработки отказа с Базой данных SQL.

    Примечание.

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

Мониторинг процесса подготовки

Вы можете периодически вызывать Get-AzSqlDatabaseFailoverGroup для мониторинга репликации баз данных из источника в целевой объект. Выходной объект Get-AzSqlDatabaseFailoverGroup включает свойство для ReplicationState:

  • ReplicationState = 2 (CATCH_UP) указывает, что база данных синхронизирована и для нее можно выполнить безопасную отработку отказа.
  • ReplicationState = 0 (SEEDING) указывает, что база данных еще не заполнена и попытка отработки отказа завершится ошибкой.

Тестирование синхронизации

Когда ReplicationState перейдет в состояние 2, подключитесь к каждой базе данных или подмножеству баз данных с помощью вторичной конечной точки <fog-name>.secondary.database.windows.net и отправьте любой запрос к базам данных, чтобы обеспечить возможность подключения, правильную конфигурацию безопасности и репликацию данных.

Начало перемещения

  1. Подключитесь к целевому серверу с помощью вторичной конечной точки <fog-name>.secondary.database.windows.net.
  2. Используйте Switch-AzSqlDatabaseFailoverGroup , чтобы переключить вторичный сервер на основной сервер с полной синхронизацией. Эта операция выполняется успешно или откатывается.
  3. Убедитесь, что команда выполнена успешно, с помощью nslook up <fog-name>.secondary.database.windows.net. Так можно проверить, ссылается ли запись DNS CNAME на IP-адрес целевого региона. Если команда switch завершается ошибкой, CNAME не обновляется.

Удаление исходных эластичных пулов

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

  1. Удалите группу отработки отказа с помощью команды Remove-AzSqlDatabaseFailoverGroup.
  2. Удалите каждый исходный эластичный пул на исходном сервере с помощью команды Remove-AzSqlElasticPool.
  3. Удалите исходный сервер с помощью команды Remove-AzSqlServer.
  4. Удалите хранилище ключей, контейнеры хранилища аудита, концентратор событий, клиент Microsoft Entra и другие зависимые ресурсы, чтобы остановить выставление счетов за них.

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

Управление базой данных после ее переноса.