Высокий уровень доступности (надежность) в Azure Cosmos DB для NoSQL
В этой статье описывается поддержка высокой доступности (надежности) в Azure CosmosDB для NoSQL и охватывает обе зоны доступности, а также аварийное восстановление между регионами и непрерывность бизнес-процессов.
Общие рекомендации по устойчивости Для Azure Cosmos DB для NoSQL см . в рекомендациях по устойчивости для Azure Cosmos DB для NoSQL.
Поддержка зоны доступности
Зоны доступности Azure — это по крайней мере три физически отдельные группы центров обработки данных в каждом регионе Azure. Центры обработки данных в каждой зоне оснащены независимой питанием, охлаждения и сетевой инфраструктурой. В случае сбоя локальной зоны зоны зоны создаются таким образом, чтобы при возникновении влияния одной зоны, региональных служб, емкости и высокой доступности поддерживались остальными двумя зонами.
Сбои могут варьироваться от сбоев программного обеспечения и оборудования до таких событий, как землетрясения, наводнения и пожары. Устойчивость к сбоям достигается с избыточностью и логической изоляцией служб Azure. Дополнительные сведения о зонах доступности в Azure см. в разделе "Регионы и зоны доступности".
Службы с поддержкой зон доступности Azure предназначены для обеспечения правильного уровня надежности и гибкости. Их можно настроить двумя способами. Они могут быть избыточными по зонам с автоматическим реплика tion между зонами или зональными экземплярами, закрепленными в определенной зоне. Эти подходы также можно объединить. Дополнительные сведения об зональной архитектуре, избыточной между зонами, см. в Рекомендации использования зональных зон и регионов.
Azure Cosmos DB — это мультитенантная служба, которая прозрачно управляет всеми деталями отдельных вычислительных узлов. Вам не нужно беспокоиться о каком-либо исправлении или плановом обслуживании. Azure Cosmos DB гарантирует соглашения об уровне обслуживания для доступности и задержки P99 через все операции автоматического обслуживания, выполняемые системой.
Предложения Azure Cosmos DB:
Устойчивость отдельных узлов. Azure Cosmos DB автоматически устраняет реплика сбоя, гарантируя по крайней мере три реплика данных в каждом регионе Azure для учетной записи в пределах четырех реплика кворума. Это гарантирует, что RTO 0 и RPO 0 для отдельных сбоев узлов не требуют изменений или конфигураций приложения.
Устойчивость к сбоям в зонах. При развертывании учетной записи Azure Cosmos DB с помощью зон доступности Azure Cosmos DB предоставляет RTO 0 и RPO 0 даже в сбоях зоны. Сведения о RTO см. в разделе "Цели восстановления".
С включенными зонами доступности Azure Cosmos DB для NoSQL поддерживает конфигурацию, резервную для зоны.
Необходимые компоненты
Ваши реплика должны быть развернуты в регионе Azure, поддерживающем зоны доступности. Чтобы узнать, поддерживает ли ваш регион зоны доступности, см . список поддерживаемых регионов.
Определите, добавляют ли зоны доступности достаточное значение в текущую конфигурацию в зависимости от использования зон доступности.
Влияние использования зон доступности
Влияние зон доступности на высокий уровень доступности базы данных Cosmos DB для NoSQL зависит от уровня согласованности учетной записи и регионов с включенными зонами доступности. Во многих случаях зоны доступности не добавляют значение или добавляют минимальное значение, если учетная запись является несколькими регионами (если она не настроена с строгой согласованности).
Ознакомьтесь со следующей таблицей, чтобы оценить влияние использования зон доступности в конфигурации текущей учетной записи:
| Уровень согласованности учетной записи | Регионы с включенными зонами доступности | Влияние использования зон доступности |
|---|---|---|
| Асинхронная (ограниченная устаревшая или слабая) | Любое количество дополнительных регионов чтения. | Предоставляет минимальное значение, так как пакет SDK уже предоставляет простое перенаправление для операций чтения при сбое региона чтения. |
| Синхронная (строгая) | Два или более дополнительных регионов чтения | Предоставляет маргинальное значение, так как система может использовать динамический кворум, если регион чтения теряет доступность, что позволяет продолжить запись. |
| Синхронная (строгая) | Один дополнительный регион чтения | Предоставляет большее значение, так как потеря региона чтения в этом сценарии может повлиять на доступность записи. |
| Все | Запись регионов и любое количество дополнительных регионов | Обеспечивает большую доступность операций записи для зональных сбоев. |
| Все | Один регион | Один регион не может воспользоваться возможностью отработки отказа в нескольких регионах. Использование зон доступности защищает от полной потери доступности из-за зонального сбоя. |
Улучшения обслуживания
Так как зоны доступности физически отделены и предоставляют различные источники питания, сети и охлаждения, соглашения об уровне обслуживания (соглашения об уровне обслуживания) выше (99,995%) чем учетные записи с одним регионом (99,99%). Регионы, в которых включены зоны доступности, взимается плата за 25 % премиум, а без них без зон доступности не взимается плата за премиум. Кроме того, цены на категории "Премиум" для зон доступности отменяются для учетных записей, настроенных с помощью операций записи в нескольких регионах и (или) для коллекций, настроенных в режиме автомасштабирования.
Добавление дополнительного региона в учетную запись Cosmos DB обычно увеличивает существующий счет на 100 % (аддитивно не умножательно), хотя небольшие варианты затрат в разных регионах существуют. Дополнительные сведения см . на странице цен.
Включение AZ, добавление дополнительных регионов или включение операций записи с несколькими регионами можно рассматривать как подход к наложению, который повышает устойчивость и доступность определенной учетной записи Cosmos DB на каждом шаге пути — от 4 9 до 4 9 для конфигурации без АЗ, до 4 и половины 9 для одного региона с AZs, вплоть до 5 9 доступности для конфигурации с несколькими регионами с включенным параметром записи в нескольких регионах. См. следующую таблицу, чтобы получить сводку об уровне обслуживания для каждой конфигурации.
| КПЭ | Запись в один регион без зон доступности | Запись в одном регионе с зонами доступности | Запись в нескольких регионах без зон доступности | Запись в нескольких регионах с зонами доступности | Создание нескольких регионов с несколькими регионами с зонами доступности или без них |
|---|---|---|---|---|---|
| Соглашение об уровне обслуживания для доступности записи | 99,99 % | 99.995% | 99,99 % | 99.995% | 99,999 % |
| Соглашение об уровне обслуживания для чтения | 99,99 % | 99.995% | 99,999 % | 99,999 % | 99,999 % |
| Сбои зоны: потеря данных | Потеря данных | Без потери данных | Без потери данных | Без потери данных | Без потери данных |
| Сбои зоны: доступность | Потери доступности | Без потерь доступности | Без потерь доступности | Без потерь доступности | Без потерь доступности |
| Региональный сбой: потеря данных | Потеря данных | Потеря данных | Зависит от уровня согласованности. Дополнительные сведения см. в разделе "Согласованность", "Доступность" и "Компромиссы по производительности". | Зависит от уровня согласованности. Дополнительные сведения см. в разделе "Согласованность", "Доступность" и "Компромиссы по производительности". | Зависит от уровня согласованности. Дополнительные сведения см. в разделе "Согласованность", "Доступность" и "Компромиссы по производительности". |
| Региональный сбой: доступность | Потери доступности | Потери доступности | Нет потерь доступности при сбое региона чтения, временном сбое для области записи | Нет потерь доступности при сбое региона чтения, временном сбое для области записи | Отсутствие потери доступности чтения, временная потеря доступности записи в затронутом регионе |
| Цена (1) | Нет данных | Скорость подготовки единиц запросов в секунду (x 1,25) | Подготовленные регионы ЕЗ/с x N | Подготовленные ЕЗ/с x 1,25 частоты x N (2) | Скорость записи в нескольких регионах x N |
1 Для бессерверных учетных записей ЕЗ умножаются на коэффициент 1,25.
2 Ставка 1.25 применяется только к регионам, в которых можно включить зоны доступности.
Создание ресурса с включенными зонами доступности
Зоны доступности можно настроить только при добавлении нового региона в учетную запись NoSQL Azure Cosmos DB.
Чтобы включить поддержку зоны доступности, можно использовать следующее:
Поддержка перехода на зоны доступности
Сведения о переносе учетной записи Cosmos DB в поддержку зоны доступности см. в статье "Миграция Azure Cosmos DB для NoSQL в поддержку зоны доступности").
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (АВАРИЙНОе восстановление) заключается в восстановлении из событий высокой нагрузки, таких как стихийные бедствия или неудачные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем начать думать о создании плана аварийного восстановления, ознакомьтесь с Рекомендации для разработки стратегии аварийного восстановления.
Когда дело доходит до аварийного восстановления, корпорация Майкрософт использует модель общей ответственности. В модели общей ответственности корпорация Майкрософт гарантирует, что доступны базовые службы инфраструктуры и платформы. В то же время многие службы Azure не автоматически реплика te данные или возвращаются из неудающегося региона, чтобы перекрестно реплика te в другой включенный регион. Для этих служб вы несете ответственность за настройку плана аварийного восстановления, который работает для рабочей нагрузки. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления, и вы можете использовать специальные функции службы для поддержки быстрого восстановления для разработки плана аварийного восстановления .
Сбои регионов — это сбои, влияющие на все узлы Azure Cosmos DB в регионе Azure во всех зонах доступности. В редких случаях сбоя регионов можно настроить Azure Cosmos DB для поддержки различных результатов устойчивости и доступности.
Устойчивость
При развертывании учетной записи Azure Cosmos DB в одном регионе обычно не происходит потери данных. Доступ к данным восстанавливается после восстановления служб Azure Cosmos DB в затронутом регионе. Потеря данных может возникать только с неустранимой катастрофой в регионе Azure Cosmos DB.
Чтобы обеспечить защиту от полной потери данных, которая может привести к катастрофическим авариям в регионе, Azure Cosmos DB предоставляет два режима резервного копирования:
- Непрерывные резервные копии резервного копирования каждого региона каждые 100 секунд. Они позволяют восстанавливать данные в любой момент времени с 1-секундной степенью детализации. Резервное копирование в каждом регионе зависит от данных в этом регионе. Если в регионе включена зона доступности, резервная копия хранится в учетных записях хранения, избыточных между зонами.
- Периодические резервные копии полностью резервного копирования всех секций из всех контейнеров в учетной записи без синхронизации между секциями. Минимальный интервал резервного копирования составляет 1 час.
При развертывании учетной записи Azure Cosmos DB в нескольких регионах устойчивость данных зависит от уровня согласованности, настроенного в учетной записи. В следующей таблице приведены сведения обо всех уровнях согласованности, RPO учетной записи Azure Cosmos DB, развернутой по крайней мере в двух регионах.
| Уровень согласованности | RPO для сбоя региона |
|---|---|
| Сеанс, согласованный префикс, в конечном итоге | Менее 15 минут |
| Ограниченное устаревание | K и T |
| Строгие | 0 |
K = количество версий (т. е. обновлений) элемента.
T = интервал времени с момента последнего обновления.
Для учетных записей с несколькими регионами минимальное значение K и T составляет 100 000 операций записи или 300 секунд. Это значение определяет минимальное значение RPO для данных при использовании ограниченной устаревших значений.
Дополнительные сведения о различиях между уровнями согласованности см. в разделе "Уровни согласованности" в Azure Cosmos DB.
Отработка отказа управляемой службы
Если для решения требуется непрерывное время простоя во время сбоя регионов, можно настроить Azure Cosmos DB для реплика размещения данных в нескольких регионах и прозрачного отработки отказа в рабочие регионы при необходимости.
Учетные записи с одним регионом могут потерять специальные возможности после регионального сбоя. Чтобы обеспечить непрерывность бизнес-процессов, рекомендуется настроить учетную запись Azure Cosmos DB с одним регионом записи и по крайней мере вторым (чтением) регионом и включить отработку отказа, управляемой службой.
Отработка отказа, управляемой службой, позволяет Azure Cosmos DB выполнить отработку отказа в регионе записи для обеспечения непрерывности бизнес-процессов по стоимости потери данных, как описано ранее в разделе "Устойчивость ". Региональные отработки отказа обнаруживаются и обрабатываются в клиенте Azure Cosmos DB. Они не требуют никаких изменений в приложении. Инструкции по включению нескольких регионов чтения и отработки отказа, управляемых службой, см. в статье "Управление учетной записью Azure Cosmos DB" с помощью портал Azure.
Внимание
Если вы выбрали конфигурацию записи в одном регионе с несколькими регионами чтения, настоятельно рекомендуется настроить учетные записи Azure Cosmos DB, используемые для рабочих нагрузок, чтобы включить отработку отказа, управляемой службой. Эта конфигурация позволяет Azure Cosmos DB выполнять отработку отказа баз данных учетной записи в доступные регионы. В отсутствие этой конфигурации учетная запись потеряет доступность записи в течение всего периода сбоя области записи. Отработка отказа вручную не будет выполнена из-за отсутствия подключения к региону.
Предупреждение
Даже при включенной отработке отказа, управляемой службой, частичный сбой может потребовать ручного вмешательства для команды службы Azure Cosmos DB. В этих сценариях может потребоваться до 1 часа (или более), чтобы переход на другой ресурс ввелся в силу. Для повышения доступности записи во время частичных сбоев рекомендуется включить зоны доступности в дополнение к отработке отказа, управляемой службой.
Несколько регионов записи
Azure Cosmos DB можно настроить для приема записей в нескольких регионах. Эта конфигурация полезна для снижения задержки записи в географически распределенных приложениях.
При настройке учетной записи Azure Cosmos DB для нескольких регионов записи строгие согласованности не поддерживаются и могут возникнуть конфликты записи. Дополнительные сведения о том, как устранить эти конфликты, см. в разделе "Типы конфликтов" и политики разрешения конфликтов при использовании нескольких регионов записи.
Внимание
Обновление одного и того же идентификатора документа часто (или повторное изменение идентификатора документа часто после TTL или удаления) влияет на производительность реплика из-за увеличения числа конфликтов, созданных в системе.
Регион для разрешения конфликтов
При настройке учетной записи Azure Cosmos DB с несколькими регионами один из регионов будет выступать в качестве арбитера в конфликтах записи.
Рекомендации по записи в нескольких регионах
Ниже приведены некоторые рекомендации, которые следует учитывать при написании в нескольких регионах.
Сохранение локального трафика
При использовании операций записи в нескольких регионах приложение должно выдавать трафик чтения и записи, исходящий в локальном регионе строго в локальный регион Cosmos DB. Для оптимальной производительности избежать вызовов между регионами.
Важно, чтобы приложение свести к минимуму конфликты, избегая следующих антипаттернов:
Отправка одной и той же операции записи во все регионы, чтобы повысить вероятность получения быстрого времени отклика
Случайное определение целевого региона для операции чтения или записи на основе каждого запроса
Использование политики циклического перебора для определения целевого региона для операции чтения или записи на основе каждого запроса.
Избегайте зависимости от задержки реплика
Невозможно настроить учетные записи записи с несколькими регионами для строгой согласованности. Регион, который записывается в ответ сразу после реплика Azure Cosmos DB, локально реплика реплика реплика данных.
Хотя это редко, реплика задержка в реплика может возникать на одной или нескольких секциях при гео реплика данных. Задержка репликации может возникать из-за редкого скольжения в сетевом трафике или более высоких скоростях разрешения конфликтов.
Например, архитектура, в которой приложение записывает данные в регион A, но считывается из региона B, представляет зависимость от задержки реплика от двух регионов. Однако если приложение считывает и записывает данные в тот же регион, производительность остается постоянной даже в присутствии задержки реплика.
Оценка использования согласованности сеансов для операций записи
В согласованности сеансов используется маркер сеанса для операций чтения и записи.
Для операций чтения Azure Cosmos DB отправляет кэшированный маркер сеанса на сервер с гарантией получения данных, которые соответствуют указанному (или более последнему) токену сеанса.
Для операций записи Azure Cosmos DB отправляет маркер сеанса в базу данных с гарантией сохранения данных, только если сервер поймал предоставленный маркер сеанса. В учетных записях записи в одном регионе регион всегда гарантируется, что область записи будет подключена к маркеру сеанса. Однако в учетных записях с несколькими регионами регион, который вы записываете, возможно, не удалось выполнить запись, выданную в другом регионе. Если клиент записывает данные в регион A с маркером сеанса из региона B, регион A не сможет сохранять данные, пока не будет выполнено догонять изменения, внесенные в регионЕ B.
Рекомендуется использовать маркеры сеанса только для операций чтения, а не для операций записи при передаче маркеров сеанса между экземплярами клиента.
Устранение быстрых обновлений в том же документе
Обновления сервера для разрешения или подтверждения отсутствия конфликтов могут столкнуться с записью, запущенной приложением при повторном обновлении одного документа. Повторяющиеся обновления в быстром последовательности в одном документе испытывают более высокую задержку во время разрешения конфликтов.
Хотя случайные всплески повторяющихся обновлений в одном документе неизбежны, вы можете рассмотреть архитектуру, в которой создаются новые документы вместо того, если трафик устойчивого состояния видит быстрые обновления того же документа в течение длительного периода.
Чтение и запись сбоев
Клиенты учетных записей с одним регионом потеряют доступность чтения и записи, пока служба не будет восстановлена.
Учетные записи с несколькими регионами отличаются поведению в зависимости от следующих конфигураций и типов сбоев.
| Настройка | Отказ | Влияние на доступность | Влияние на устойчивость | Что следует делать |
|---|---|---|---|---|
| Один регион записи | Сбой региона чтения | Все клиенты автоматически перенаправляют операции чтения в другие регионы. Для всех конфигураций нет потери доступности чтения или записи. Исключением является конфигурация двух регионов с строгой согласованность, которая теряет доступность записи до восстановления службы. Или, если включить отработку отказа, управляемой службой, служба помечает регион как неудачный и происходит отработка отказа. | Потери данных нет. | Во время сбоя убедитесь, что в оставшихся регионах достаточно подготовленных единиц запросов для поддержки трафика чтения. Когда сбой закончится, перенастроите подготовленные ЕЗ в соответствии с соответствующим образом. |
| Один регион записи | Сбой региона записи | Клиенты перенаправляют операции чтения в другие регионы. Без отработки отказа, управляемой службой, клиенты испытывают потерю доступности. Восстановление доступности записи происходит автоматически при завершении сбоя. При отработки отказа, управляемом службой, клиенты испытывают потерю доступности, пока служба не будет управлять отработкой отказа в новый регион записи, который вы выбрали. |
Если вы не выберете высокий уровень согласованности, служба может не реплика отправлять некоторые данные в оставшиеся активные регионы. Это реплика от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. | Во время сбоя обеспечьте достаточную емкость (ЕЗ) в остальных регионах для обслуживания трафика чтения. Не активируйте отработку отказа вручную во время сбоя, так как она не может завершиться успешно. Когда сбой закончится, перенастроите подготовленные ЕЗ в соответствии с соответствующим образом. Учетные записи, использующие API для NoSQL, также могут восстановить неисправные данные реплика в неисправном регионе из веб-канала конфликтов. |
| Несколько регионов записи | Любой сбой региона | Существует возможность временной потери доступности записи, которая аналогична одному региону записи с отработкой отказа, управляемой службой. Отработка отказа региона разрешения конфликтов также может привести к потере доступности записи, если во время сбоя происходит большое количество конфликтующих операций записи. | Недавно обновленные данные в регионе сбоя могут быть недоступны в оставшихся активных регионах в зависимости от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. | Во время сбоя убедитесь, что в остальных регионах достаточно подготовленных единиц ЕЗ для поддержки большего трафика. Когда сбой закончится, вы можете перенастроить подготовленные ЕЗ соответствующим образом. По возможности Azure Cosmos DB автоматически восстанавливает не реплика ированные данные в неисправном регионе. Это автоматическое восстановление использует метод разрешения конфликтов, настроенный для учетных записей, использующих API для NoSQL. Для учетных записей, использующих другие API, это автоматическое восстановление использует последнюю победу записи. |
Дополнительные сведения о сбоях регионов чтения
Затронутый регион отключен и помечен в автономном режиме. Пакеты SDK Azure Cosmos DB перенаправляют вызовы чтения в следующий доступный регион в списке предпочтительных регионов.
Если ни один из регионов в списке предпочтительных регионов недоступен, вызовы автоматически возвращаются в текущий регион записи.
Изменения в коде приложения не требуются для обработки сбоев в области чтения. Когда затронутый регион чтения снова подключен к сети, он синхронизируется с текущим регионом записи и снова доступен для обслуживания запросов на чтение после полного перехвата.
Последующие операции чтения перенаправляются в восстановленный регион без каких-либо изменений в коде приложения. При отработке отказа и повторном подключении к ранее неудачной области Azure Cosmos DB продолжает соблюдать гарантии согласованности чтения.
Даже в редких и несчастных случаях, когда регион записи Azure безвозвратно неизменяем, нет потери данных, если ваша учетная запись Azure Cosmos DB с несколькими регионами настроена с высокой согласованности. Учетная запись Azure Cosmos DB с несколькими регионами имеет характеристики устойчивости, указанные ранее в разделе "Устойчивость ".
Дополнительные сведения о сбоях регионов чтения
Во время сбоя региона записи учетная запись Azure Cosmos DB повышает дополнительный регион для создания нового основного региона записи при настройке отработки отказа , управляемой службой, в учетной записи Azure Cosmos DB. Отработка отказа происходит в другой регион в порядке указанного приоритета региона.
Отработка отказа вручную не должна быть активирована и не будет выполнена успешно в случае сбоя исходного или целевого региона. Причина заключается в том, что процедура отработки отказа включает проверка согласованности, для которой требуется подключение между регионами.
Когда затронутый ранее регион вернулся в режим "в сети", все данные записи, которые не были реплика, когда регион не удалось получить доступ через канал конфликтов. Приложения могут считывать веб-канал конфликтов, разрешать конфликты на основе логики конкретного приложения и записывать обновленные данные обратно в контейнер Azure Cosmos DB соответствующим образом.
После восстановления ранее затронутого региона записи он будет отображаться как "онлайн" в портал Azure и станет доступным как регион чтения. На этом этапе безопасно вернуться в восстановленный регион в качестве области записи с помощью [PowerShell, Azure CLI или портал Azure](.). /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. Данные или потери доступности отсутствуют до, в то время как или после переключения области записи. Приложение сохраняет высокий уровень доступности.
Предупреждение
В случае сбоя региона записи, когда учетная запись Azure Cosmos DB повышает уровень дополнительного региона в качестве нового основного региона записи с помощью отработки отказа, управляемого службой, исходная область записи не будет повышена автоматически, так как область записи автоматически будет восстановлена. Вам нужно вернуться к восстановленному региону в качестве региона записи с помощью PowerShell, Azure CLI или портал Azure (как только безопасно сделать это, как описано выше).
Обнаружение сбоев, уведомление и управление
Для учетных записей с одним регионом клиенты испытывают потерю доступности чтения и записи во время сбоя региона Azure Cosmos DB. Учетные записи с несколькими регионами отличаются от поведения, как описано в следующей таблице.
| Регионы записи | Отработка отказа, управляемого службой | Чего следует ожидать | Что следует делать |
|---|---|---|---|
| Один регион записи | Не включено | Если в регионе чтения возникает сбой, когда вы не используете надежную согласованность, все клиенты перенаправляются в другие регионы. Нет потери доступности чтения или записи, и нет потери данных. При использовании строгой согласованности сбой в регионе чтения может повлиять на доступность записи, если менее двух регионов чтения остаются. Если в регионе записи произошел сбой, клиенты испытывают потерю доступности записи. Если вы не выбрали надежную согласованность, служба может не реплика отправлять некоторые данные в оставшиеся активные регионы. Это реплика tion зависит от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. Azure Cosmos DB восстанавливает доступность записи при завершении сбоя. |
Во время сбоя обеспечьте достаточную емкость (ЕЗ) в остальных регионах для обслуживания трафика чтения. Не активируйте отработку отказа вручную во время сбоя, так как она не может завершиться успешно. Когда сбой закончится, перенастроите подготовленные ЕЗ в соответствии с соответствующим образом. |
| Один регион записи | Включен | Если в регионе чтения возникает сбой, когда вы не используете надежную согласованность, все клиенты перенаправляются в другие регионы. Нет потери доступности чтения или записи, и нет потери данных. При использовании строгой согласованности сбой региона чтения может повлиять на доступность записи, если менее двух регионов чтения остаются. Если в регионе записи произошел сбой, клиенты испытывают потерю доступности записи, пока Azure Cosmos DB не выберет новый регион в качестве нового региона записи в соответствии с вашими предпочтениями. Если вы не выбрали надежную согласованность, служба может не реплика отправлять некоторые данные в оставшиеся активные регионы. Это реплика tion зависит от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. |
Во время сбоя обеспечьте достаточную емкость (ЕЗ) в остальных регионах для обслуживания трафика чтения. Не активируйте отработку отказа вручную во время сбоя, так как она не может завершиться успешно. Когда сбой закончится, вы можете переместить регион записи обратно в исходный регион и перенастроить подготовленные ЕЗ соответствующим образом. Учетные записи, использующие API для NoSQL, также могут восстановить не реплика ированные данные в неисправном регионе из веб-канала конфликтов. |
| Несколько регионов записи | Нет данных | Недавно обновленные данные в регионе с ошибкой могут быть недоступны в оставшихся активных регионах. В конечном итоге, согласованный префикс и уровни согласованности сеансов гарантируют устаревание менее 15 минут. Ограниченное устаревание гарантирует меньше K обновлений или секунд T в зависимости от конфигурации. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. | Во время сбоя убедитесь, что в остальных регионах достаточно подготовленных единиц ЕЗ для поддержки большего трафика. Когда сбой закончится, вы можете перенастроить подготовленные ЕЗ соответствующим образом. По возможности Azure Cosmos DB восстанавливает не реплика ированные данные в неисправном регионе. Это восстановление использует метод разрешения конфликтов, настроенный для учетных записей, использующих API для NoSQL. Для учетных записей, использующих другие API, это восстановление использует последнюю победу записи. |
Тестирование высокого уровня доступности
Даже если ваша учетная запись Azure Cosmos DB высокодоступна, приложение может быть неправильно разработано для обеспечения высокой доступности. Чтобы проверить сквозную высокую доступность приложения в рамках детализации тестирования приложений или аварийного восстановления (АВАРИЙНОго восстановления), временно отключите отработку отказа, управляемой службой, для учетной записи. Вызовите отработку отказа вручную с помощью PowerShell, Azure CLI или портал Azure, а затем отслеживайте приложение. После завершения теста можно выполнить отработку отказа в основной регион и восстановить отработку отказа, управляемой службой, для учетной записи.
Внимание
Не вызывайте отработку отказа вручную во время сбоя Azure Cosmos DB в исходном или целевом регионе. Отработка отказа вручную требует подключения к регионам для обеспечения согласованности данных, поэтому она не будет выполнена.