Высокий уровень доступности (надежность) в Базе данных Azure для PostgreSQL

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

База данных Azure для PostgreSQL поддерживает высокий уровень доступности благодаря физическому разделению первичных и резервных реплик, которое может быть реализовано в пределах одной зоны доступности (зональное) или между разными зонами доступности (избыточное между зонами). Эта модель высокой доступности предназначена для обеспечения того, чтобы зафиксированные данные никогда не терялись во время сбоев. При установке высокого уровня доступности данные синхронно фиксируются как на первичных, так и на резервных серверах. Модель разработана таким образом, чтобы база данных не стала единственной точкой сбоя в архитектуре программного обеспечения. Дополнительные сведения о поддержке высокого уровня доступности и зоны доступности см. в разделе "Поддержка зоны доступности".

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

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

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

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

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

  

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

Зональная избыточность не поддерживается для:

• Ресурсоемкие вычислительные уровни

• Регионы с наличием одной зоны

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

  

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

Настройка зональной устойчивости на портале

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

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

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

Возможности обеспечения высокой доступности

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

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

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

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

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

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

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

• Все изменения параметров сервера также применяются к резервной реплике.

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

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

Отслеживание состояния системы высокой доступности

Мониторинг состояния системы высокой доступности (HA) в базе данных Azure для PostgreSQL предоставляет непрерывный обзор готовности и работоспособности экземпляров HA. Эта функция мониторинга применяет платформу проверки работоспособности ресурсов Azure (RHC) для обнаружения и оповещения о любых проблемах, которые могут повлиять на готовность к отработке отказа базы данных или общую доступность. Оценивая ключевые метрики, такие как состояние подключения, состояние отработки отказа и работоспособность репликации данных, мониторинг состояния работоспособности высокой доступности обеспечивает упреждающее устранение неполадок и помогает поддерживать безотказное время работы и производительность базы данных.

Мониторинг состояния работоспособности высокого уровня доступности используется для:

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

Подробное руководство по настройке и интерпретации состояний работоспособности высокого уровня доступности см. в разделе "Мониторинг состояния работоспособности высокого уровня доступности" для Базы данных Azure для PostgreSQL.

Ограничения высокого уровня доступности

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

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

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

• Резервный сервер обычно восстанавливает ФАЙЛЫ WAL в 40 МБ/с. Для более крупных версий эта скорость может увеличиться до 200 МБ/с. Если ваша рабочая нагрузка превышает это ограничение, вы можете столкнуться с тем, что восстановление может занять больше времени, как во время переключения на резерв, так и после установки нового резервного сервера.

• Перезапуск сервера базы данных-источника также перезапускает резервную реплику.

• Вы не можете настроить дополнительный резервный режим.

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

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

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

  • В PostgreSQL 16 и более ранних версиях слоты логической репликации по умолчанию не сохраняются на резервном сервере после отказа.
  • Чтобы логическая репликация продолжала функционировать после аварийного переключения, необходимо включить расширение pg_failover_slots и настроить вспомогательные параметры, такие как hot_standby_feedback = on.
  • Начиная с PostgreSQL 17 синхронизация слотов поддерживается изначально. Если включить правильные конфигурации PostgreSQL (sync_replication_slots, hot_standby_feedback), слоты логической репликации сохраняются автоматически после отработки отказа, и никаких расширений не требуется.
  • Для получения инструкций по настройке и предварительных требований, см. документацию по расширению PG_Failover_Slots.

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

• Вы можете настроить только зоны доступности в одном регионе. Невозможно настроить зоны доступности в разных регионах.

SLA

• Зональная модель предлагает время безотказной работы по SLA около 99%.

• Модель избыточности между зонами обеспечивает доступность для SLA на уровне 99%.

Создание базы данных Azure для PostgreSQL с включенной зоной доступности

Сведения о создании базы данных Azure для PostgreSQL для обеспечения высокой доступности с зонами доступности см. в кратком руководстве по созданию базы данных Azure для PostgreSQL на портале Azure.

Перераспределение и миграция зон доступности

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

Компоненты и рабочие процессы высокого уровня доступности

Выполнение транзакций

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

Проверка состояния здоровья

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

Режимы отработки отказа

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

Статус высокой доступности

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

Операции в устойчивом состоянии

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

1. Клиенты подключаются к гибкому серверу и выполняют операции записи.
2. Изменения реплицируются на резервный сайт.
3. Первичный получает подтверждение.
4. Признаются записи и фиксации.

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

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

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

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

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

Сведения о восстановлении гибкого сервера на определенный момент времени см. в статье "Восстановление гибкого сервера на определенный момент времени".

Поддержка отработки отказа

Плановое переключение на резервную систему

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

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

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

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

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

Список возможных запланированных событий простоя см. в разделе "Запланированные события простоя".

Внеплановое переключение

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

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

Тестирование отработки отказов (принудительная отработка отказа)

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

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

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

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

Рекомендации при выполнении принудительного переключения

• Общее время выполнения операции может быть дольше фактического времени простоя приложения.

  Это важно

  Всегда следите за временем простоя с точки зрения приложения!

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

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

Рекомендации по статистике PostgreSQL после переключения после сбоя

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

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

Учитывая это различие, запустите ANALYZE после отказа системы PostgreSQL. Это действие обновляет таблицы, например, pg_stat_*, свежими статистическими данными о действиях, помогая процессу автовакуума и обеспечивая оптимальную производительность базы данных в новой роли. Этот упреждающий шаг связывает разрыв между сохранением важной статистики оптимизатора и обновлением метрик действий для выравнивания текущего состояния базы данных.

Опыт понижения зоны

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

Дополнительные сведения о восстановлении на определенный момент времени см. в статье "Резервное копирование и восстановление" в Базе данных Azure для PostgreSQL - Гибкий сервер.

Избыточность по зонам: гибкий сервер автоматически переключается на резервный сервер в течение 60–120 секунд с нулевой потерей данных.

Конфигурации без зон доступности

Хотя это не рекомендуется, можно настроить гибкий сервер без включения высокой доступности. Для гибких серверов, настроенных без высокой доступности, служба предоставляет локально резервируемое хранилище с тремя копиями данных, резервное копирование с избыточностью между зонами (в регионах, где оно поддерживается), а также встроенную устойчивость сервера, которая автоматически перезапускает аварийный сервер и выполняет перемещение на другой физический узел. Эта конфигурация обеспечивает время безотказной работы по соглашению об уровне обслуживания на уровне 99,9%. Во время запланированных или незапланированных событий отработки отказа, если сервер выходит из строя, служба обеспечивает сохранение доступности серверов с помощью следующей автоматической процедуры:

1. Будет подготовлена новая виртуальная машина Linux для вычислений.
2. Хранилище с файлами данных сопоставляется с новой виртуальной машиной.
3. Ядро СУБД PostgreSQL подключено к сети на новой виртуальной машине.

На следующем рисунке показан переход между виртуальной машиной и сбоем хранилища.

Аварийное восстановление между регионами и непрерывность бизнес-процессов

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

Гибкий сервер предоставляет функции, которые защищают данные и уменьшают простой во время запланированных и незапланированных событий для критически важных баз данных. На основе инфраструктуры Azure, которая обеспечивает надежную устойчивость и доступность, гибкий сервер предлагает функции непрерывности бизнес-процессов, обеспечивающие защиту от сбоев, требования к времени восстановления и снижение риска потери данных. При разработке приложений учитывайте отказоустойчивость времени простоя — цель времени восстановления (RTO) и воздействие потери данных — цель точки восстановления (RPO). Например, для базы данных, критически важной для бизнеса, требуется более строгое время простоя, чем тестовая база данных.

Аварийное восстановление в географическом регионе с несколькими регионами

Геоизбыточное резервное копирование и восстановление

Геоизбыточное резервное копирование и восстановление позволяют восстановить сервер в другом регионе в случае аварии. Это также обеспечивает устойчивость объектов резервного копирования как минимум на 99,99999999999999 % (16 девяток) в течение заданного года.

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

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

Реплики для чтения

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

Дополнительные сведения о функциях и особенностях читающих реплик см. в разделе Читающие реплики.

Обнаружение сбоев, уведомление и управление

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

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

Дополнительные сведения о незапланированном устранении простоя и восстановлении после региональной аварии см. в разделе "Внеплановая защита от простоя".

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

• Документация по Базе данных Azure для PostgreSQL
• Надежность в Azure