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

Статья
04/01/2025

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

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

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

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

Дополнительные сведения о зонах доступности в Azure см. в статье "Что такое зоны доступности?"

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

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

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

Примечание.

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

Требования

Избыточность в пределах зоны.

Параметр зональной избыточности доступен только в регионах, поддерживающих зоны доступности.
Зональная избыточность не поддерживается для:
- База данных Azure для PostgreSQL – Single Server SKU.
- Ресурсоемкие вычислительные уровни.
- Регионы с доступностью только в одной зоне.

Зональный:

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

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

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

Мониторинг состояния высокой доступности

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

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

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

Подробное руководство по настройке и интерпретации состояний работоспособности систем высокой доступности смотрите в основной статье Мониторинг состояния работоспособности для Azure Database for PostgreSQL — гибкий сервер.

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

Из-за синхронной репликации с резервным сервером приложения могут испытывать повышенные задержки записи и утверждения, особенно при конфигурации с избыточностью по зонам.
Резервную реплику нельзя использовать для запросов чтения.
В зависимости от рабочей нагрузки и активности на основном сервере процесс переключения может занять более 120 секунд из-за необходимости восстановления в резервной реплике перед её подключением.
Резервный сервер обычно восстанавливает ФАЙЛЫ WAL в 40 МБ/с. Для более крупных SKU эта скорость может увеличиться до 200 МБ/с. Если ваша рабочая нагрузка превышает это ограничение, вы можете столкнуться с тем, что восстановление может занять больше времени, как во время переключения на резерв, так и после установки нового резервного сервера.
Перезапуск сервера базы данных-источника также перезапускает резервную реплику.
Настройка дополнительного резервного копирования не поддерживается.
Настройка задач управления, инициированных клиентом, не может быть запланирована во время управляемого периода обслуживания.
Запланированные события, такие как масштабирование вычислительных мощностей и масштабируемое хранилище, сначала происходят на резервном сервере, а затем на основном сервере. В настоящее время сервер не выполняет переключение на резервный сервер для этих запланированных операций.
Если логическое декодирование или логическая репликация настроены на гибком сервере, настроенном на доступность, то при переходе на резервный сервер логические слоты репликации не копируются на резервный сервер. Чтобы поддерживать слоты логической репликации и обеспечить согласованность данных после переключения на резерв, рекомендуется использовать расширение PG Failover Slots. Дополнительные сведения о включении этого расширения см. в документации.
Настройка зон доступности между частной (виртуальной сетью) и общедоступным доступом с частными конечными точками не поддерживается. Необходимо настроить зоны доступности в виртуальной сети (распространенные между зонами доступности в пределах региона) или общий доступ с частными конечными точками.
Зоны доступности настраиваются только в одном регионе. Зоны доступности не могут быть настроены в разных регионах.

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

Зональная модель обеспечивает SLA гарантированный уровень доступности 99,95%.
Модель зональной избыточности обеспечивает SLA от 99,99%.

Создайте базу данных Azure для PostgreSQL — Flexible Server с поддержкой зоны доступности

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

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

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

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

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

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

Проверка здоровья

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

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

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

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

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

Состояние	Description
Инициализация	В процессе создания нового резервного сервера
Репликация данных	После создания резервного узла он синхронизируется с основным.
Здоровый	Репликация находится в стабильном и хорошем состоянии.
Переключение при отказе	Сервер базы данных находится в процессе переключения на резервный сервер.
Удаление резервного режима	В процессе удаления резервного сервера.
Не включено	Высокий уровень доступности не включен.

Примечание.

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

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

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

Рисунок, показывающий рабочий процесс устойчивого состояния высокой доступности.

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

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

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

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

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

Поддержка резервирования отказоустойчивости

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

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

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

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

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

Step	Description	Ожидается ли простой приложения?
1	Подождите, пока резервный сервер не синхронизируется с основным.	Нет
2	Внутренняя система мониторинга инициирует процесс переключения.	Нет
3	Записи приложений блокируются, когда резервный сервер близок к основному номеру последовательности журналов (LSN).	Да
4	Резервный сервер повышен до статуса независимого сервера.	Да
5	Запись DNS обновлена, и в ней указан IP-адрес нового резервного сервера.	Да
6	Приложение для повторного подключения и возобновления чтения и записи с новым основным.	Нет
7	Создан новый резервный сервер в другой зоне.	Нет
8	Резервный сервер начинает восстанавливать журналы (из Blob Azure), которые он пропустил во время своей настройки.	Нет
9	Устанавливается устойчивое состояние между основным и резервным сервером.	Нет
10	Процесс запланированного переключения на резерв завершен.	Нет

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

Совет

С гибким сервером вы можете при необходимости запланировать действия обслуживания, инициированные Azure, выбрав 60-минутное окно в день вашего предпочтения, где действия в базах данных, как ожидается, будут низкими. Во время этого окна будут выполняться задачи по обслуживанию Azure, такие как патчинг или незначительные обновления версий. Если вы не выбираете настраиваемое окно, системой выбирается назначенное 1-часовое окно в промежутке с 11 вечера до 7 утра местного времени для вашего сервера. Эти действия обслуживания, инициированные Azure, также выполняются на резервной реплике для гибких серверов, настроенных с зонами доступности.

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

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

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

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

Тестирование отказоустойчивости (принудительное переключение на резерв)

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

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

Ниже приведены шаги во время принудительного переключения при отказе.

Step	Description	Ожидается ли простой приложения?
1	Основной сервер останавливается немедленно после получения запроса на переключение.	Да
2	Так как главный сервер не работает, приложение простаивает.	Да
3	Внутренняя система мониторинга обнаруживает сбой и инициирует переключение на резервный сервер.	Да
4	Резервный сервер переходит в режим восстановления до того момента, пока его уровень не будет повышен до независимого сервера.	Да
5	Процесс отработки отказа ожидает завершения восстановления резервного режима.	Да
6	После запуска сервера запись DNS обновляется с тем же именем узла, но с использованием IP-адреса резервного сервера.	Да
7	Приложение может повторно подключиться к новому главному серверу и возобновить свою работу.	Нет
8	Создан резервный сервер в предпочтительной зоне.	Нет
9	Резервный сервер начинает восстанавливать пропущенные журналы (из Azure Blob-хранилища) во время его настройки.	Нет
10	Устанавливается устойчивое состояние между основным и резервным сервером.	Нет
11	Процесс принудительного переключения завершен.	Нет

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

Внимание

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

Опыт снижения интенсивности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги

Документация по Базе данных Azure для PostgreSQL

Надежность в Azure

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