Часто задаваемые вопросы

Зачем клиентам использовать прокси-сервер stolon?

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

Почему вы не использовали уже существующий прокси, например haproxy?

Для нашей потребности принудительно закрывать соединения с неизбранными мастерами и обрабатывать хранителей/часовых, которые могут появляться и исчезать и менять свои адреса, мы внедрили специальный прокси, который напрямую считывает своё состояние из хранилища. Благодаря горутинам на языке Go это происходит очень быстро.

Мы открыты для альтернативных решений (приветствуются PR), таких как использование haproxy, если они могут соответствовать вышеуказанным требованиям. Например, гипотетический прокси на основе haproxy должен иметь возможность работать с изменяющимися IP-адресами, получать текущую информацию о кластере и иметь возможность принудительно закрыть соединение, когда бэкенд haproxy помечен как неисправный (обратите внимание, что для достижения последнего возможное решение, требующее тестирования, будет заключаться в использовании опции сервера haproxy on-marked-down shutdown-sessions).

Отправляет ли прокси-сервер stolon запросы только для чтения на резервные серверы?

В настоящее время прокси перенаправляет все запросы на мастер. Существует запрос функции для использования прокси также для резервных серверов, но он находится в конце списка приоритетов.

Существует простой скрипт на Python, который получает информацию о резервных серверах от stolonctl и генерирует конфигурацию HAProxy: UnitedTraders/stolon-standby-haproxy.

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

Почему при использовании stolon не требуется общее хранилище и ограждение?

stolon устраняет необходимость общего хранилища, поскольку он использует потоковую репликацию postgres и может избежать необходимости ограждения (убить узел, лишить доступа к общему хранилищу и т. д.) благодаря своей архитектуре:

• Он использует etcd/consul в качестве первого шага для определения того, какие компоненты исправны.
• Прокси-сервер stolon является своего рода ограждением, так как он закроет соединения со старыми мастерами и направит новые соединения к текущему мастеру.

Чем stolon отличается от чистой высокой доступности kubernetes?

Чистый подход kubernetes к достижению высокой доступности postgres заключается в использовании постоянных томов и statefulsets (petsets). Использование постоянных томов означает, что вы не потеряете ни одной транзакции. В настоящее время k8s требует ограждения, чтобы избежать повреждения данных при использовании statefulsets с постоянными томами (см. https://github.com/kubernetes/kubernetes/pull/34160).

Вместо этого stolon использует потоковую репликацию postgres для обеспечения высокой доступности. Чтобы избежать потери какой-либо транзакции, вы можете включить синхронную репликацию.

С stolon у вас также есть другие плюсы:

• В настоящее время обнаружение сбоев узлов/выселение подов в k8s занимает минуты, в то время как stolon по умолчанию обнаруживает сбои за секунды.
• На облачных провайдерах, таких как aws, том EBS привязан к зоне доступности, поэтому вы не можете выполнить аварийное переключение на другую зону доступности. С помощью stolon вы можете это сделать.
• Вы можете привязать данные экземпляра к определённому узлу, если не хотите использовать постоянные тома, такие как AWS EBS.
• Вы можете легко развёртывать и управлять новыми кластерами
• обновлять спецификацию кластера
• обновлять параметры postgres
• Выполнять восстановление на момент времени
• Создавать кластеры stolon с главным/резервным сервером (будущее улучшение).
• Легко масштабировать компоненты stolon.

Чем stolon отличается от pacemaker?

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

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

Что происходит при разделении etcd/Consul?

См. «Архитектура Stolon и требования» (architecture.md).

Как выполняются резервные копии с помощью Stolon?

Stolon позволяет легко интегрироваться с любым решением для резервного копирования и восстановления. См. «Восстановление на момент времени» (pitr.md) и пример wal-e (pitr_wal-e.md).

Каким образом Stolon решает, какой резервный сервер должен быть повышен до главного?

При использовании асинхронной репликации ведущий Sentinel пытается найти лучший резервный сервер, используя доступный резервный сервер с ближайшим местоположением xlog к последнему известному местоположению xlog мастера. Если мастер не работает, нет способа узнать его последнее местоположение xlog (Stolon получает и сохраняет его через определённые промежутки времени), поэтому невозможно гарантировать, что резервный сервер не отстаёт, а просто будет выбран лучший из доступных резервных серверов.

При синхронной репликации будут выбраны только синхронные резервные серверы, поэтому отстающие от мастера резервные серверы выбраны не будут (обратите внимание на ограничения синхронной репликации PostgreSQL, объяснённые в документации PostgreSQL, например, когда мастер перезапускается, пока синхронные резервные сервера недоступны, транзакции, ожидающие подтверждения на мастере, будут помечены как полностью зафиксированные. Это «исправлено» Stolon. См. документацию по синхронной репликации (syncrepl.md).

Использует ли Stolon методы кворума синхронной репликации PostgreSQL (FIRST или ANY)?

Уже существует аналогичная, но более мощная и расширяемая функция, предоставляемая Stolon, которая управляется Sentinel с использованием параметров спецификации кластера MinSynchronousStandbys и MaxSynchronousStandbys (если вы хотите расширить её, пожалуйста, откройте запрос на новую функцию или запрос на вытягивание).

Мы намеренно не используем методы FIRST или ANY PostgreSQL с N, отличным от количества требуемых синхронных резервных серверов, потому что нам нужно, чтобы все определённые резервные серверы были синхронными (поэтому только один отказавший резервный сервер заблокирует основной).

Это необходимо для обеспечения согласованности. Если у нас есть 3 резервных сервера и мы используем FIRST 2 (a, b, c), Sentinel, когда мастер выходит из строя, не сможет определить, какой из 3 резервных серверов действительно является синхронным и синхронизирован с мастером. И выбор несинхронного приведёт к потере транзакций, содержащихся в записях wal, которые не были переданы.

Использует ли Stolon Consul в качестве DNS-сервера?

Consul (или etcd) используется только как хранилище ключей и значений.

Допустим, у меня несколько кластеров Stolon. Нужно ли мне отдельное хранилище (etcd или Consul) для каждого кластера Stolon?

Stolon будет создавать свои ключи, используя имя кластера как часть иерархии ключей. Таким образом, несколько кластеров Stolon могут совместно использовать одно хранилище.

Рекомендуется использовать хранилище, расположенное в том же регионе/центре обработки данных (понятия связаны с вашей архитектурой/поставщиком облачных услуг), что и кластер Stolon.