Высокая доступность для управляемого экземпляра SQL через Azure Arc

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

Мониторинг здоровья
Обнаружение сбоев
Автоматическое переключение на резерв для поддержания работоспособности сервиса.

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

Monitoring
Обнаружение сбоев
автоматическое переключение при отказе

Служба данных с поддержкой Arc предоставляет эту службу без вмешательства пользователя. Служба:

Настройка группы доступности
Настройка конечных точек зеркального отображения базы данных
Добавляет базы данных в группу доступности
Координирует переключение на запасной вариант и обновление.

В этом документе рассматриваются оба типа высокой доступности.

Управляемый экземпляр SQL, включенный Azure Arc, предоставляет различные уровни высокой доступности в зависимости от того, был ли развернут управляемый экземпляр SQL в качестве уровня службы общего назначения или уровня служб "Критически важный для бизнеса ".

Высокий уровень доступности на уровне служб общего назначения

На уровне служб общего назначения доступно только одна реплика, а высокая доступность достигается с помощью оркестрации Kubernetes. Например, если pod или узел, содержащий образ контейнера управляемого экземпляра, выходит из строя, Kubernetes пытается запустить другой pod или узел и присоединиться к тому же постоянному хранилищу. В это время управляемый экземпляр SQL недоступен для приложений. Приложениям необходимо повторно подключаться и повторить транзакцию, когда новый pod готов к работе. Если load balancer используется тип службы, приложения могут повторно подключиться к той же основной конечной точке, и Kubernetes перенаправит подключение к новой первичной точке. Если тип службы является nodeport , приложениям потребуется повторно подключиться к новому IP-адресу.

Проверка встроенной высокой доступности

Чтобы проверить встроенную высокую доступность, предоставляемую Kubernetes, можно:

Удаление модуля pod существующего управляемого экземпляра
Убедитесь, что Kubernetes восстанавливается после этого действия.

Во время восстановления Kubernetes запускает другой pod и подключит постоянное хранилище.

Prerequisites

Кластер Kubernetes требует общего, удаленного хранилища
Управляемый экземпляр SQL, включенный Azure Arc, развернутый с одной репликой (по умолчанию)

Просмотр модулей pod.

kubectl get pods -n <namespace of data controller>

Удалите модуль pod управляемого экземпляра.

kubectl delete pod <name of managed instance>-0 -n <namespace of data controller>

Например.

user@pc:/# kubectl delete pod sql1-0 -n arc
pod "sql1-0" deleted

Просмотрите модули pod, чтобы убедиться, что управляемый экземпляр восстанавливается.

kubectl get pods -n <namespace of data controller>

Рассмотрим пример.

user@pc:/# kubectl get pods -n arc
NAME                 READY   STATUS    RESTARTS   AGE
sql1-0               2/3     Running   0          22s

После восстановления всех контейнеров в pod можно подключиться к управляемому экземпляру.

Высокая доступность в уровне обслуживания "Критично важный для бизнеса"

Кроме возможностей, изначально предоставляемых оркестрацией Kubernetes, на уровне обслуживания «Критически важный для бизнеса», управляемый экземпляр SQL для Azure Arc предоставляет самодостаточную группу доступности. Содержащаяся группа доступности основана на технологии SQL Server AlwaysOn. Он обеспечивает более высокий уровень доступности. Управляемый экземпляр SQL, поддерживаемый Azure Arc и развернутый с уровнем службы «Критически важный для бизнеса», можно развернуть с 2 или 3 репликами. Эти реплики всегда синхронизируются друг с другом.

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

Автономные группы доступности

Группа доступности привязывает одну или несколько пользовательских баз данных к логической группе, чтобы при отказе вся группа баз данных переключилась на вторичную реплику как единое целое. Группа доступности реплицирует данные только в пользовательских базах данных, но не в системных базах данных, таких как имена входа, разрешения или задания агента. Группа доступности с ограниченным доступом включает метаданные из системных баз данных, таких как базы данных msdb и master. Когда имена входа создаются или изменяются в первичной реплике, они автоматически создаются в вторичных репликах. Аналогичным образом, когда задание агента создается или изменяется в первичной реплике, вторичные реплики также получают эти изменения.

Управляемый экземпляр SQL, под управлением Azure Arc, принимает эту концепцию автономной группы доступности и добавляет оператор Kubernetes, чтобы обеспечить возможность их развертывания и управления в масштабе.

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

При развертывании с несколькими репликами создается одна группа доступности с тем же именем, что и управляемый экземпляр SQL с поддержкой Arc. По умолчанию в автономной группе доступности (Contained AG) три реплики, включая основную. Все операции CRUD для группы доступности обрабатываются автоматически, включая создание группы доступности и присоединение реплик к созданной группе доступности. В экземпляре нельзя создавать больше групп доступности.
Все базы данных автоматически добавляются в группу доступности, включая все пользовательские и системные базы данных, такие как master и msdb. Эта возможность предоставляет единое представление системы для всей группы реплик доступности. Обратите внимание и на базы данных containedag_master и containedag_msdb, если вы подключитесь непосредственно к экземпляру. Базы данных containedag_* представляют master и msdb внутри группы доступности.
Внешняя конечная точка автоматически подготавливается для подключения к базам данных в группе доступности. Эта конечная точка <managed_instance_name>-external-svc играет роль слушателя группы доступности.

Развертывание управляемого экземпляра SQL с поддержкой Azure Arc с несколькими репликами с помощью портала Azure

На портале Azure на странице создания управляемого экземпляра SQL, активированного с помощью Azure Arc:

Выберите "Настроить вычисления и хранилище " в разделе "Вычисления и хранилище". На портале показаны дополнительные параметры.
В разделе "Уровень служб" выберите "Критически важный для бизнеса".
Установите флажок "Только для разработки", если используется для целей разработки.
В разделе "Высокий уровень доступности" выберите 2 реплики или 3 реплики.

Параметры высокой доступности

Развертывание с несколькими репликами с помощью Azure CLI

Если управляемый экземпляр SQL развёрнут при помощи Azure Arc в уровне обслуживания "Критически важный", то развертывание создает несколько реплик. Настройка и конфигурация ограниченных групп доступности среди этих экземпляров выполняется автоматически в ходе развертывания.

Например, следующая команда создает управляемый экземпляр с 3 репликами.

Косвенно подключенный режим:

az sql mi-arc create -n <instanceName> --k8s-namespace <namespace> --use-k8s --tier <tier> --replicas <number of replicas>

Example:

az sql mi-arc create -n sqldemo --k8s-namespace my-namespace --use-k8s --tier BusinessCritical --replicas 3

Режим прямого подключения:

az sql mi-arc create --name <name> --resource-group <group>  --location <Azure location> –subscription <subscription>  --custom-location <custom-location> --tier <tier> --replicas <number of replicas>

Example:

az sql mi-arc create --name sqldemo --resource-group rg  --location uswest2 –subscription xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --custom-location private-location --tier BusinessCritical --replcias 3

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

Просмотр и мониторинг состояния высокой доступности

После завершения развертывания подключитесь к основной конечной точке из SQL Server Management Studio.

Проверьте и получите конечную точку первичной реплики и подключитесь к ней из SQL Server Management Studio. Например, если экземпляр SQL был развернут с помощью service-type=loadbalancer, выполните следующую команду, чтобы получить конечную точку для подключения:

az sql mi-arc list --k8s-namespace my-namespace --use-k8s

kubectl get sqlmi -A

Получите основные и вторичные конечные точки и состояние группы доступности.

Используйте команды kubectl describe sqlmi или az sql mi-arc show для просмотра основных и вторичных конечных точек, а также состояния высокой доступности.

Example:

kubectl describe sqlmi sqldemo -n my-namespace

az sql mi-arc show --name sqldemo --k8s-namespace my-namespace --use-k8s

Пример результатов, ваши результаты будут различаться

 "status": {
    "endpoints": {...
      "mirroring": "10.15.100.150:5022",
      "primary": "10.15.100.150,1433",
      "secondary": "10.15.100.156,1433"
    },
    "highAvailability": {
      "healthState": "OK",
      "mirroringCertificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
    },
    "observedGeneration": 1,
    "readyReplicas": "2/2",
    "state": "Ready"
  }

Вы можете подключиться к основной конечной точке с помощью SQL Server Management Studio и проверить служебные представления (DMV) следующим образом:

SELECT * FROM sys.dm_hadr_availability_replica_states

Группа доступности

И панель мониторинга локальной доступности:

Панель мониторинга группы доступности контейнеров

Сценарии переключения на резерв

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

Развертывание управляемых экземпляров SQL уровня "Критически важный для бизнеса" в конфигурации двух реплик или трех реплик. Последствия сбоев и последующей возможности восстановления отличаются при каждой конфигурации. Три экземпляра реплики обеспечивают более высокий уровень доступности и восстановления, чем два экземпляра реплики.

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

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

Note

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

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

При подключении к основному экземпляру SQL, вы можете использовать следующий T-SQL для переключения экземпляра SQL на один из вторичных серверов.

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

При подключении ко вторичной реплике можно использовать следующий T-SQL для перевода нужной вторичной реплики в первичную.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Предпочитаемая первичная реплика

Можно также задать конкретную реплику в качестве основной реплики с помощью AZ CLI следующим образом:

az sql mi-arc update --name <sqlinstance name> --k8s-namespace <namespace> --use-k8s --preferred-primary-replica <replica>

Example:

az sql mi-arc update --name sqldemo --k8s-namespace my-namespace --use-k8s --preferred-primary-replica sqldemo-3

Note

Kubernetes попытается установить предпочтительную реплику, однако это не гарантируется.

Восстановление базы данных в экземпляре с несколькими репликами

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

Открытие внешней конечной точки первичного экземпляра путем создания новой службы Kubernetes.

Определите модуль pod, на котором размещена первичная реплика. Подключитесь к управляемому экземпляру и выполните следующую команду:
```
SELECT @@SERVERNAME
```
Запрос возвращает pod, на котором размещена первичная реплика.

Создайте службу Kubernetes для основной инстанции, применив следующую команду, если ваш кластер Kubernetes использует NodePort службы. Замените <podName> именем сервера, возвращаемого на предыдущем шаге, <serviceName> предпочтительным именем созданной службы Kubernetes.
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
```
Для службы LoadBalancer выполните ту же команду, за исключением того, что тип создаваемой службы — LoadBalancer. Рассмотрим пример.
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
```
Ниже приведен пример выполнения этой команды в службе Azure Kubernetes, где pod, на котором размещен основной sql2-0, является основным хостом.
```
kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
```
Получите IP-адрес созданной службы Kubernetes:
```
kubectl get services -n <namespaceName>
```

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

Добавьте файл резервной копии базы данных в контейнер основного экземпляра.

kubectl cp <source file location> <pod name>:var/opt/mssql/data/<file name> -c <serviceName> -n <namespaceName>

Example

kubectl cp /home/WideWorldImporters-Full.bak sql2-1:var/opt/mssql/data/WideWorldImporters-Full.bak -c arc-sqlmi -n arc

Восстановите файл резервной копии базы данных, выполнив приведенную ниже команду.

RESTORE DATABASE test FROM DISK = '/var/opt/mssql/data/<file name>.bak'
WITH MOVE '<database name>' to '/var/opt/mssql/data/<file name>.mdf'  
,MOVE '<database name>' to '/var/opt/mssql/data/<file name>_log.ldf'  
,RECOVERY, REPLACE, STATS = 5;  
GO

Example

RESTORE Database WideWorldImporters
FROM DISK = '/var/opt/mssql/data/WideWorldImporters-Full.BAK'
WITH
MOVE 'WWI_Primary' TO '/var/opt/mssql/data/WideWorldImporters.mdf',
MOVE 'WWI_UserData' TO '/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
MOVE 'WWI_Log' TO '/var/opt/mssql/data/WideWorldImporters.ldf',
MOVE 'WWI_InMemory_Data_1' TO '/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
RECOVERY, REPLACE, STATS = 5;  
GO

Добавьте базу данных в группу доступности.

Чтобы добавить базу данных в группу доступности, она должна работать в режиме полного восстановления, и необходимо выполнить резервное копирование журнала. Выполните приведенные ниже инструкции TSQL, чтобы добавить восстановленную базу данных в группу доступности.
```
ALTER DATABASE <databaseName> SET RECOVERY FULL;
BACKUP DATABASE <databaseName> TO DISK='<filePath>'
ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
```
В следующем примере добавляется база данных с именем WideWorldImporters, которая была восстановлена на экземпляре:
```
ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
```

Important

Рекомендуется удалить службу Kubernetes, созданную выше, выполнив следующую команду:

kubectl delete svc sql2-0-p -n arc

Limitations

Управляемый экземпляр SQL, включенный группами доступности Azure Arc, имеет те же ограничения, что и группы доступности кластера больших данных. Дополнительные сведения см. в статье "Развертывание кластера больших данных SQL Server с высоким уровнем доступности".

Дополнительные сведения о функциях и возможностях управляемого экземпляра SQL, включенные в Azure Arc

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-01-13

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

Высокая доступность для управляемого экземпляра SQL через Azure Arc

Высокий уровень доступности на уровне служб общего назначения

Проверка встроенной высокой доступности

Prerequisites

Высокая доступность в уровне обслуживания "Критично важный для бизнеса"

Автономные группы доступности

Развертывание управляемого экземпляра SQL с поддержкой Azure Arc с несколькими репликами с помощью портала Azure

Развертывание с несколькими репликами с помощью Azure CLI

Просмотр и мониторинг состояния высокой доступности

Получите основные и вторичные конечные точки и состояние группы доступности.

Сценарии переключения на резерв

Предпочитаемая первичная реплика

Восстановление базы данных в экземпляре с несколькими репликами

Limitations

Связанный контент

Обратная связь

Дополнительные ресурсы