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

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

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

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

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

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

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

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

Логическая архитектура

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

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

Дополнительные сведения об общей архитектуре службы и моделях развертывания см. в обзоре База данных Azure для PostgreSQL.

Физическая архитектура

• Разделение вычислительных ресурсов и хранилища: База данных Azure для PostgreSQL использует архитектуру разделения вычислительных ресурсов и хранилища для обеспечения высокой доступности. Ядро СУБД выполняется на виртуальной машине Linux, а служба хранилища Azure хранит файлы данных и сохраняет три локально избыточных синхронных копии файлов базы данных, чтобы обеспечить устойчивость данных.

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

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

  

  Схема, на которой показана архитектура высокого уровня доступности для База данных Azure для PostgreSQL. Два сервера рядом. Слева находится прямоугольник с надписью «primary server», а внутри него — виртуальная машина и диск. Справа расположен такой же блок с подписью «резервный сервер», который также содержит виртуальную машину и диск. Горизонтальная стрелка указывает от первичного сервера слева к резервному серверу справа и обозначена как «потоковая репликация», что указывает на одностороннюю связь, при которой изменения данных передаются от первичного сервера к резервному серверу.

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

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

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

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

• Резервные копии: База данных Azure для PostgreSQL автоматически создает резервные копии серверов. Дополнительные сведения см. в разделе "Резервное копирование и восстановление".

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

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

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

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

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

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

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

Дополнительные сведения см. в статье Об обработке временных ошибок подключения в Базе данных Azure для PostgreSQL.

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

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

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

Каждая зона доступности хранит файлы данных и журналы перед записью (WALs) на управляемых дисках уровня "Премиум" с локальным избыточным хранилищем (LRS), которое автоматически сохраняет три копии данных в каждой зоне.

База данных Azure для PostgreSQL поддерживает два типа конфигурации зоны доступности при использовании высокой доступности:

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

  Можно выбрать зоны доступности для основных и резервных серверов или разрешить корпорации Майкрософт выбрать их.

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

  

  Схема, показывающая зонально-избыточную конфигурацию База данных Azure для PostgreSQL, распределенную по зонам доступности. Три зоны перечислены в верхней части: зона доступности 1, зона доступности 2 и зона доступности 3. Под зоной доступности 1 расположен блок с меткой «основной сервер», а внутри этого блока находятся виртуальная машина и диск, что показывает, что основной сервер состоит из вычислительных ресурсов и хранилища. Под зоной доступности 2 расположен аналогичный блок с меткой «резервный сервер», который также содержит виртуальную машину и диск. Между этими двумя блоками серверов находится стрелка, направленная вправо, с меткой «потоковая репликация», показывающая, что изменения данных передаются от первичного сервера слева к резервному серверу справа. Схема демонстрирует межзонную отказоустойчивость: основной и резервный узлы разнесены по двум зонам доступности, а зона доступности 3 не используется.

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

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

  

  Схема, на которой показана зональная База данных Azure для PostgreSQL настройка в одной зоне доступности. Показаны три зоны: зона доступности 1, зона доступности 2 и зона доступности 3. В зоне доступности 1 расположены два блока рядом друг с другом. Блок слева помечен как «основной сервер», а внутри этого блока находятся виртуальная машина и диск. Поле справа помечается резервным сервером, а внутри этого поля — виртуальная машина и диск. Между этими двумя блоками серверов расположена стрелка, направленная вправо, с надписью «потоковая репликация», показывающая, что изменения данных передаются с основного сервера слева на резервный сервер справа. Оба сервера находятся в одной зоне доступности. Зона доступности 2 и зона доступности 3 не используются.

  Зональная (однозонная) высокая доступность доступна только в следующих ситуациях:

  • Регион не поддерживает зоны доступности. Регион эффективно работает в качестве одной зоны, поэтому единственная конфигурация высокого уровня доступности, которая можно выбрать, является одной и той же зоной.
  • Если регион не располагает достаточной емкостью для развертывания с избыточностью между зонами, служба может первоначально разместить оба сервера в одной зоне доступности, а затем автоматически перенести их в разные зоны, когда емкость станет доступна. Этот параметр доступен при использовании портала Azure или Azure CLI для развертывания сервера. Дополнительные сведения см. в разделе "Настройка параметров "Критически важный для бизнеса" (высокий уровень доступности).

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

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

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

Требования

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

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

  Уровень вычислений	Зональное резервирование	Зональный (та же зона)
  С возможностью всплесков	Не поддерживаются	Не поддерживаются
  General Purpose	Поддерживается	Поддерживается
  Оптимизация памяти	Поддерживается	Поддерживается

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

Рекомендации

Емкость региона: Если регион не имеет достаточной емкости для развертывания с избыточностью между зонами, служба может первоначально разместить оба сервера в одной зоне доступности и автоматически перенести их в отдельные зоны, когда емкость становится доступной. Этот параметр доступен при использовании портала Azure или Azure CLI для развертывания сервера. Дополнительные сведения см. в разделе "Настройка параметров "Критически важный для бизнеса" (высокий уровень доступности).

Cost

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

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

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

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

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

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

  Подсказка

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

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

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

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

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

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

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

  Эффекты репликации различаются в зависимости от конфигурации зоны доступности, используемой сервером:

  • Избыточность между зонами: Так как серверы находятся в отдельных зонах, этот подход гарантирует нулевой потери данных во время сбоя зоны. Эта ситуация также иногда называется достижением нулевой цели точки восстановления (RPO) в случае сбоев зоны.

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

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

  Замечание

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

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

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

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

  Если зона доступности выходит из строя, поведение различается в зависимости от конфигурации зоны доступности, которую использует ваш сервер:

  • Зональная избыточность: База данных Azure для PostgreSQL автоматически обнаруживает сбои зоны доступности. Чтобы просмотреть возможные типы статуса высокой доступности, см. Мониторинг статуса работоспособности высокой доступности (HA). При сбое зоны Azure инициирует принудительный переход на резервный сервер, не требуя принятия мер.

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

• Уведомление: Мониторинг состояния и работоспособности высокой доступности в База данных Azure для PostgreSQL обеспечивает непрерывное представление о состоянии и готовности экземпляров с включенной высокой доступностью. Функция мониторинга построена на базе Azure Работоспособность ресурсов и может обнаруживать проблемы, которые могут повлиять на готовность базы данных к переключению или на её общую доступность, и оповещать о них. Оцените ключевые метрики, такие как состояние подключения, состояние отработки отказа и работоспособность репликации данных, чтобы обеспечить упреждающее устранение неполадок и обеспечить производительность базы данных.

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

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

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

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

  • Зональный: Данные на серверах в затронутой зоне недоступны до восстановления зоны.

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

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

  • Зонально: Серверы в затронутой зоне недоступны, пока не восстановится зона доступности.

• Перераспределение: Поведение перенаправки трафика зависит от конфигурации зоны доступности, используемой сервером.

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

  • Зональный: Если зона недоступна, ваш сервер также будет недоступен. Если у вас есть отдельный сервер, созданный заранее в другой зоне доступности или регионе, вы несете ответственность за перенаправку трафика на этот сервер.

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

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

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

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

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

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

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

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

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

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

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

Межрегионные реплики чтения

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

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

Схема, показывающая приложение в верхней части. Непосредственно под ней находится блок с надписью «read-write endpoint». Есть стрелка вниз от приложения к конечной точке, показывающая, что приложение отправляет свой трафик базы данных в эту конечную точку сначала. Нижняя половина схемы разделена на две большие области. Слева — основной регион. В этой области есть блок с надписью «primary server», а внутри блока — имя службы База данных Azure для PostgreSQL server. Справа — вторичный регион. В этом регионе есть соответствующий блок сервера с меткой «реплика для чтения, повышенная до основного сервера», также с меткой База данных Azure для PostgreSQL server. Стрелка идёт от конечной точки чтения-записи к первичному серверу. Пунктирная горизонтальная стрелка с надписью «асинхронная репликация» идёт от первичного сервера слева к серверу во вторичном регионе справа, показывая, что изменения данных копируются с основного сервера на реплику.

Если основной регион отказал, можно активировать промоцию, чтобы вторичная реплика стала основной. В зависимости от того, как вы используете реплики для чтения, могут подходить разные типы переключения при отказе. При использовании реплик чтения для обеспечения устойчивости к сбоям регионов обычно используется подход «повысить до основного сервера», который обновляет вашу виртуальную точку подключения. Во время сбоя региона необходимо выполнить принудительное повышение роли, что может привести к потере данных для любых не реплицированных данных. В запланированных сценариях, где основной регион работоспособен, вы можете выполнить запланированное повышение, чтобы избежать потери данных. Дополнительную информацию см. в статье "Промоция реплик для чтения" в Базе данных Azure для PostgreSQL.

Схема, показывающая приложение вверху, отправляющее данные через конечную точку чтения-записи. Нижняя половина схемы разделена на две большие области. Слева — основной регион. Внутри этой области есть блок с меткой «primary server», а внутри блока указано имя службы База данных Azure для PostgreSQL server. Над основным регионом отображается X, указывающий на то, что этот регион больше не активен. Справа — вторичный регион. В этом регионе есть соответствующий блок сервера с меткой «основной сервер, повышенный из реплики для чтения», также с меткой «сервер База данных Azure для PostgreSQL». Стрелка идёт от конечной точки чтения и записи к вторичному региону. Пунктирная горизонтальная стрелка с меткой «асинхронная репликация», идущая от основного региона к вторичному региону, перечёркнута крестом, что указывает на то, что репликация больше не активна.

Замечание

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

Требования

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

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

Рекомендации

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

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

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

Дополнительные сведения о процессе продвижения см. в разделе "Рекомендации".

Cost

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

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

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

  Сведения о создании виртуальной конечной точки см. в статье "Создание виртуальных конечных точек".

• Удаление реплики чтения: Сведения об удалении реплики чтения см. в статье "Удаление реплики чтения".

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

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

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

• Репликация данных между регионами: Реплики чтения между регионами используют асинхронную репликацию, чтобы свести к минимуму влияние на производительность сервера-источника. Объем задержки репликации зависит от многих факторов, включая нагрузку записи и задержку между основным сервером и репликами. Задержка репликации обычно составляет не менее нескольких минут, но она может быть длиннее. Дополнительные сведения см. в разделе "Мониторинг репликации".

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

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

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

  Это важно

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

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

• Уведомления: Корпорация Майкрософт не уведомляет вас об отключении региона автоматически. Однако вы можете использовать Работоспособность служб Azure, чтобы понять общее состояние службы, включая сбои в любом регионе, и настроить оповещения Service Health для уведомления о проблемах.

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

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

  Объем потери данных зависит от задержки репликации во время сбоя. Задержка репликации обычно составляет не менее нескольких минут, но она может быть длиннее. Дополнительные сведения см. в разделе "Мониторинг репликации".

• Ожидаемое время простоя: Принудительное продвижение обычно завершается в течение 1–3 минут после активации. Приложения также могут потребовать повторного подключения к правильной конечной точке. Виртуальные конечные точки обновляются в рамках принудительного продвижения. Приложения должны учитывать время жизни (TTL) записей DNS конечной точки, чтобы обеспечить быстрое подключение к правильной реплике после завершения повышения уровня.

• Перенаправка трафика: Виртуальная конечная точка сервера автоматически перенаправляет трафик приложения на новую первичную реплику.

  Замечание

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

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

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

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

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

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

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

Пошаговые инструкции см. в разделе Переключение реплики чтения на первичную.

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

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

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

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

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

  Срок хранения резервных копий по умолчанию составляет семь дней, но срок хранения можно продлить до 35 дней. Azure Backup также можно использовать для долгосрочного хранения резервных копий вручную до 10 лет. Все резервные копии шифруются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных Azure для PostgreSQL предоставляет разные соглашения об уровне обслуживания доступности в зависимости от конфигурации сервера:

• Серверы, настроенные с высоким уровнем доступности с зональной избыточностью, предоставляют гарантию времени безотказной работы 99.99%.
• Серверы, настроенные с зональной высокой доступностью, гарантируют доступность на уровне 99,95%.
• Серверы, настроенные без функции высокой доступности, предоставляют ГСО по времени безотказной работы на уровне 99.9%.

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

• Надежность Azure
• Рекомендации по архитектуре для Базы данных Azure для PostgreSQL
• Обзор непрерывности бизнес-процессов с помощью Базы данных Azure для PostgreSQL
• Географическое аварийное восстановление в базе данных Azure для PostgreSQL
• Скрипты Terraform для реализации принципов устойчивости и восстановления