Основные понятия высокого уровня доступности в Базе данных Azure для PostgreSQL — гибкий сервер

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

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

  • HA с избыточностью между зонами. Этот вариант обеспечивает полную изоляцию и избыточность инфраструктуры в нескольких зонах доступности в регионе. Он обеспечивает высочайший уровень доступности, но требует настройки избыточности приложений в разных зонах. HA с избыточностью между зонами — предпочтительный вариант, если вам нужна защита от сбоев на уровне зоны доступности и задержка по зоне доступности приемлема. Высокий уровень доступности с избыточностью между зонами доступен в подмножестве регионов Azure, где регион поддерживает несколько зон доступности. Уровень доступности Соглашения об уровне обслуживания, составляющий 99,99 %, предложен в этой конфигурации

  • HA в пределах одной зоны. Этот параметр предпочтителен для избыточности инфраструктуры с меньшей задержкой в сети, так как и главный, и резервный серверы будут находиться в одной зоне доступности. Он обеспечивает высокий уровень доступности без настройки избыточности приложений в разных зонах. Высокий уровень доступности в одной зоне предпочтителен, если требуется достичь высокого уровня доступности в пределах одной зоны доступности с наименьшей задержкой в сети. Высокий уровень доступности в одной зоне доступен во всех регионах Azure, в которых можно развернуть гибкий сервер. Уровень доступности Соглашения об уровне обслуживания, составляющий 99,95 %, предложен в этой конфигурации.

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

Примечание

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

Архитектура с высоким уровнем доступности

Гибкий сервер Базы данных Azure для PostgreSQL поддерживает две модели развертывания с высоким уровнем доступности. Одна из них обеспечивает HA с избыточностью между зонами, а другая — HA в одной зоне. В обеих моделях развертывания, когда приложение выполняет операции записи или фиксации, используя потоковую репликацию PostgreSQL, журналы транзакций (журналы с упреждающим протоколированием или WAL) записываются на локальный диск, а также реплицируются в резервную реплику в синхронном режиме. После сохранения журналов в резервной реплике для приложения будут подтверждены операции записи или фиксации. Резервный сервер будет находиться в режиме восстановления, в котором продолжается применение журналов, но главный сервер не ожидает, когда будет завершено применение журналов на резервном сервере.

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

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

Примечание

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

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

Высокий уровень доступности в одной зоне

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

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

Компоненты и рабочий процесс

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

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

Проверка работоспособности

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

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

Существует два режима отработки отказа.

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

  2. При незапланированной отработке отказа (например, при сбое узла главного сервера) главный сервер немедленно изолируется, поэтому все выполняемые транзакции теряются и приложение выполняет их повторно.

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

Простой

В любом случае необходимо наблюдать за временем простоя на стороне приложения или клиента. После отработки отказа приложение сможет повторно подключиться, как только обновится DNS. Мы позаботимся о нескольких других аспектах, включая сравнение последних порядковых номеров (LSN) между главным и резервным серверами, прежде чем изолировать операции записи. Но при незапланированных отработках отказа в некоторых случаях резервному серверу может потребоваться более 2 минут из-за объема журналов, которые необходимо восстановить, прежде чем он будет открыть для чтения и записи.

Состояние HA

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

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

Примечание

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

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

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

высокий уровень доступности — устойчивое состояние

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

Процесс отработки отказа — запланированные простои

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

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

Сокращение запланированного простоя с помощью управляемого периода обслуживания

Используя гибкий сервер, вы можете запланировать действия по обслуживанию, инициированные Azure. Для этого выберите 60-минутное "окно" в любой подходящий день, в который ожидается минимальное количество операций с базами данных. Во время этого периода обслуживания будут выполнены задачи по обслуживанию Azure, например обновление путем частичной замены или незначительное обновление версий. Если не выбрать пользовательское "окно", для сервера будет выбрано выделенное системой одночасовое "окно" в период с 23:00 до 7:00.

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

Процесс отработки отказа — незапланированные простои

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

Примечание

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

После отработки отказа во время подготовки нового резервного сервера (обычно это занимает 5–10 минут), приложения по-прежнему могут подключаться к серверу-источнику и продолжать операции чтения и записи. После создания резервного сервера он начнет восстанавливать журналы, созданные после отработки отказа.

высокий уровень доступности — отработка отказа

  1. Главный сервер базы данных отключен, а клиенты теряют возможность подключения к базе данных.
  2. Резервный сервер активируется в качестве нового главного сервера. Клиент подключается к новому главному серверу, используя ту же строку подключения. Наличие клиентского приложения в той же зоне, что и главный сервер базы данных, сокращает задержку и повышает производительность.
  3. Резервный сервер устанавливается в той же зоне, что и старый главный сервер, и инициируется потоковая репликация.
  4. После выхода процесса репликации на установившийся режим, клиентское приложение выполняет фиксацию, а подтверждение выполнения записи приходит после сохранения данных на обоих серверах.

Отработка отказа по запросу

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

принудительным переходом на другой ресурс

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

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

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

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

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

Важно!

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

Плановая отработка отказа

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

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

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

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

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

  • Общее время операции может быть больше, чем фактическое время простоя приложения. Оценивая время простоя, измеряйте его с точки зрения приложения.
  • Следующую отработку отказа не следует выполнять сразу после предыдущей. Между операциями отработки отказа делайте паузы продолжительностью не менее 15–20 минут, чтобы дождаться полного создания нового резервного сервера.
  • Чтобы уменьшить время простоя при плановой отработке отказа, рекомендуется выполнять эту процедуру в периоды малой активности серверов.

Сведения об управлении высоким уровнем доступности см. в этом руководстве.

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

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

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

Высокий уровень доступности: возможности

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

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

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

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

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

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

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

  • Любые изменения параметров этого сервера также применяются к резервному серверу-реплике.

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

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

Высокий уровень доступности: ограничения

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

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

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

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

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

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

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

  • Настройка дополнительных резервных копий не поддерживается.

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

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

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

Доступность для серверов без HA

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

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

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

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

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

Плановый простой

Ниже перечислен ряд сценариев планового обслуживания.

Сценарий Описание
Увеличение/уменьшение масштаба вычислительных ресурсов Когда пользователь выполняет операцию вертикального увеличения или уменьшения масштаба вычислительных ресурсов, новый сервер базы данных подготавливается к работе с использованием масштабируемой конфигурации вычислений. На старом сервере базы данных ожидается завершение активных контрольных точек, останавливаются с отработкой клиентские подключения, все незафиксированные транзакции отменяются, и затем сервер останавливается. После этого хранилище отсоединяется от старого сервера базы данных и прикрепляется к новому серверу. Оно будет принимать все подключения.
Вертикальное увеличение масштаба хранилища Увеличение масштаба хранилища в настоящее время — автономная операция, включающая короткий простой.
Развертывание нового программного обеспечения (Azure) Развертывание новых компонентов или исправлений производится автоматически, в составе планового обслуживания службы. Дополнительные сведения см. в документации, а также на портале.
Обновление промежуточных версий База данных Azure для PostgreSQL автоматически обновляет серверы баз данных, устанавливая промежуточные версии с номером дополнительной версии, определенным Azure. Это происходит в процессе планового обслуживания службы. Такое обновление вызывает краткосрочный простой, порядка нескольких секунд, после чего автоматически перезапускается сервер базы данных (уже с новой промежуточной версией). Дополнительные сведения см. в документации, а также на портале.

Незапланированный простой

Внеплановые простои могут возникнуть в результате непредвиденных сбоев, в том числе сбоев оборудования, обеспечивающего работу систем, отказов сети или программных ошибок. Если сервер базы данных непредвиденно прекращает работу, за считаные секунды подготавливается к работе новый сервер базы данных. Удаленное хранилище автоматически подсоединяется к этому новому серверу. Ядро СУБД PostgreSQL выполняет операцию восстановления, используя журналы WAL и файлы базы данных, а затем открывает сервер базы данных и разрешает клиентам подключаться к нему. Незафиксированные транзакции будут утеряны, и приложениям потребуется выполнить их повторно. Хотя избежать внепланового простоя невозможно, гибкий сервер сокращает длительность таких простоев, автоматически выполняя операции восстановления как на сервере базы данных, так и на уровнях хранилища без вмешательства пользователя.

Ниже перечислены некоторые сценарии сбоев и способы автоматического восстановления гибкого сервера:

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

Время восстановления (RTO) зависит от различных факторов, в том числе от выполнявшихся на момент сбоя действий (например, крупных транзакций) и от объемов восстановления, которое необходимо выполнить в ходе процесса запуска сервера базы данных.

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

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

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

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

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

Часто задаваемые вопросы

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

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

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

  • Можно ли выбрать зоны доступности для главного и резервного серверов?
    Для HA в одной зоне можно выбрать только главный сервер. Для HA с избыточностью между зонами можно выбирать как главные, так и резервные AZ.

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

  • Можно ли одновременно развернуть HA с избыточностью между зонами и HA в одной зоне?
    Нет. Вы можете развернуть только один из этих вариантов.

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

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

  • Синхронный режим создает задержки. Как это повлияет на производительность моего приложения?
    Настройка высокого уровня доступности приводит к задержке операций записи и фиксации. Но не влияет на запросы на чтение. Влияние на производительность зависит от рабочей нагрузки. Как правило, влияние на операции записи и фиксации может составлять около 20–30 %.

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

  • Можно ли включить и отключить высокий уровень доступности в любой момент времени?

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

  • Можно ли выбрать зону доступности для резервного сервера?
    Нет. В настоящее время невозможно выбрать зону доступности для резервного сервера. Мы планируем добавить эту возможность в будущем.

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

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

  • Можно ли использовать логическую репликацию серверов с высоким уровнем доступности?
    Можно настроить логическую репликацию с высоким уровнем доступности. Однако после отработки отказа сведения о логическом слоте не будут скопированы на резервный сервер. Таким образом сейчас обеспечивается ограниченная поддержка этой конфигурации.

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

  • Как происходит типичный процесс отработки отказа во время сбоя?
    Когда система мониторинга обнаруживает сбой, она инициирует рабочий процесс отработки отказа, который включает в себя применение к резервному серверу всех остаточных файлов WAL перед предоставлением к нему доступа для чтения и записи. После этого в службе DNS задается IP-адрес резервного сервера, прежде чем клиенты смогут повторно подключиться к серверу через ту же самую конечную точку (имя узла). Создается экземпляр резервного сервера для хранения конфигурации в режиме высокой доступности.

  • Что такое типичное время отработки отказа и ожидаемые потери данных во время сбоя?
    В стандартном случае время отработки отказа или простоя приложения не превышает 60–120 секунд. Этот период может быть больше в случаях, когда сбой происходит во время длительных транзакций, создания индекса или интенсивных операций записи, так как на выполнение процесса восстановления для резервного сервера может потребоваться больше времени.

    Так как репликация выполняется в синхронном режиме, потери данных не ожидается.

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

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

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

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

    В psql можно выполнить команду select * from pg_stat_replication;, которая помимо других сведений отображает состояние потоковой передачи.

  • Поддерживаются ли запросы на чтение для резервной реплики?
    Нет. Мы не поддерживаем запросы на чтение для резервной реплики.

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

Дальнейшие действия