Обеспечение высокой доступности с помощью Azure Cosmos DB
Область применения: 
Nosql Mongodb Кассандра Гремлин Таблица
Чтобы создать решение с высоким уровнем доступности, необходимо оценить характеристики надежности всех компонентов. Azure Cosmos DB предоставляет функции и параметры конфигурации, помогающие обеспечить высокий уровень доступности решения.
В этой статье используются следующие термины:
- Цель времени восстановления (RTO) — время между началом сбоя, затрагивающего Azure Cosmos DB и восстановление до полной доступности.
- Цель точки восстановления (RPO): время между последней записью, которая была правильно восстановлена и временем начала сбоя, затрагивающего Azure Cosmos DB.
Примечание.
Ожидаемые и максимальные RPOs и ОСРВ зависят от типа сбоя, возникающего в Azure Cosmos DB. Например, сбой одного узла отличается от RTO и RPO, чем сбой всего региона.
В этой статье описаны события, которые могут повлиять на доступность Azure Cosmos DB и соответствующие параметры конфигурации Azure Cosmos DB.
Обслуживание реплик
Azure Cosmos DB — это мультитенантная служба, которая прозрачно управляет всеми деталями отдельных вычислительных узлов. Пользователям не нужно беспокоиться о каком-либо исправлении или плановом обслуживании. Azure Cosmos DB гарантирует соглашения об уровне обслуживания для доступности и задержки P99 через все операции автоматического обслуживания, выполняемые системой.
Сбои реплик
Сбои реплик — это сбои отдельных узлов в кластере Azure Cosmos DB, развернутом в регионе Azure.
Azure Cosmos DB автоматически устраняет реплика сбоев, гарантируя по крайней мере три реплика данных в каждом регионе Azure для учетной записи в пределах четырех реплика кворума. Это гарантирует, что RTO 0 и RPO 0 для отдельных сбоев узлов не требуют изменений или конфигураций приложения.
Во многих регионах Azure можно распределить кластер Azure Cosmos DB между зонами доступности. Зоны доступности могут увеличить соглашения об уровне обслуживания, так как они физически отделены и предоставляют отдельный источник питания, сеть и охлаждение. При развертывании учетной записи Azure Cosmos DB с помощью зон доступности Azure Cosmos DB предоставляет RTO 0 и RPO 0 даже в сбоях зоны.
При развертывании в одном регионе Azure без дополнительных пользовательских данных Azure Cosmos DB устойчив к сбоям узлов. Включение избыточности между зонами доступности обеспечивает устойчивость Azure Cosmos DB к сбоям зон за счет увеличения расходов.
Вы можете настроить избыточность зоны только при добавлении нового региона в учетную запись Azure Cosmos DB. Для существующих регионов можно включить избыточность зоны, удалив регион, а затем добавив его обратно с включенной избыточностью зоны. Для учетной записи с одним регионом этот подход требует добавить регион для временного отработки отказа, а затем удалить и добавить нужный регион с включенной избыточностью зоны.
По умолчанию учетная запись Azure Cosmos DB не использует несколько зон доступности. Развертывание в нескольких зонах доступности можно включить следующими способами:
Если ваша учетная запись Azure Cosmos DB распределена по регионам N Azure, будут копироваться все данные n x 4. Дополнительные сведения о том, как данные azure Cosmos DB реплика tes в каждом регионе см. в статье "Глобальное распределение" с помощью Azure Cosmos DB. Наличие учетной записи Azure Cosmos DB в более чем двух регионах повышает доступность приложения и обеспечивает низкую задержку в связанных регионах.
Сбои региона
Сбои регионов — это сбои, влияющие на все узлы 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.
Availability
Если для решения требуется непрерывная доступность во время сбоя регионов, можно настроить 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. Данные или потери доступности отсутствуют до, в то время как или после переключения области записи. Приложение сохраняет высокий уровень доступности.
Предупреждение
В случае сбоя региона записи, когда учетная запись Azure Cosmos DB повышает уровень дополнительного региона в качестве нового основного региона записи с помощью отработки отказа, управляемого службой, исходная область записи не будет повышена автоматически, так как область записи автоматически будет восстановлена. Вам нужно вернуться к восстановленному региону в качестве региона записи с помощью PowerShell, Azure CLI или портал Azure (как только безопасно сделать это, как описано выше).
Соглашения об уровне обслуживания
В следующей таблице перечислены возможности высокой доступности различных конфигураций учетных записей.
| КПЭ | Запись в один регион без зон доступности | Запись в одном регионе с зонами доступности | Запись в нескольких регионах без зон доступности | Запись в нескольких регионах с зонами доступности | Создание нескольких регионов с несколькими регионами с зонами доступности или без них |
|---|---|---|---|---|---|
| Соглашение об уровне обслуживания для доступности записи | 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 применяется только к регионам, в которых можно включить зоны доступности.
Советы для создания высокодоступных приложений
Просмотрите ожидаемое поведение пакетов SDK Azure Cosmos DB во время событий и какие конфигурации влияют на него.
Чтобы обеспечить высокую доступность записи и чтения, настройте учетную запись Azure Cosmos DB, чтобы охватывать по крайней мере два региона (или три, если используется надежная согласованность). Дополнительные сведения см. в руководстве по настройке глобального распространения Azure Cosmos DB с помощью API для NoSQL.
Для учетных записей Azure Cosmos DB с несколькими регионами, настроенными с одним регионом записи, включите отработку отказа, управляемой службой, с помощью Azure CLI или портал Azure. После включения отработки отказа, управляемой службой, при возникновении региональной аварии Azure Cosmos DB будет выполнять отработку отказа учетной записи без каких-либо входных данных пользователя.
Даже если ваша учетная запись Azure Cosmos DB высокодоступна, приложение может быть неправильно разработано для обеспечения высокой доступности. Чтобы проверить сквозную высокую доступность приложения в рамках детализации тестирования приложений или аварийного восстановления (АВАРИЙНОго восстановления), временно отключите отработку отказа, управляемой службой, для учетной записи. Вызовите отработку отказа вручную с помощью PowerShell, Azure CLI или портал Azure, а затем отслеживайте приложение. После завершения теста можно выполнить отработку отказа в основной регион и восстановить отработку отказа, управляемой службой, для учетной записи.
Внимание
Не вызывайте отработку отказа вручную во время сбоя Azure Cosmos DB в исходном или целевом регионе. Отработка отказа вручную требует подключения к регионам для обеспечения согласованности данных, поэтому она не будет выполнена.
В среде глобально распределенной базы данных существует прямая зависимость между уровнем согласованности и устойчивостью данных в случае сбоя в масштабе региона. При разработке плана непрерывности бизнес-процессов необходимо понять максимально допустимое время, прежде чем приложение полностью восстанавливается после нарушения (то есть RTO). Кроме того, необходимо понять максимальный период последних обновлений данных, которые приложение может терпеть потерять при восстановлении после нарушения (то есть RPO). Дополнительные сведения о RTO и RPO см. в разделе "Уровни согласованности" в Azure Cosmos DB.
Что ожидать во время сбоя региона Azure Cosmos DB
Для учетных записей с одним регионом клиенты испытывают потерю доступности чтения и записи во время сбоя региона Azure Cosmos DB. Учетные записи с несколькими регионами отличаются от поведения, как описано в следующей таблице.
| Регионы записи | Отработка отказа, управляемого службой | Чего следует ожидать | Что следует делать |
|---|---|---|---|
| Один регион записи | Не включено | Если в регионе чтения возникает сбой, когда вы не используете надежную согласованность, все клиенты перенаправляются в другие регионы. Нет потери доступности чтения или записи, и нет потери данных. При использовании строгой согласованности сбой в регионе чтения может повлиять на доступность записи, если менее двух регионов чтения остаются. Если в регионе записи произошел сбой, клиенты испытывают потерю доступности записи. Если вы не выбрали надежную согласованность, служба может не реплика отправлять некоторые данные в оставшиеся активные регионы. Это реплика tion зависит от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. Azure Cosmos DB восстанавливает доступность записи при завершении сбоя. |
Во время сбоя обеспечьте достаточную емкость (ЕЗ) в остальных регионах для обслуживания трафика чтения. Не активируйте отработку отказа вручную во время сбоя, так как она не может завершиться успешно. Когда сбой закончится, перенастроите подготовленные ЕЗ в соответствии с соответствующим образом. |
| Один регион записи | Включен | Если в регионе чтения возникает сбой, когда вы не используете надежную согласованность, все клиенты перенаправляются в другие регионы. Нет потери доступности чтения или записи, и нет потери данных. При использовании строгой согласованности сбой региона чтения может повлиять на доступность записи, если менее двух регионов чтения остаются. Если в регионе записи произошел сбой, клиенты испытывают потерю доступности записи, пока Azure Cosmos DB не выберет новый регион в качестве нового региона записи в соответствии с вашими предпочтениями. Если вы не выбрали надежную согласованность, служба может не реплика отправлять некоторые данные в оставшиеся активные регионы. Это реплика tion зависит от выбранного уровня согласованности. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. |
Во время сбоя обеспечьте достаточную емкость (ЕЗ) в остальных регионах для обслуживания трафика чтения. Не активируйте отработку отказа вручную во время сбоя, так как она не может завершиться успешно. Когда сбой закончится, вы можете переместить регион записи обратно в исходный регион и перенастроить подготовленные ЕЗ соответствующим образом. Учетные записи, использующие API для NoSQL, также могут восстановить не реплика ированные данные в неисправном регионе из веб-канала конфликтов. |
| Несколько регионов записи | Нет данных | Недавно обновленные данные в регионе с ошибкой могут быть недоступны в оставшихся активных регионах. В конечном итоге, согласованный префикс и уровни согласованности сеансов гарантируют устаревание менее 15 минут. Ограниченное устаревание гарантирует меньше K обновлений или секунд T в зависимости от конфигурации. Если затронутый регион страдает от постоянной потери данных, вы можете потерять не реплика ированные данные. | Во время сбоя убедитесь, что в остальных регионах достаточно подготовленных единиц ЕЗ для поддержки большего трафика. Когда сбой закончится, вы можете перенастроить подготовленные ЕЗ соответствующим образом. По возможности Azure Cosmos DB восстанавливает не реплика ированные данные в неисправном регионе. Это восстановление использует метод разрешения конфликтов, настроенный для учетных записей, использующих API для NoSQL. Для учетных записей, использующих другие API, это восстановление использует последнюю победу записи. |
Следующие шаги
Далее можно ознакомиться со следующими статьями: