Share via

Высокая доступность в Базе данных Azure для PostgreSQL (отдельный сервер)

  • Статья

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

Внимание

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

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

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

Компоненты Базы данных Azure для PostgreSQL (отдельный сервер)

Компонент Description
Сервер Postgre База данных SQL База данных Azure для PostgreSQL реализует функции безопасности, изоляции, средства защиты ресурсов и возможность быстрого перезапуска серверов баз данных. Эти возможности облегчают выполнение таких операций, как масштабирование и восстановление сервера базы данных после сбоя, которые производятся за считаные секунды.
Изменения данных на сервере базы данных обычно происходят в контексте транзакции базы данных. Все изменения базы данных записываются синхронно в виде журналов на основе операций записи (WAL) на служба хранилища Azure, которая подключена к серверу базы данных. В процессе отработки контрольных точек базы данных страницы данных из памяти сервера базы данных также сбрасываются в хранилище.
Удаленные служба хранилища Все файлы физических данных PostgreSQL и файлы журналов WAL хранятся в службе хранилища Azure, архитектура которой предусматривает сохранение трех копий данных в рамках одного региона для обеспечения избыточности, доступности и надежности хранения данных. Уровень хранения также независим от сервера базы данных. Его можно отсоединить от сервера базы данных, на котором произошел сбой, и подсоединить к новому серверу базы данных за несколько секунд. Кроме того, служба хранилища Azure постоянно отслеживает хранилище на предмет любых ошибок. При обнаружении повреждения блока оно автоматически исправляется посредством создания экземпляра новой копии хранилища.
Шлюз Шлюз выступает в качестве прокси-сервера базы данных и направляет все клиентские подключения к серверу базы данных.

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

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

Снимок экрана: эластичная масштабирование в Azure PostgreSQL.

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

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

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

Снимок экрана: высокий уровень доступности в Azure PostgreSQL.

  1. Серверы Azure PostgreSQL с возможностями быстрого масштабирования.
  2. Шлюз, который выступает в качестве прокси-сервера для маршрутизации клиентских подключений к соответствующему серверу базы данных.
  3. Служба хранилища Azure с тремя копиями для обеспечения надежности, доступности и избыточности.
  4. Удаленное хранилище также позволяет быстро отсоединяться и повторно подсоединяться к нему после отработки отказа сервера.

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

Ниже приведен ряд сценариев отказов и описано автоматическое восстановление Базы данных Azure для PostgreSQL в таких случаях.

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

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

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

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

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

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

Итоги

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

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