Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Непрерывность бизнес-процессов в Базе данных Azure для PostgreSQL относится к механизмам, политикам и процедурам, которые позволяют бизнесу продолжать работать в условиях нарушения работы, особенно в своей вычислительной инфраструктуре. В большинстве случаев База данных Azure для PostgreSQL обрабатывает разрушительные события, которые могут произойти в облачной среде и сохраняет выполнение приложений и бизнес-процессов. Однако некоторые события не могут обрабатываться автоматически, например:
- Пользователь случайно удаляет или обновляет строку в таблице.
- Землетрясение вызывает сбой электроэнергии и временно отключает зону доступности или регион.
- Исправление базы данных необходимо для исправления ошибки или проблемы с безопасностью.
База данных Azure для PostgreSQL предоставляет функции, которые защищают данные и сокращают время простоя ваших критически важных баз данных при плановых и внеплановых простоях. На основе инфраструктуры Azure, которая обеспечивает надежную устойчивость и доступность, База данных Azure для PostgreSQL имеет функции непрерывности бизнес-процессов, обеспечивающие другую защиту от сбоев, решение требований к времени восстановления и снижение риска потери данных. При разработке приложений учитывайте отказоустойчивость времени простоя — цель времени восстановления (RTO) и воздействие потери данных — цель точки восстановления (RPO). Например, для базы данных, критически важной для бизнеса, требуется более строгое время простоя, чем тестовая база данных.
В следующей таблице показаны возможности, которые предлагает База данных Azure для PostgreSQL.
| Функция | Описание | Рекомендации |
|---|---|---|
| Автоматическое резервное копирование | Гибкий экземпляр сервера Базы данных Azure для PostgreSQL автоматически выполняет ежедневные резервные копии файлов базы данных и постоянно создает резервные копии журналов транзакций. Резервные копии можно хранить от 7 дней до 35 дней. Сервер базы данных можно восстановить в любой момент времени в течение периода хранения резервных копий. RTO зависит от размера данных для восстановления и времени восстановления журнала. Это может быть от нескольких минут до 12 часов. Для получения дополнительной информации см. Основные понятия — резервное копирование и восстановление. | Данные резервного копирования остаются в пределах региона. |
| Высокий уровень доступности с избыточностью в пределах зоны | Вы можете развернуть гибкий сервер База данных Azure для PostgreSQL с конфигурацией высокой доступности (HA) с избыточностью по зонам, в которой основной и резервный серверы развертываются в двух разных зонах доступности в пределах одного региона. Эта конфигурация высокого уровня доступности защищает базы данных от сбоев на уровне зоны, а также помогает сократить время простоя приложения во время запланированных и незапланированных событий простоя. Данные с первичного сервера реплицируются на резервную реплику в синхронном режиме. В случае нарушения работы основного сервера происходит автоматическое переключение сервера на резервную реплику. Ожидается, что в большинстве случаев RTO будет менее 120 секунд. Ожидается, что RPO будет нулевым (без потери данных). Дополнительные сведения см. в разделе "Основные понятия — высокий уровень доступности". | Поддерживается в вычислительных уровнях общего назначения и уровнях, оптимизированных по памяти. Доступно только в регионах, где доступно несколько зон. |
| Высокий уровень доступности в одной зоне | Вы можете развернуть гибкий экземпляр сервера База данных Azure для PostgreSQL с той же конфигурацией высокого уровня доступности зоны, где первичные и резервные серверы развертываются в одной зоне доступности в регионе. Эта конфигурация высокого уровня доступности защищает базы данных от сбоев на уровне узла, а также помогает сократить время простоя приложения во время запланированных и незапланированных событий простоя. Данные с первичного сервера реплицируются на резервную реплику в синхронном режиме. В случае нарушения работы основного сервера происходит автоматическое переключение сервера на резервную реплику. В большинстве случаев ожидается, что RTO будет менее 120 секунд. Ожидается, что RPO будет нулевым (без потери данных). Дополнительные сведения см. в разделе [Основные понятия — высокий уровень доступности]/azure/надежность/надежность-postgresql-гибкий сервер. | Поддерживается в вычислительных уровнях общего назначения и уровнях, оптимизированных по памяти. |
| Управляемые диски премиум-класса | Файлы базы данных хранятся в очень прочном и надежном управляемом хранилище премиум-класса. Это хранилище обеспечивает избыточность данных с тремя копиями реплики, хранящейся в зоне доступности, с возможностями автоматического восстановления данных. Для получения дополнительной информации см. Документацию по управляемым дискам. | Данные хранятся в зоне доступности. |
| Резервное копирование с зональной избыточностью | Резервные копии экземпляров гибкого сервера База данных Azure для PostgreSQL автоматически и безопасно хранятся в зонально-избыточном хранилище в пределах региона, если регион поддерживает зоны доступности. Во время сбоя на уровне зоны, в которой развернут ваш сервер, если сервер не настроен на зональную избыточность, вы все равно можете восстановить базу данных, используя последнюю точку восстановления в другой зоне. Для получения дополнительной информации см. Основные понятия — резервное копирование и восстановление. | Применимо только в регионах, где доступно несколько зон. |
| Георезервное резервное копирование | Резервные копии экземпляров гибкого сервера базы данных Azure для PostgreSQL копируются в удаленный регион. Эта функция помогает с ситуацией аварийного восстановления в случае сбоя основного сервера. | В настоящее время эта функция включена в выбранных регионах. Время восстановления (RTO) становится дольше, а допустимая потеря данных (RPO) выше в зависимости от размера данных для восстановления и объема необходимых операций по восстановлению. |
| Реплика для чтения | Вы можете развернуть межрегиональные читающие реплики, чтобы защитить ваши базы данных от сбоев на уровне региона. Реплики для чтения обновляются асинхронно с использованием технологии физической репликации PostgreSQL и могут отставать от основного экземпляра. Для получения дополнительной информации см. раздел «Основные понятия — реплики для чтения». | Поддерживается в вычислительных уровнях общего назначения и уровнях, оптимизированных по памяти. |
В таблице ниже сравниваются значения RTO и RPO в типичном сценарии рабочей нагрузки.
| Способность | Всплесковая производительность | Производственный SKU (оптимизация для общего назначения/памяти) |
|---|---|---|
| Восстановление на точку во времени из резервной копии | Любая точка восстановления в течение периода хранения Время восстановления (RTO) — варьируется RPO < 5 минут |
Любая точка восстановления в течение периода хранения Время восстановления (RTO) — варьируется RPO < 5 минут |
| Геовосстановление из геореплицированных резервных копий | Время восстановления (RTO) — варьируется RPO < 1 ч |
Время восстановления (RTO) — варьируется RPO < 1 ч |
| Реплики для чтения | Не применимо | RTO — минуты* RPO — обычно от 30 с до 5 минут* |
| Высокий уровень доступности | Не применимо | RTO < 120 с RPO = 0 |
Запланированные события простоя
В следующей таблице описаны некоторые распространенные сценарии планового обслуживания. Эти события обычно вызывают несколько минут простоя, но не вызывают потери данных.
| Сценарий | Процесс |
|---|---|
| Масштабирование вычислений (инициированное пользователем) | Во время операции масштабирования вычислений процесс позволяет активным контрольным точкам завершить работу, очищает клиентские подключения, отменяет все незафиксированные транзакции, отсоединяет хранилище, а затем завершает работу. Процесс создает новый экземпляр гибкого сервера База данных Azure для PostgreSQL с тем же именем сервера базы данных, но с масштабированной конфигурацией вычислительных ресурсов. Процесс присоединяет хранилище к новому серверу и запускает базу данных, которая выполняет восстановление при необходимости перед принятием клиентских подключений. |
| Масштабирование хранилища (инициированное пользователем) | При запуске операции масштабирования хранилища процесс позволяет выполнять активные контрольные точки, очищать клиентские подключения и отменять все незафиксированные транзакции. После этого процесс завершает работу сервера. Процесс масштабирует хранилище до требуемого размера, а затем присоединяет его к новому серверу. Процесс выполняет восстановление при необходимости, прежде чем принимать клиентские подключения. Обратите внимание, что уменьшение размера хранилища не поддерживается. |
| Развертывание нового программного обеспечения (инициированное Azure) | Служба автоматически развертывает новые функции или исправления ошибок в рамках планового обслуживания. Вы можете запланировать, когда будут выполняться эти действия. Для получения дополнительной информации посетите свой портал. |
| Небольшие обновления версий (инициируемые Azure) | База данных Azure для PostgreSQL автоматически устанавливает патчи на серверы баз данных до минорной версии, определенной Azure. Это исправление происходит в рамках планового обслуживания службы. Процесс автоматически перезапускает сервер базы данных до новой минорной версии. Дополнительные сведения см. в этой документации. Вы также можете проверить ваш портал. |
При настройке гибкого экземпляра сервера База данных Azure для PostgreSQL с высокой доступностью служба сначала выполняет масштабирование и операции обслуживания на резервном сервере. Дополнительные сведения см. в разделе [Основные понятия — высокий уровень доступности]/azure/надежность/надежность-postgresql-гибкий сервер.
Уменьшение продолжительности незапланированного простоя
Незапланированные простои могут возникать в результате непредвиденных сбоев, таких как отказ основного оборудования, проблемы с сетью и ошибки программного обеспечения. Если сервер базы данных, настроенный с высоким уровнем доступности, неожиданно исчезает, служба активирует резервную реплику и клиенты могут возобновить свои операции. Если сервер не настроен с высоким уровнем доступности (HA), служба автоматически подготавливает новый сервер базы данных, если попытка перезапуска завершается сбоем. Хотя вы не можете избежать незапланированного простоя, База данных Azure для PostgreSQL помогает снизить время простоя, автоматически выполняя операции восстановления, не требуя вмешательства человека.
Хотя команда инженеров постоянно стремится обеспечить высокий уровень доступности, иногда возникает сбой База данных Azure для PostgreSQL, который приводит к недоступности баз данных и, таким образом, влияет на ваше приложение. Когда мониторинг служб обнаруживает проблемы, которые вызывают распространенные ошибки подключения, сбои или проблемы с производительностью, служба автоматически объявляет о сбое, чтобы держать вас в курсе.
Сбой в работе службы
Если экземпляр гибкого сервера База данных Azure для PostgreSQL становится недоступным, подробные сведения о сбое можно найти в следующих местах:
- Баннер портала Azure: Если ваша подписка затронута, в разделе Уведомления портала Azure отображается оповещение о сбое в работе службы.
- Справка и поддержка или Поддержка и устранение неполадок: при создании обращения в службу поддержки из Справка и поддержка или Поддержка и устранение неполадок портал включает сведения о любых проблемах, влияющих на ваши ресурсы. Выберите "Просмотреть сведения о сбое" для получения дополнительных сведений и сводки о влиянии. На странице "Новый запрос на поддержку " также содержится оповещение.
- Работоспособности служб. Страница работоспособности служб на портале Azure содержит сведения о состоянии центра обработки данных Azure глобально. Найдите "service health" в строке поиска на портале Azure, а затем просмотрите проблемы служб в категории Активные события. Вы также можете просмотреть работоспособность отдельных ресурсов на странице работоспособности ресурсов любого ресурса в меню справки. На следующем снимке экрана страницы "Работоспособность службы " отображаются сведения о активной проблеме службы в Юго-Восточной Азии.
- Уведомление по электронной почте: при настройке оповещений вы получаете уведомление по электронной почте, когда сбой службы влияет на подписку и ресурс. Сообщения электронной почты поступают из "azure-noreply@microsoft.com". Текст сообщения начинается с "Оповещение журнала действий ... было вызвано проблемой с подпиской Azure на услугу...". Дополнительные сведения об оповещениях о работоспособности служб см. в статье «Получение оповещений журнала действий об уведомлениях службы Azure с помощью портала Azure».
Это важно
Как подразумевает имя, временные пространства таблиц в PostgreSQL используются для временных объектов, а также для других внутренних операций базы данных, таких как сортировка. Поэтому не создавайте объекты схемы пользователя во временном табличном пространстве, так как сохранность этих объектов после перезапуска сервера, переключений при отказе в высокодоступной конфигурации и аналогичных событий не гарантируется.
Незапланированный простой: сценарии сбоев и восстановление службы
В следующей таблице описаны распространенные незапланированные сценарии сбоя и процесс восстановления.
| Сценарий |
Процесс восстановления [Серверы настроены без избыточности между зонами высокого уровня доступности] |
Процесс восстановления [Серверы, настроенные с зонально-избыточным HA] |
|---|---|---|
| Сбой сервера базы данных | Если сервер базы данных выходит из строя, Azure пытается перезапустить сервер базы данных. Если эта попытка завершается ошибкой, Azure перезапускает сервер базы данных на другом физическом узле. Время восстановления (RTO) зависит от различных факторов, включая действие во время сбоя, например большую транзакцию, и объем восстановления для выполнения во время запуска сервера базы данных. Приложения, использующие базы данных PostgreSQL, должны обнаруживать и повторять удаленные подключения и неудачные транзакции. |
Если обнаружен сбой сервера баз данных, происходит переключение на резервный сервер, что сокращает время простоя. Для получения дополнительной информации см. страницу [концепции HA]/azure/надежность/надежность-postgresql-гибкий-сервер. Ожидается, что RTO составляет 60–120 секунд с нулевой потерей данных. |
| Сбой хранилища | Приложения не видят никакого влияния на любые проблемы, связанные с хранилищем, такие как сбой диска или повреждение физического блока. Так как данные хранятся в трех копиях, сохраняющееся хранилище служит копией данных. Поврежденный блок данных автоматически восстанавливается, и автоматически создается новая копия данных. | При возникновении редких и неустранимых ошибок, например когда недоступно все хранилище, экземпляр гибкого сервера База данных Azure для PostgreSQL переключается на резервную реплику, чтобы уменьшить время простоя. Для получения дополнительной информации см. страницу [концепции HA]/azure/надежность/надежность-postgresql-гибкий-сервер. |
| Логические или пользовательские ошибки | Чтобы восстановиться после ошибок пользователя, таких как случайно удаленные таблицы или неправильно обновленные данные, выполните восстановление на определенный момент времени (PITR). При выполнении операции восстановления укажите пользовательскую точку восстановления, которая находится прямо перед ошибкой. Если вы хотите восстановить только подмножество баз данных или определенных таблиц, а не все базы данных на сервере базы данных, можно восстановить сервер базы данных в новом экземпляре, экспортировать таблицы с помощью pg_dump, а затем использовать pg_restore для восстановления этих таблиц в базе данных. |
Эти ошибки пользователя не защищены высокой доступностью, так как все изменения реплицируются в резервную реплику синхронно. Чтобы устранить последствия таких ошибок, необходимо выполнить восстановление на определённый момент времени. |
| Сбой зоны доступности | Чтобы восстановиться после сбоя на уровне зоны, выполните восстановление на определённый момент времени из резервной копии и выберите пользовательскую точку восстановления с самым поздним временем, чтобы восстановить самые актуальные данные. Разверните новый гибкий сервер База данных Azure для PostgreSQL в другой незатронутой зоне. Время, необходимое для восстановления, зависит от предыдущей резервной копии и объема восстанавливаемых журналов транзакций. | Экземпляр гибкого сервера База данных Azure для PostgreSQL автоматически переключается на резервный сервер в течение 60–120 секунд без потери данных. Для получения дополнительной информации см. страницу [концепции HA]/azure/надежность/надежность-postgresql-гибкий-сервер. |
| Сбой региона | Если на сервере настроено геоизбыточное резервное копирование, можно выполнить геовосстановление в парном регионе. Azure подготавливает и восстанавливает новый сервер до последних доступных данных, скопированных в этот регион. Можно также использовать кросс-региональные реплики чтения. В случае сбоя в регионе можно выполнить аварийное восстановление, повысив реплику для чтения до автономного сервера с возможностью чтения и записи. Ожидается, что RPO составляет до пяти минут (возможна потеря данных), за исключением случаев серьезного регионального сбоя, когда RPO может быть близок к задержке репликации во время сбоя. |
Тот же процесс. |
Настройка базы данных после восстановления из регионального сбоя
- Если вы используете геовосстановление или геореплику для восстановления после сбоя, убедитесь, что подключение к новому серверу настроено правильно, чтобы нормальная функция приложения может возобновиться. Следуйте задачам после восстановления.
- Если вы ранее настроили параметр диагностики на исходном сервере, убедитесь, что он установлен на целевом сервере при необходимости, как описано в разделе "Настройка и доступ к журналам" в База данных Azure для PostgreSQL.
- Чтобы настроить оповещения телеметрии, убедитесь, что существующие параметры правила генерации оповещений обновляются для сопоставления с новым сервером. Дополнительные сведения о правилах генерации оповещений см. на портале Azure для настройки оповещений о метриках для Базы данных Azure для PostgreSQL.
Это важно
Вы можете восстановить удаленные серверы. При удалении сервера следуйте инструкциям в статье "Восстановление удаленного сервера для восстановления". Используйте блокировку ресурсов Azure, чтобы предотвратить случайное удаление вашего сервера.