Высокая доступность

Настройте резервные реплики и режимы репликации для обеспечения высокой доступности в ClickHouse Managed Postgres

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

​

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

​

2 резервных экземпляра

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

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

​

1 резервный экземпляр

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

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

​

Без резервного экземпляра

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

​

Резервные экземпляры и реплики для чтения

Резервные экземпляры и реплики для чтения выполняют разные задачи в Managed Postgres и настраиваются отдельно.

Резервные экземпляры предназначены исключительно для высокой доступности и автоматического переключения при отказе. Они реплицируют данные с основного экземпляра с помощью потоковой репликации и всегда готовы стать основными в случае его отказа. Резервные экземпляры не используются для запросов на чтение.

Реплики для чтения предназначены для масштабирования чтения. Они получают данные WAL (Write-Ahead Log) из объектного хранилища и работают в отдельной сетевой среде, используя собственную конечную точку подключения. Реплики для чтения позволяют перенести нагрузку от операций чтения с основного экземпляра без ущерба для гарантий высокой доступности.

​

Почему резервные экземпляры не выполняют запросы на чтение

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

Есть две основные причины:

1. Конкуренция с воспроизведением WAL: При интенсивной записи запросы на чтение на резервном экземпляре конкурируют с воспроизведением WAL за системные ресурсы. Из-за этого может возникать существенная задержка репликации, то есть резервный экземпляр начинает отставать от основного экземпляра. Если переключение при отказе произойдёт, пока резервный экземпляр отстаёт, на нём не будет самых свежих данных, и он может оказаться не готов без сбоев взять на себя роль основного.

2. Помехи для VACUUM: Длительные запросы на чтение на резервном экземпляре могут мешать VACUUM (и AUTOVACUUM) очищать мёртвые кортежи на основном экземпляре. PostgreSQL не может удалить строки, к которым активный запрос на любой реплике всё ещё может обратиться. Со временем это может привести к разрастанию таблиц и снижению производительности.

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

​

Обработка сбоев

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

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