Планирование событий обслуживания Azure в Базе данных SQL AzurePlanning for Azure maintenance events in Azure SQL Database

Узнайте, как подготовиться к событиям планового обслуживания в базе данных SQL Azure.Learn how to prepare for planned maintenance events on your Azure SQL database.

Что такое событие планового обслуживанияWhat is a planned maintenance event

Для каждой базы данных служба "База данных SQL Azure" обеспечивает кворум реплик базы данных, в котором одна реплика является первичной.For each database, Azure SQL DB maintains a quorum of database replicas where one replica is the primary. Первичная реплика всегда должна быть в режиме онлайн-обслуживания, и хотя бы одна вторичная реплика должна быть исправной.At all times a primary replica must be online servicing, and at least one secondary replica must be healthy. Во время планового обслуживания участники кворума базы данных будут переходить в автономный режим по одному, соблюдая условие наличия одной первичной реплики, отвечающей на запросы, и по крайней мере одной подключенной вторичной реплики, чтобы предотвратить простой клиента.During planned maintenance, members of the database quorum will go offline one at a time, with the intent that there is one responding primary replica and at least one secondary replica online to ensure no client downtime. Когда первичную реплику необходимо перевести в автономный режим, возникнет процесс перенастройки или отработки отказа, в результате которого одна вторичная реплика станет новой первичной.When the primary replica needs to be brought offline, a reconfiguration/failover process will occur in which one secondary replica will become the new primary.

Что происходит во время события планового обслуживанияWhat to expect during a planned maintenance event

Операции перенастройки или отработки отказа обычно завершаются в течение 30 секунд (в среднем — в течение 8).Reconfigurations/failovers generally complete within 30 seconds – the average is 8 seconds. Если ваше приложение уже подключено, оно должно заново подключиться к работоспособной копии новой первичной реплики базы данных.If already connected, your application must reconnect to the healthy copy new primary replica of your database. Если при попытке выполнить новое подключение происходит перенастройка базы данных до того, как новая первичная реплика будет подключена к сети, возникает ошибка 40613 (база данных недоступна): "база данных" {DatabaseName} "на сервере" {servername} "в настоящее время недоступна.If a new connection is attempted while the database is undergoing a reconfiguration before the new primary replica is online, you get error 40613 (Database Unavailable): “Database '{databasename}' on server '{servername}' is not currently available. Повторите попытку подключения позже".Please retry the connection later.”. Если в базе данных есть длительный запрос, он будет прерван во время перенастройки и его нужно будет перезапустить.If your database has a long running query, this query will be interrupted during a reconfiguration and will need to be restarted.

Логика повторных попытокRetry Logic

Для любого клиентского приложения в рабочей среде, которое подключается к облачной службе базы данных, следует реализовать надежную логику повторных попыток подключения.Any client production application that connects to a cloud database service should implement a robust connection retry logic. Она поможет устранить такие ситуации и упрощает общий механизм определения ошибок для пользователя.This will help mitigate these situations and should generally make the errors transparent to the end user.

FrequencyFrequency

В среднем каждый месяц происходят 1,7 событий планового обслуживания.On average, 1.7 planned maintenance events occur each month.

Работоспособность ресурсаResource Health

Если в базе данных SQL возникли ошибки входа, на портале Azure просмотрите окно Работоспособность ресурсов, чтобы узнать текущее состояние.If your SQL database is experiencing login failures, check the Resource Health window in the Azure portal for the current status. Раздел "Работоспособность ресурсов" содержит причину простоя для каждого события (если она доступна).The Health History section contains the downtime reason for each event (when available).

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