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

Надежность в Базе данных SQL Azure

База данных SQL Azure — это полностью управляемая платформа как служба (PaaS), которая обрабатывает большинство функций управления базами данных, таких как обновление, исправление, резервное копирование и мониторинг без участия пользователя.

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

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

Рекомендации по развертыванию в производственной среде

Сведения о том, как развернуть базу данных SQL Azure для поддержки требований к надежности решения, а также о том, как надежность влияет на другие аспекты архитектуры, ознакомьтесь с рекомендациями по архитектуре базы данных SQL Azure в Azure Well-Architected Framework.

Обзор архитектуры надежности

База данных SQL выполняется на последнем стабильном ядре СУБД SQL Server операционной системы Windows, включая все применимые исправления.

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

  • Операции управления, инициированные клиентом, которые приводят к краткому простою

  • Операции обслуживания сервиса

  • Проблемы и сбои центра обработки данных, в которых центр обработки данных имеет следующие компоненты:

    • Стойки, на которых работают машины, обеспечивающие вашу службу

    • Физические машины, на которых размещена виртуальная машина, на которой запущен ядро СУБД SQL

  • Другие проблемы с ядром СУБД SQL

  • Другие потенциальные незапланированные локализованные сбои

База данных SQL использует Azure Service Fabric для управления репликацией базы данных.

Избыточность реализуется различными способами для разных уровней служб базы данных SQL. Дополнительную информацию см. в статье "Доступность с использованием избыточности - База данных SQL".

Устойчивость к временным сбоям

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

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

База данных SQL автоматически обрабатывает критически важные задачи обслуживания, такие как исправление, резервные копии, обновления ядра СУБД Windows и SQL. Он также автоматически обрабатывает незапланированные события, такие как базовое оборудование, программное обеспечение или сбои сети. База данных SQL предназначена для быстрого восстановления после критических сбоев, что гарантирует доступность данных. Большинство пользователей не замечают, что обновления выполняются непрерывно.

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

Вы можете проверить устойчивость приложения к временным сбоям, следуя инструкциям в руководстве по устойчивости тестового приложения.

Устойчивость к сбоям зоны доступности

Зоны доступности — это физически отдельные группы центров обработки данных в регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.

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

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

Для уровней обслуживания "Премиум", "Критически важный для бизнеса" и "Гипермасштабирование" механизм зональной избыточности размещает реплики базы данных SQL в нескольких зонах доступности Azure в основном регионе. Чтобы уменьшить вероятность возникновения единой точки отказа (SPOF), кольцо управления дублируется в нескольких зонах доступности.

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

Требования

Сервисные уровни "Базовый" и "Стандартный" не поддерживают резервирование зон.

Избыточность зоны доступна базам данных в уровнях служб "Критически важный для бизнеса", "Общего назначения" и "Гипермасштабирование" модели приобретения на основе виртуальных ядер, а также только на уровне служб "Премиум" модели приобретения на основе DTU.

Для уровня служб общего назначения:

Для уровней служб "Премиум" и "Критически важный для бизнеса":

Для уровня служб гипермасштабирования:

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

Соображения

  • Задержка: Зонально избыточные базы данных имеют реплики в отдельных центрах обработки данных. Добавленная задержка сети может увеличить время фиксации транзакций и потенциально повлиять на производительность определенных рабочих нагрузок обработки транзакций в сети (OLTP). Большинство приложений не учитывает эту дополнительную задержку.

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

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

Себестоимость

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

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

Если включить несколько реплик базы данных в уровне Hyperscale, можно включить зональную избыточность. При включении резервирования зоны реплики распределяются между зонами доступности. Это распределение означает, что в базе данных SQL в уровне обслуживания Hyperscale, при наличии нескольких реплик, не связано дополнительных затрат на включение избыточности зоны.

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

Настройка поддержки зоны доступности

Для уровней служб "Общего назначения", "Премиум" и "Критически важный для бизнеса":

Для уровня служб гипермасштабирования:

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

Поведение, когда все зоны работоспособны

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

Для уровня служб общего назначения:

  • Маршрутизация трафика между зонами: Запросы направляются на узел, на котором выполняется вычислительный слой базы данных SQL. Если включено резервирование зоны, узел может находиться в любой зоне доступности.

  • Репликация данных между зонами: Файлы данных и журналов синхронно реплицируются в зонах доступности с помощью ZRS. Операции записи не считаются завершенными, пока данные не будут успешно реплицированы во всех зонах доступности. Эта синхронная репликация обеспечивает высокую согласованность и нулевую потерю данных во время сбоев зоны. Однако это может привести к немного более высокой задержке записи по сравнению с локальным избыточным хранилищем (LRS).

Для уровней служб "Премиум" и "Критически важный для бизнеса":

  • Маршрутизация трафика между зонами: Реплики распределяются между зонами доступности, и одна из этих реплик назначается в качестве основной реплики. Запросы направляются в первичную реплику базы данных.

  • Репликация данных между зонами: Первичная реплика постоянно отправляет изменения во вторичные реплики последовательно, чтобы обеспечить сохранение данных на достаточном количестве вторичных реплик перед фиксацией каждой транзакции. Этот процесс гарантирует, что если первичная реплика или доступная для чтения вторичная реплика становится недоступной по какой-либо причине, полностью синхронизированная реплика всегда доступна для переключения на резерв. Если включена избыточность по зонам, эти реплики находятся в разных зонах доступности. Однако процесс может привести к немного более высокой задержке записи из-за задержки сети в зонах обхода.

Для уровня служб гипермасштабирования:

  • Маршрутизация трафика между зонами: Реплики баз данных распределяются между зонами доступности, а одна из этих реплик — основной репликой. Запросы направляются в первичную реплику базы данных.

  • Репликация данных между зонами: Реплика базы данных-источника отправляет изменения через службу журналов, избыточной между зонами, которая реплицирует все изменения синхронно в зонах доступности. Серверы страниц находятся в каждой зоне доступности и хранят состояние базы данных. Этот процесс гарантирует, что если первичная реплика или читаемая вторичная реплика становится недоступной по какой-либо причине, полностью синхронизированная реплика всегда доступна для переключения при отказе. Однако процесс может привести к немного более высокой задержке записи по сравнению с LRS.

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

Поведение во время сбоя зоны

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

  • Обнаружение и ответ: База данных SQL отвечает за обнаружение и реагирование на сбой в зоне доступности. Вам не нужно ничего делать, чтобы инициировать переключение зоны.
  • Активные запросы: Когда зона доступности переходит в автономный режим, все запросы, обрабатываемые в неисправной зоне доступности, завершаются и должны быть извлечены. Дополнительные сведения о том, как сделать приложения устойчивыми к этим типам проблем, см. в руководстве по устойчивости к временным сбоям .

  • Перенаправка трафика: Для уровня служб общего назначения база данных SQL перемещает ядро СУБД в другой вычислительный узел без сохранения состояния, который находится в другой зоне доступности и имеет достаточную свободную емкость. После завершения отработки отказа новые подключения автоматически перенаправляются на новый первичный вычислительный узел.

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

  • Перенаправка трафика: Для уровней служб "Премиум" и "Критически важный для бизнеса" база данных SQL выбирает реплику в другой зоне доступности, чтобы стать основной репликой. После того как вторичная реплика станет новой первичной репликой, создается другая вторичная реплика, чтобы убедиться, что кластер имеет достаточное количество реплик для поддержания кворума. После завершения переключения новые подключения автоматически перенаправляются к новой основной реплике (или вторичной реплике с поддержкой чтения на основе строки подключения).

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

  • Перенаправка трафика: Для уровня обслуживания Hyperscale, если основная реплика была утрачена из-за сбоя зоны, база данных SQL назначает одну из реплик высокой доступности в другой зоне в качестве новой основной.

    Дополнительные сведения см. на гипермасштабном уровне обслуживания.

  • Ожидаемое время простоя: Во время отработки отказа зоны доступности может потребоваться небольшое время простоя. Время простоя обычно меньше 30 секунд, которое приложение должно терпеть, если оно соответствует рекомендациям по устойчивости к временным сбоям .

  • Ожидаемая потеря данных: Во время отработки отказа зоны доступности не ожидается потеря данных.

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

Восстановление зоны

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

Тестирование на сбои в зоне

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

Устойчивость к сбоям на уровне региона

В этом разделе представлен обзор двух связанных, но отдельных функций, которые можно использовать для георепликации базы данных SQL в нескольких регионах:

Активная георепликация

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

Требования

При использовании активной георепликации учитывайте следующие требования:

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

    Подсказка

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

  • Конфигурации: Основной и гео-вторичный должны иметь один и тот же уровень служб и должен иметь один и тот же уровень вычислений, размер вычислительных ресурсов и избыточность хранилища резервных копий.

  • Брандмауэр: Как основной, так и гео-вторичный должны иметь одинаковые правила IP-адресов брандмауэра.

  • Подписки Azure: Активная георепликация поддерживается для баз данных в разных подписках Azure.

Соображения

  • Активная георепликация предназначена для обеспечения аварийного переключения отдельной базы данных. Если необходимо переключить на резерв несколько баз данных, рекомендуется использовать группы отказоустойчивости.

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

  • Дополнительные сведения об ограничениях и рекомендациях см. в разделе "Активная георепликация".

Себестоимость

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

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

Настройка поддержки нескольких регионов

Поведение, когда все регионы работоспособны

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

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

  • Репликация данных между регионами: Репликация между базами данных-источником и вторичными базами данных выполняется асинхронно, что означает, что между моментом применения изменения к базе данных-источнику и репликацией в базу данных-получатель может возникнуть задержка.

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

Поведение во время сбоя региона

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

  • Обнаружение и ответ: Вы несете ответственность за обнаружение сбоя базы данных или региона и запуск процедуры переключения на резервную систему.

  • Активные запросы: Все активные запросы во время резервного перехода завершаются и должны быть повторно выполнены.

  • Ожидаемая потеря данных: Если основная база данных доступна, вы можете выполнить переключение на резервную базу данных без потери данных. Процесс переключения при отказе синхронизирует данные между основными и вторичными базами данных перед переключением ролей.

    Если основная база данных недоступна, может потребоваться выполнить принудительное переключение, что приводит к потере данных. Вы можете оценить объем потери данных, отслеживая задержку репликации. Дополнительные сведения см. в разделе "Мониторинг базы данных SQL" с помощью метрик и оповещений.

  • Ожидаемое время простоя: Обычно во время переключения в случае отказа время простоя составляет до 60 секунд. Убедитесь, что приложение обрабатывает временные ошибки , чтобы он смог восстановиться с коротких периодов простоя. Кроме того, то, как быстро вы перенастроите ваше приложение для подключения к новой основной базе данных, влияет на время простоя, которое вы испытываете.

  • Перенаправка трафика: Вы несете ответственность за перенастройку приложения для отправки запросов в новую базу данных-источник. Если требуется прозрачное переключение на резерв, рассмотрите возможность использования групп переключения на резерв.

Восстановление региона

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

Проверка сбоев в регионе

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

Группы переключения при отказе

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

  • Репликация набора баз данных с одного логического сервера в любом сочетании регионов Azure.

  • Выполните переключение при отказе на базах данных как на группу.

  • Используйте конечные точки подключения, которые автоматически направляют подключения к основному объекту.

Требования

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

    Подсказка

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

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

Соображения

  • Избыточность зоны: Для уровня служб гипермасштабирования, если основная база данных имеет избыточность зоны, то вторичные базы данных автоматически включают избыточность зоны.
  • Избыточность зоны: Вторичные базы данных по умолчанию не поддерживают избыточность зоны, но её можно включить позже.

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

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

Себестоимость

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

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

Настройка поддержки нескольких регионов

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

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

    Это важно

    Аварийное переключение, инициированное Microsoft, скорее всего, произойдет после значительной задержки и выполняется в меру возможностей. Отказоустойчивое переключение баз данных может происходить в другое время, чем переключение других служб Azure. Подробности см. в разделе "Настройка группы отказоустойчивости для базы данных SQL".

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

  • Отключить группы отработки отказа: Вы можете удалить отдельную базу данных из группы отработки отказа, удалить всю группу отработки отказа или переместить базу данных в другую группу отработки отказа.

Поведение, когда все регионы работоспособны

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

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

    • Конечная точка прослушивателя чтения и записи направляет все запросы к основным базам данных.

    • Конечная точка прослушивателя только для чтения направляет все запросы к читаемой вторичной базе данных.

  • Репликация данных между регионами: Георепликация между первичными и вторичными базами данных выполняется асинхронно. Эта задержка означает, что между изменением, применяемым к базе данных-источнику, и при репликации в базу данных-получатель может возникнуть задержка.

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

Поведение во время сбоя региона

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

  • Обнаружение и реагирование зависят от используемой политики отработки отказа.

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

    • Переключение на резервный, инициированное корпорацией Майкрософт: Корпорация Майкрософт активирует переключение на резервный для всех групп переключений на резервный в затронутом регионе. Корпорация Майкрософт ожидает, что переключение при отказе будет выполняться только в исключительных ситуациях. Не полагайтесь на управляемую Microsoft отработку отказа для большинства решений. Дополнительные сведения см. в статье о политике отработки отказа — управляемая корпорацией Майкрософт.

  • Активные запросы: Все активные запросы во время резервного перехода завершаются и должны быть повторно выполнены.

  • Ожидаемая потеря данных: Потеря данных зависит от используемой политики резервного копирования.

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

      Если основная база данных недоступна, может потребоваться выполнить принудительное переключение, что приводит к потере данных. Вы можете оценить объем потери данных, отслеживая задержку репликации. Дополнительные сведения см. в разделе "Мониторинг базы данных SQL" с помощью метрик и оповещений.

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

  • Ожидаемое время простоя: Время простоя зависит от используемой политики отработки отказа.

    • Отказоустойчивость, инициированная клиентом: Обычно при переключении происходит простой продолжительностью до 60 секунд. Убедитесь, что приложение обрабатывает временные ошибки , чтобы он смог восстановиться с коротких периодов простоя.

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

  • Перенаправка трафика: Во время переключения на резервный ресурс база данных SQL обновляет точки доступа для чтения и записи, а также только для чтения, чтобы направлять трафик к новым основным и вторичным базам данных по мере необходимости.

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

Восстановление региона

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

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

Проверка сбоев в регионе

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

Резервное копирование и восстановление

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

База данных SQL предоставляет автоматические резервные копии баз данных. Дополнительные сведения о частоте резервного копирования, которая может повлиять на объем потери данных при необходимости восстановления из резервной копии, см. в статье "Автоматизированные резервные копии" в базе данных SQL.

Хранилище резервных копий

Вы можете сохранить автоматические резервные копии в LRS или ZRS. Если вы используете связанный регион, вы можете копировать автоматические резервные копии в этот регион, используя геоизбыточное хранилище. Эта функция позволяет геовосстановление ваших резервных копий в парном регионе. Дополнительные сведения см. в статье "Автоматическое резервное копирование" в базе данных SQL.

Если вы используете непарный регион или вам нужно реплицировать резервные копии в регион, который не совпадает с парным регионом, рассмотрите возможность экспорта базы данных и хранения экспортированного файла в учетной записи хранения, которая использует репликацию блоб-объектов для репликации в учетную запись хранения в другом регионе. Дополнительные сведения см. в разделе "Экспорт базы данных".

Устойчивость к обслуживанию служб

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

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

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

Дополнительные сведения см. в разделе "Период обслуживания" в базе данных SQL.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

Соглашение об уровне обслуживания (SLA) для базы данных SQL описывает ожидаемую доступность службы и ожидаемую точку восстановления и время восстановления для активной георепликации.

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

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

  • Last updated on