Share via

Общие сведения об обеспечении непрерывности бизнес-процессов с помощью службы "База данных Azure для PostgreSQL" (отдельный сервер)

  • Статья

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

Внимание

База данных Azure для PostgreSQL — одиночный сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для PostgreSQL — гибкий сервер см. в статье "Что происходит с одним сервером База данных Azure для PostgreSQL?".

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

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

При разработке плана обеспечения непрерывности бизнес-процессов нужно понимать, какое максимальное время до полного восстановления приложения после аварийного события допустимо. Это целевое время восстановления (RTO). Необходимо также понимать, какой максимальный объем потери последних обновлений данных (т. е. за какой интервал времени) в приложении допустим при восстановлении после аварийного события. Это целевая точка восстановления (RPO).

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

Примечание.

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

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

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

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

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

Восстановление сервера после ошибки пользователя или приложения

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

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

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

Восстановление после отключения центра обработки данных Azure

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

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

Геовосстановление

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

Внимание

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

Реплики чтения в других регионах

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

Вопросы и ответы

Где База данных Azure для PostgreSQL хранит данные клиентов?

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

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