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

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

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

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

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

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

Компонент	Description	Рекомендации
Автоматическое резервное копирование	База данных Azure для PostgreSQL гибкий сервер автоматически выполняет ежедневные резервные копии файлов базы данных и постоянно создает резервные копии журналов транзакций. Резервные копии могут храниться от 7 до 35 дней. Вы можете восстановить сервер базы данных в любой момент времени в течение периода хранения резервных копий. RTO зависит от размера данных для восстановления + времени на восстановление журнала. Это может быть от нескольких минут до 12 часов. Для получения дополнительной информации см. Основные понятия — резервное копирование и восстановление.	Данные резервного копирования остаются в пределах региона.
Высокий уровень доступности с избыточностью в пределах зоны	База данных Azure для PostgreSQL гибкий сервер можно развернуть с конфигурацией высокого уровня доступности с избыточностью между зонами (HA), где первичные и резервные серверы развертываются в двух разных зонах доступности в пределах региона. Эта конфигурация высокой доступности защищает ваши базы данных от сбоев на уровне зоны, а также помогает сократить время простоя приложений во время запланированных и незапланированных простоев. Данные с первичного сервера реплицируются на резервную реплику в синхронном режиме. В случае нарушения работы основного сервера происходит автоматическое переключение сервера на резервную реплику. Ожидается, что RTO в большинстве случаев будет менее 120 секунд. Ожидается, что RPO будет нулевым (без потери данных). Для получения дополнительной информации см. Основные понятия — высокая доступность.	Поддерживается на уровнях вычислений общего назначения и оптимизированных для памяти. Доступно только в регионах, где доступно несколько зон.
Высокий уровень доступности в одной зоне	База данных Azure для PostgreSQL гибкий сервер можно развернуть с той же конфигурацией высокого уровня доступности зоны, где первичные и резервные серверы развертываются в одной зоне доступности в регионе. Эта конфигурация высокой доступности защищает ваши базы данных от сбоев на уровне узлов, а также помогает сократить время бездействия приложений во время запланированных и незапланированных простоев. Данные с первичного сервера реплицируются на резервную реплику в синхронном режиме. В случае нарушения работы основного сервера происходит автоматическое переключение сервера на резервную реплику. Ожидается, что RTO в большинстве случаев будет менее 120 секунд. Ожидается, что RPO будет нулевым (без потери данных). Для получения дополнительной информации см. Основные понятия — высокая доступность.	Поддерживается на уровнях вычислений общего назначения и оптимизированных для памяти.
Управляемые диски премиум-класса	Файлы базы данных хранятся в очень прочном и надежном управляемом хранилище премиум-класса. Это обеспечивает избыточность данных с тремя копиями реплики, хранящимися в зоне доступности, с возможностью автоматического восстановления данных. Для получения дополнительной информации см. Документацию по управляемым дискам.	Данные хранятся в зоне доступности.
Резервное копирование зоны с резервированием	База данных Azure для PostgreSQL гибкие резервные копии серверов автоматически и безопасно хранятся в хранилище, избыточном между зонами в регионе, если регион поддерживает зоны доступности. Во время сбоя уровня зоны, в котором подготовлен сервер, и если сервер не настроен с избыточностью зоны, вы по-прежнему можете восстановить базу данных с помощью последней точки восстановления в другой зоне. Для получения дополнительной информации см. Основные понятия — резервное копирование и восстановление.	Применимо только в регионах, где доступно несколько зон.
Геоизбыточное резервное копирование	База данных Azure для PostgreSQL гибкие резервные копии сервера копируются в удаленный регион. это помогает с ситуацией аварийного восстановления в случае сбоя основного сервера.	В настоящее время эта функция включена в выбранных регионах. В зависимости от размера восстанавливаемых данных и объема операций восстановления RTO и RPO увеличиваются.
Реплика чтения	Реплики чтения между регионами можно развернуть для защиты баз данных от сбоев на уровне региона. Реплики чтения обновляются асинхронно с применением технологии физической репликации PostgreSQL и могут отставать от основной реплики. Дополнительные сведения см. в разделе "Основные понятия" — реплики чтения.	Поддерживается на уровнях вычислений общего назначения и оптимизированных для памяти.

В таблице ниже сравниваются значения RTO и RPO в типичном сценарии рабочей нагрузки.

Возможность	С увеличивающейся производительностью	Общего назначения	Оптимизированные для памяти
Восстановление до точки во времени из резервной копии	Любая точка восстановления в течение периода хранения RTO — зависит RPO < 15 мин	Любая точка восстановления в течение периода хранения RTO — зависит RPO < 15 мин	Любая точка восстановления в течение периода хранения RTO — зависит RPO < 15 мин
Геовосстановление из геореплицированных резервных копий	RTO — зависит RPO < 1 ч	RTO — зависит RPO < 1 ч	RTO — зависит RPO < 1 ч
Реплики чтения	RTO — минуты* RPO < 5 мин*	RTO — минуты* RPO < 5 мин*	RTO — минуты* RPO < 5 мин*

* В некоторых случаях значения RTO и RPO могут быть намного выше. Это зависит от различных факторов: задержки между расположениями, объема передаваемых данных и, что важнее всего, рабочей нагрузки записи базы данных-источника.

Запланированные события простоя

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

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

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

Уменьшение продолжительности незапланированного простоя

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

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

Простой службы

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

• портал Azure баннер. Если подписка будет затронута, в портал Azure уведомлениях появится оповещение об ошибке службы.

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

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

• Уведомление по электронной почте: если вы настроили оповещения, уведомление по электронной почте будет поступать, когда сбой службы влияет на подписку и ресурс. Сообщения электронной почты поступают из "azure-noreply@microsoft.com". Текст сообщения начинается с "Оповещение журнала действий ... была вызвана проблемой службы для подписки Azure...". Дополнительные сведения о оповещениях о работоспособности служб см. в статье "Получение оповещений журнала действий" в уведомлениях службы Azure с помощью портал Azure.

Внимание

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

Незапланированный простой: сценарии сбоев и восстановление службы

Ниже приведены некоторые сценарии незапланированного сбоя и процесс восстановления.

Сценарий	Процесс восстановления [Серверы настроены без избыточности между зонами высокого уровня доступности]	Процесс восстановления [Серверы настроены с избыточностью между зонами высокого уровня доступности]
Сбой сервера базы данных	Если сервер базы данных не работает, Azure попытается перезапустить сервер базы данных. Если это не удастся, сервер базы данных будет перезапущен на другом физическом узле. Время восстановления (RTO) зависит от различных факторов, включая действие во время сбоя, например большую транзакцию, и объем восстановления, который необходимо выполнить во время запуска сервера базы данных. Приложения, использующие базы данных PostgreSQL, должны быть разработаны таким образом, чтобы они выявляли прерванные подключения и завершившиеся сбоем транзакции и пытались восстановить или повторить их.	Если обнаруживается сбой сервера базы данных, сервер переключается на резервный сервер, что сокращает время простоя. Дополнительные сведения см. на Странице концепций высокой доступности. Ожидается, что RTO составит 60–120 с без потери данных.
Сбой хранилища	Приложения не видят никакого влияния на любые проблемы, связанные с хранилищем, такие как сбой диска или повреждение физического блока. Поскольку данные хранятся в трех копиях, копия данных обслуживается уцелевшим хранилищем. Поврежденный блок данных автоматически восстанавливается, и автоматически создается новая копия данных.	Для всех редких и невосстановляемых ошибок, таких как весь хранилище, недоступно, База данных Azure для PostgreSQL гибкий экземпляр сервера выполняется отработка отказа в резервную реплику, чтобы сократить время простоя. Дополнительные сведения см. на Странице концепций высокой доступности.
Логические ошибки/ошибки пользователя	Чтобы исправить ошибки пользователя, такие как случайно отброшенные таблицы или неправильно обновленные данные, необходимо выполнить восстановление на определенный момент времени (PITR). При выполнении операции восстановления вы указываете настраиваемую точку восстановления, то есть время непосредственно перед возникновением ошибки. Если нужно восстановить лишь часть баз данных или отдельные таблицы, а не все базы данных на сервере базы данных, можно восстановить сервер баз данных в новый экземпляр, экспортировать из него эти таблицы с помощью команды pg_dump, а затем использовать команду pg_restore, чтобы восстановить эти таблицы в основную базу данных.	Эти ошибки пользователя не защищены высокой доступностью, так как все изменения реплицируются в резервную реплику синхронно. Для устранения таких ошибок необходимо выполнить восстановление на определенный момент времени.
Сбой зоны доступности	Для восстановления после сбоя на уровне зоны вы можете выполнить восстановление на определенный момент времени, используя резервную копию и выбрав настраиваемую точку восстановления с самым последним временем для восстановления последних данных. Новый База данных Azure для PostgreSQL гибкий экземпляр сервера развертывается в другой не затронутой зоне. Время, необходимое для восстановления, зависит от предыдущей резервной копии и объема восстанавливаемых журналов транзакций.	База данных Azure для PostgreSQL гибкий сервер автоматически выполняет отработку отказа на резервный сервер в течение 60–120 с нулевой потерей данных. Дополнительные сведения см. на Странице концепций высокой доступности.
Сбой региона	Если на сервере настроено геоизбыточное резервное копирование, можно выполнить геовосстановление в парном регионе. Новый сервер будет подготовлен и восстановлен до последней доступной информации, которая была скопирована в этот регион. Можно также использовать реплики чтения между регионами. В случае сбоя региона можно выполнить операцию аварийного восстановления, продвигая реплика чтения в качестве автономного сервера для чтения. Ожидается, что RPO составляет до 5 минут (возможна потеря данных), за исключением случаев серьезного регионального сбоя, когда RPO может быть близок к задержке репликации во время сбоя.	Тот же процесс.

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

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

Внимание

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

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

• Ознакомьтесь с моделями развертывания высокого уровня доступности
• Ознакомьтесь с дополнительными сведениями о резервном копировании и восстановлении.