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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

  

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

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

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

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

Требования

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

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

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

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

  Зональные развертывания (однозонные) поддерживаются во всех ценовых категориях.

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

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

Cost

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

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

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

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

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

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

  Подсказка

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

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

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

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

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

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

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования

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

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

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

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

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

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

Дополнительные рекомендации, которые применяются к процессу продвижения, см. в статье "Повышение реплик чтения в Azure Database для PostgreSQL - рекомендации".

Cost

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

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

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

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

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

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

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

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

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

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

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

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

  Это важно

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

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

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

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

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

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

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

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

  Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

  Срок хранения резервных копий по умолчанию составляет 7 дней, при этом можно продлить срок хранения до 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
• Акселератор устойчивых решений для базы данных Azure для PostgreSQL — скрипты Terraform для реализации многих принципов устойчивости и восстановления, описанных в этой статье.