Компоненты сообщества PostgreSQL on PIG.CENTER

Примечания к выпускам pgBadger 13.x

Mon, 01 Jan 0001 00:00:00 +0000

Здесь полностью сохранена история изменений pgBadger 13.x из исходного проекта, от новых версий к старым.

v13.2 · 2025-12-29

Это выпуск pgBadger с исправлениями проблем и патчами, предложенные пользователями после предыдущего выпуска.

Исправлена нормализация, некорректно обрабатывавшая сбалансированные строки в одинарных кавычках с экранированными кавычками внутри. Спасибо Bertrand Bourgier за сообщение.
Исправлены требования к заполнителям в документации.
Исправлен случай, когда примеры строк журнала с ошибками не попадали в отчёт. Спасибо john doe за сообщение.
Исправлена возможная проблема приоритета между ! и %s. Спасибо Luca Santarelli и Philipp Trulson за сообщение.
Код pgFormatter обновлён до версии 5.9.
Добавлено действие GitHub CI для тестирования при отправке коммитов.
Исправлен разбор заполнителя %r в log_line_prefix. Спасибо nike7o0 за сообщение.
Исправлено предупреждение о неинициализированном значении. Спасибо Ales Zeleny за сообщение.
Документация по параметрам SSH для разбора журналов Postgres дополнена примерами. Спасибо Ulrich Konrad за патч.
Добавлена команда –ssh-sudo для запуска команд по SSH через sudo. Спасибо Andrew Jackson за патч.
Исправлена возможная проблема приоритета между ! и строковым eq. Спасибо Adrien Nayrat за сообщение.
Исправлен разбор статистики pgbouncer. Спасибо mrgtt за сообщение.

v13.1 · 2025-03-16

Это выпуск pgBadger с исправлениями проблем, о которых пользователи сообщили после предыдущего выпуска, и добавляет новые возможности:

YAML Параметры конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

Глобальный/Всемирный

thread_pool_size: размер пула потоков, используемый Patroni для выполнения асинхронных задач и обмена данными по REST API с другими участниками во время выбора лидера или проверок в аварийном режиме. Минимальное значение — 5, значение по умолчанию — 5.
thread_stack_size: указывает размер стека, используемый для потоков, запускаемых Patroni. Значение должно быть выровнено по 64kB. Минимальное значение — 64kB, значение по умолчанию (устанавливается Patroni) — 512kB.
name: имя хоста. Должно быть уникальным для кластера. Значение __patroni_strict_sync_replica_placeholder__ зарезервировано для внутреннего использования Patroni и не может использоваться в качестве имени узла.
namespace: путь внутри хранилища конфигурации, где Patroni будет хранить информацию о кластере. Значение по умолчанию: “/service”
scope: имя кластера

Введение

Mon, 01 Jan 0001 00:00:00 +0000

Patroni — шаблон решений высокой доступности (HA) PostgreSQL на Python. Patroni возник как ответвление проекта Governor от Compose и содержит множество новых возможностей.

Дополнительные вводные материалы:

PostgreSQL HA with Kubernetes and Patroni — доклад Джоша Беркуса на KubeCon 2016 (видео)
Публикация в техническом блоге Zalando за февраль 2016 года

Состояние разработки

Patroni активно разрабатывается и принимает вклады сообщества. Подробнее см. раздел Участие в разработке ниже.

Сведения о новых выпусках публикуются здесь .

Возможности

Mon, 01 Jan 0001 00:00:00 +0000

Несколько уровней строгости при перераспределении соединений:

Сеансовый режим пула

Наиболее щадящий метод. При подключении клиента ему назначается серверное соединение на всё время клиентского соединения. После отключения клиента серверное соединение возвращается в пул. Этот режим поддерживает все возможности PostgreSQL.

Транзакционный режим пула

Серверное соединение назначается клиенту только на время транзакции. Когда PgBouncer определяет завершение транзакции, серверное соединение возвращается в пул. Этот режим нарушает работу некоторых сеансовых возможностей PostgreSQL. Его можно использовать, только если приложение не применяет несовместимые возможности. Они перечислены в таблице ниже.

Режим пула на уровне операторов

Наиболее строгий метод. Это транзакционный режим пула с дополнительным ограничением: транзакции из нескольких операторов запрещены. Такой режим принудительно обеспечивает клиентский режим «autocommit» и в основном предназначен для PL/Proxy.
Низкое потребление памяти (по умолчанию 2 kB на соединение), поскольку PgBouncer не требуется получать пакеты целиком.

Настройки динамической конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

Динамическая конфигурация хранится в DCS (распределённое хранилище конфигурации) и применяется ко всем узлам кластера.

Чтобы изменить динамическую конфигурацию, можно использовать либо инструмент patronictl_edit_config , либо Patroni REST API .

loop_wait: количество секунд, в течение которых цикл будет спать. Значение по умолчанию: 10, минимально возможное значение: 1
ttl: TTL для получения блокировки лидера (в секундах). Представьте это как продолжительность времени до начала процесса автоматического переключения при отказе. Значение по умолчанию: 30, минимально возможное значение: 20
retry_timeout: тайм-аут повторных попыток операций DCS и PostgreSQL (в секундах). DCS или сетевые проблемы, короче этого времени, не приведут к демотированию лидера. Значение по умолчанию: 10, минимально возможное значение: 3

Предупреждение

при изменении значений loop_wait, retry_timeout или ttl необходимо соблюдать следующее правило:

Руководство для начинающих

Mon, 01 Jan 0001 00:00:00 +0000

Примечания к выпускам pgBadger 12.x

Mon, 01 Jan 0001 00:00:00 +0000

Здесь полностью сохранена история изменений pgBadger 12.x из исходного проекта, от новых версий к старым.

v12.4 · 2023-12-25

Это выпуск pgBadger с исправлениями проблем, о которых пользователи сообщили после предыдущего выпуска.

Исправлен отчёт pgbouncer для версии 1.21. Спасибо Ales Zeleny за патч.
Число параллельных процессов Perl больше не может превышать число файлов. Спасибо maliangzhu за сообщение.
Исправлен регрессионный тест, не работавший с версии 12.3. Спасибо ieshin за сообщение.
Исправлены случаи, когда записи LOG учитывались как записи уровня ERROR. Спасибо Matti Linnanvuori за сообщение.

v12.3 · 2023-11-27

Это выпуск pgBadger с исправлениями проблем, о которых пользователи сообщили после предыдущего выпуска. Он также добавляет новые возможности:

Основы балансировки нагрузки

Mon, 01 Jan 0001 00:00:00 +0000

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

Загрузка и установка

Mon, 01 Jan 0001 00:00:00 +0000

Выбор канала распространения

Канал	Для чего использовать	Где находится
Официальный выпуск	Архивы исходного кода и примечания к выпуску	Выпуски GitHub
Пакет RPM	Дистрибутивы Linux на базе RPM	Репозиторий PostgreSQL Yum
Пакет Debian/Ubuntu	Дистрибутивы Linux на базе APT	Репозиторий PostgreSQL Apt
Разрабатываемый исходный код	Текущий код, ещё не вошедший в выпуск	darold/pgbadger

Снимок документации на этом сайте основан на дереве исходного кода версии 13.2. Перед загрузкой всегда проверяйте страницу выпусков: локальный снимок намеренно зафиксирован, тогда как исходный проект продолжает выпускать новые версии.

Конфигурация: pgbouncer.ini

Mon, 01 Jan 0001 00:00:00 +0000

Описание

Файл конфигурации имеет формат «ini». Имена секций заключаются между [ и ]. Строки, начинающиеся с ; или #, считаются комментариями и игнорируются. Символы ; и # не имеют специального значения в других позициях строки.

Общие параметры

logfile

Задаёт файл журнала. Для демонизации (-d) обязательно задать этот параметр или syslog.

Файл журнала остаётся открытым, поэтому после ротации следует выполнить kill -HUP или RELOAD; в консоли. В Windows службу необходимо остановить и запустить.

Установка

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования для Mac OS

Чтобы установить необходимые компоненты на Mac, выполните:

brew install postgresql etcd haproxy libyaml python

Psycopg

Начиная с psycopg2-2.8 двоичная версия psycopg2 больше не устанавливается по умолчанию. Для установки из исходного кода необходим компилятор C и пакеты разработки postgres и python. Поскольку в экосистеме Python нельзя указать зависимость как psycopg2 OR psycopg2-binary, способ установки нужно выбрать самостоятельно.

Примечания к выпускам pgBadger 11.x

Mon, 01 Jan 0001 00:00:00 +0000

Здесь полностью сохранена история изменений pgBadger 11.x из исходного проекта, от новых версий к старым.

v11.8 · 2022-04-08

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

Исправлено обнаружение новых записей журнала по отметке времени, когда в log_line_prefix использовались миллисекунды (%m) или эпоха (%n).
Исправлено обнаружение новых записей в локальном файле без использования многопроцессной обработки.

Полный список изменений и благодарностей:

Что такое HAProxy и как он работает

Mon, 01 Jan 0001 00:00:00 +0000

Название «HAProxy» обозначает продукт, а «haproxy» — исполняемую программу, программный пакет или процесс. Однако оба варианта часто используются в обоих значениях и произносятся как H-A-Proxy. На раннем этапе «haproxy» расшифровывалось как «прокси высокой доступности», а название писалось в два отдельных слова, хотя сейчас оно означает только «HAProxy».

3.1. Чем является и чем не является HAProxy

HAProxy — это:

Использование команды pgbouncer

Mon, 01 Jan 0001 00:00:00 +0000

Синтаксис

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

Параметры для Windows:

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Дополнительные параметры для настройки службы Windows:

pgbouncer.exe --regservice <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

Описание

PgBouncer — менеджер пула соединений PostgreSQL. Любое клиентское приложение может подключаться к PgBouncer как к серверу PostgreSQL, а PgBouncer создаст соединение с настоящим сервером либо повторно использует одно из существующих соединений.

Справочник командной строки

Mon, 01 Jan 0001 00:00:00 +0000

На этой странице сохранён справочник команд, сгенерированный из зафиксированной версии исходного кода. Имена параметров и текст справки приведены дословно, чтобы их можно было непосредственно сопоставить с выводом pgbadger --help.

Использование и параметры

Использование: pgbadger [options] logfile […]

PostgreSQL log analyzer with fully detailed reports and graphs.

Аргументы:

logfile can be a single log file, a list of files, or a shell command
returning a list of files. If you want to pass log content from stdin
use - as filename. Note that input from stdin will not work with csvlog.

Параметры:

Настройки конфигурации среды

Mon, 01 Jan 0001 00:00:00 +0000

Возможно переопределить некоторые параметры конфигурации, определённые в файле конфигурации Patroni, с помощью переменных среды системы. В данном документе перечислены все переменные среды, обрабатываемые Patroni. Значения, установленные с помощью этих переменных, всегда имеют приоритет перед значениями, заданными в файле конфигурации Patroni.

Глобальный/Всемирный

PATRONI_CONFIGURATION: конфигурацию Patroni целиком можно задать с помощью переменной среды PATRONI_CONFIGURATION . В этом случае никакие другие переменные среды не будут учитываться!
PATRONI_THREAD_POOL_SIZE: размер пула потоков, используемый Patroni для выполнения асинхронных задач и обмена данными по REST API с другими участниками во время выбора лидера или проверок в аварийном режиме. Минимальное значение — 5, значение по умолчанию — 5.
PATRONI_THREAD_STACK_SIZE: указывает размер стека, используемый для потоков, запускаемых Patroni. Значение должно быть выровнено по 64kB. Минимальное значение — 64kB, значение по умолчанию (устанавливается Patroni) — 512kB.
PATRONI_NAME: имя узла, на котором выполняется текущая инстанция Patroni. Должно быть уникальным для кластера. Значение __patroni_strict_sync_replica_placeholder__ зарезервировано для внутреннего использования Patroni и не может использоваться в качестве имени узла.
PATRONI_NAMESPACE: путь в хранилище конфигурации, где Patroni будет хранить информацию о кластере. Значение по умолчанию: “/service”
PATRONI_SCOPE: имя кластера
PG_MALLOC_ARENA_MAX: пользовательское значение переменной среды MALLOC_ARENA_MAX для процесса postmaster. Если не задано, postmaster унаследует значение MALLOC_ARENA_MAX.

Журнал

PATRONI_LOG_TYPE: задаёт формат логов. Может быть либо plain, либо json. Для использования формата json необходимо установить jsonlogger . Значение по умолчанию — plain.
PATRONI_LOG_LEVEL: задаёт уровень ведения журнала. Значение по умолчанию — INFO (см. документацию по ведению журнала в Python )
PATRONI_LOG_TRACEBACK_LEVEL: задаёт уровень, на котором будут видны трассировки. Значение по умолчанию — ERROR. Установите значение DEBUG, если хотите видеть трассировки только при включении PATRONI_LOG_LEVEL=DEBUG.
PATRONI_LOG_FORMAT: задаёт строку форматирования журнала. Если тип журнала — plain, формат журнала должен быть строкой. См. атрибуты LogRecord для получения списка доступных атрибутов. Если тип журнала — json, формат журнала может быть списком, помимо строки. Каждый элемент списка должен соответствовать атрибуту LogRecord. Будьте осторожны: требуется только имя поля, а символы %( и ) опускаются. Если необходимо вывести поле журнала с другим именем ключа, используйте словарь, где ключ словаря — это поле журнала, а значение — имя поля, которое должно быть выведено в журнале. Значение по умолчанию: %(asctime)s %(levelname)s: %(message)s
PATRONI_LOG_DATEFORMAT: задаёт строку форматирования даты и времени. (см. документацию formatTime() )
PATRONI_LOG_STATIC_FIELDS: добавить дополнительные поля в лог. Этот параметр доступен только при установке типа лога в json. Пример PATRONI_LOG_STATIC_FIELDS="{app: patroni}"
PATRONI_LOG_MAX_QUEUE_SIZE: Patroni использует двухэтапное ведение журнала. Записи журнала записываются в очереди в оперативной памяти, а отдельный поток извлекает их из очереди и записывает в stderr или файл. Максимальный размер внутренней очереди по умолчанию ограничен 1000 записями, что достаточно для хранения журналов за последние 1 час 20 минут.
PATRONI_LOG_DIR: Каталог для записи журналов приложения. Каталог должен существовать и быть доступен для записи пользователем, запускающим Patroni. Если задан этот параметр среды, приложение по умолчанию сохраняет журналы 4 25MB. Значения хранения можно настроить с помощью PATRONI_LOG_FILE_NUM и PATRONI_LOG_FILE_SIZE (см. ниже).
PATRONI_LOG_MODE: Разрешения для файлов журнала (например, 0644). Если не указано, разрешения будут установлены на основе текущего значения umask.
PATRONI_LOG_FILE_NUM: Количество журналов приложений, которые необходимо сохранить.
PATRONI_LOG_FILE_SIZE: Размер файла patroni.log (в байтах), при достижении которого происходит смена лог-файла.
PATRONI_LOG_LOGGERS: Переопределение уровня ведения журнала для каждого модуля Python. Пример PATRONI_LOG_LOGGERS="{patroni.postmaster: WARNING, urllib3: DEBUG}"
PATRONI_LOG_DEDUPLICATE_HEARTBEAT_LOGS: Если установлено в true, последовательные журналы heartbeat, одинаковые по содержанию, не будут выводиться. Значение по умолчанию — false.

Предупреждение

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

Примечания к выпускам pgBadger 10.x

Mon, 01 Jan 0001 00:00:00 +0000

Здесь полностью сохранена история изменений pgBadger 10.x из исходного проекта, от новых версий к старым.

v10.3 · 2019-02-14

Это выпуск pgBadger с исправлениями нескольких проблем автоматического определения формата журнала и ещё одну ошибку разбора журнала pgBouncer, о которых сообщили пользователи. Также добавлена новая возможность:

Параметр -o | --outfile теперь можно указывать несколько раз, чтобы одной
командой вывести результат в нескольких форматах. Например:
 pgbadger -o out.html -o out.json /log/pgsql-11.log
создаст два отчёта в форматах HTML и JSON и сохранит их в соответствующих
файлах.

Также исправлены ошибки и улучшены возможности.

Patroni REST API

Mon, 01 Jan 0001 00:00:00 +0000

Patroni предоставляет обширный REST API. Сам Patroni использует его во время выбора лидера, инструмент patronictl — для аварийных и плановых переключений, повторной инициализации, перезапусков и перезагрузки конфигурации, а HAProxy и другие балансировщики — для проверок работоспособности HTTP. API также можно применять для мониторинга. Ниже перечислены конечные точки REST API Patroni.

Конечные точки проверки работоспособности

На все запросы проверки GET Patroni возвращает документ JSON с состоянием узла и код состояния HTTP. Если документ JSON не нужен, вместо GET можно использовать метод HEAD или OPTIONS.

Базовые возможности

Mon, 01 Jan 0001 00:00:00 +0000

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

3.3.1. Базовые возможности: проксирование

Проксирование — передача данных между клиентом и сервером по двум независимым соединениям. HAProxy поддерживает следующие базовые возможности проксирования и управления соединениями:

Предоставление серверу корректного соединения для защиты от любых ошибок или атак со стороны клиента.

Настройка журналирования PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger может отобразить только те сведения, которые PostgreSQL записывает в журнал. Начните с префикса, пригодного для разбора, и продуманной политики журналирования операторов, а затем добавьте эксплуатационные события, которые требуется анализировать.

Минимальное журналирование запросов

Чтобы включить текст и длительность запросов, включите журналирование операторов по длительности:

log_min_duration_statement = 0

Значение 0 записывает каждый завершённый оператор. На загруженном сервере выберите более высокий порог в миллисекундах, чтобы контролировать объём журнала. Прежде чем включать низкий порог в производственной среде, измерьте накладные расходы и рост хранилища.

Компиляция и установка PgBouncer

Mon, 01 Jan 0001 00:00:00 +0000

Сборка

Для компиляции PgBouncer требуется несколько компонентов:

GNU Make 3.81+
Libevent 2.0+
pkg-config
OpenSSL 1.0.1+ для поддержки TLS
(необязательно) c-ares как альтернатива evdns из Libevent
(необязательно) библиотеки LDAP
(необязательно) библиотеки PAM

После установки зависимостей выполните:

$ ./configure --prefix=/usr/local
$ make
$ make install

Для сборки из Git или под Windows используйте отдельные инструкции ниже.

Поддержка поиска DNS

PgBouncer разрешает имена узлов при установке соединения, а не только один раз при загрузке конфигурации. Для этого нужна асинхронная реализация DNS. В таблице перечислены поддерживаемые бэкенды в порядке их проверки:

Примечания к выпускам pgBadger 9.x

Mon, 01 Jan 0001 00:00:00 +0000

Здесь полностью сохранена история изменений pgBadger 9.x из исходного проекта, от новых версий к старым.

v9.2 · 2017-07-27

Этот выпуск pgBadger с исправлениями добавляет несколько новых возможностей.

Добавлен отчёт о расстоянии и оценке контрольных точек.
В форматировщик кода SQL добавлена поддержка ключевых слов AWS Redshift.
В удалённый режим добавлено автоматическое определение формата журнала, позволяющее удалённо разбирать журнал pgbouncer вместе с журналом PostgreSQL.

Также исправлены ошибки и улучшены возможности.

patronictl

Mon, 01 Jan 0001 00:00:00 +0000

Patroni предоставляет интерфейс командной строки patronictl , предназначенный главным образом для взаимодействия с REST API Patroni и DCS. Он упрощает операции с кластером и удобен как людям, так и сценариям.

Конфигурация

patronictl использует 3 раздела конфигурации:

ctl: способ аутентификации в REST API Patroni и проверки подлинности сервера. Подробнее см. параметры ctl ;
restapi: способ аутентификации в REST API Patroni и проверки подлинности сервера. Используется, только если конфигурации ctl недостаточно. patronictl в основном использует раздел restapi.authentication, если отсутствует ctl.authentication, и параметр restapi.cafile, если отсутствует ctl.cacert. Подробнее см. параметры REST API ;
DCS, например etcd: способ подключения и аутентификации в DCS, используемом Patroni.

Эти параметры можно получить из переменных окружения или файла конфигурации. Способы их задания описаны в соответствующих разделах Параметров конфигурации окружения и Параметров конфигурации YAML .

Загрузка исходных выпусков

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer 1.25

Файл	Дата	Размер	SHA256
pgbouncer-1.25.2.tar.gz	2026-05-08	865371 bytes	sha256
pgbouncer-1.25.1.tar.gz	2025-12-03	864801 bytes	sha256
pgbouncer-1.25.0.tar.gz	2025-11-09	863322 bytes	sha256

PgBouncer 1.24

Файл	Дата	Размер	SHA256
pgbouncer-1.24.1.tar.gz	2025-04-16	717796 bytes	sha256
pgbouncer-1.24.0.tar.gz	2025-01-10	706573 bytes	sha256

PgBouncer 1.23

Файл	Дата	Размер	SHA256
pgbouncer-1.23.1.tar.gz	2024-08-02	700025 bytes	sha256
pgbouncer-1.23.0.tar.gz	2024-07-03	694845 bytes	sha256

PgBouncer 1.22

Файл	Дата	Размер	SHA256
pgbouncer-1.22.1.tar.gz	2024-03-04	677351 bytes	sha256
pgbouncer-1.22.0.tar.gz	2024-01-31	670589 bytes	sha256

PgBouncer 1.21

Файл	Дата	Размер	SHA256
pgbouncer-1.21.0.tar.gz	2023-10-16	668211 bytes	sha256

PgBouncer 1.20

Файл	Дата	Размер	SHA256
pgbouncer-1.20.1.tar.gz	2023-08-09	638844 bytes	sha256
pgbouncer-1.20.0.tar.gz	2023-07-20	638020 bytes	sha256

PgBouncer 1.19

Файл	Дата	Размер	SHA256
pgbouncer-1.19.1.tar.gz	2023-05-31	623569 bytes	sha256
pgbouncer-1.19.0.tar.gz	2023-05-04	616947 bytes	sha256

PgBouncer 1.18

Файл	Дата	Размер	SHA256
pgbouncer-1.18.0.tar.gz	2022-12-12	600825 bytes	sha256

PgBouncer 1.17

Файл	Дата	Размер	SHA256
pgbouncer-1.17.0.tar.gz	2022-03-23	598294 bytes	sha256

PgBouncer 1.16

Файл	Дата	Размер	SHA256
pgbouncer-1.16.1.tar.gz	2021-11-11	591450 bytes	sha256
pgbouncer-1.16.0.tar.gz	2021-08-09	592136 bytes	sha256

PgBouncer 1.15

Файл	Дата	Размер	SHA256
pgbouncer-1.15.0.tar.gz	2020-11-19	588042 bytes	sha256

PgBouncer 1.14

Файл	Дата	Размер	SHA256
pgbouncer-1.14.0.tar.gz	2020-06-11	578955 bytes	sha256

PgBouncer 1.13

Файл	Дата	Размер	SHA256
pgbouncer-1.13.0.tar.gz	2020-04-27	574955 bytes	sha256

PgBouncer 1.12

Файл	Дата	Размер	SHA256
pgbouncer-1.12.0.tar.gz	2019-10-17	567465 bytes	sha256

PgBouncer 1.11

Файл	Дата	Размер	SHA256
pgbouncer-1.11.0.tar.gz	2019-08-27	571414 bytes	sha256

PgBouncer 1.10

Файл	Дата	Размер	SHA256
pgbouncer-1.10.0.tar.gz	2019-07-01	480571 bytes	sha256

PgBouncer 1.9

Файл	Дата	Размер	SHA256
pgbouncer-1.9.0.tar.gz	2018-08-13	469300 bytes	sha256

PgBouncer 1.8

Файл	Дата	Размер	SHA256
pgbouncer-1.8.1.tar.gz	2017-12-20	465930 bytes	sha256
pgbouncer-1.8.tar.gz	2017-12-19	465612 bytes	sha256

PgBouncer 1.7

Файл	Дата	Размер	SHA256
pgbouncer-1.7.2.tar.gz	2016-02-26	462374 bytes	sha256
pgbouncer-1.7.1.tar.gz	2016-02-18	461903 bytes	sha256
pgbouncer-1.7.tar.gz	2015-12-18	459080 bytes	sha256

PgBouncer 1.6

Файл	Дата	Размер	SHA256
pgbouncer-1.6.1.tar.gz	2015-09-03	431076 bytes	sha256
pgbouncer-1.6.tar.gz	2015-08-01	412700 bytes	sha256

PgBouncer 1.5

Файл	Дата	Размер	SHA256
pgbouncer-1.5.5.tar.gz	2015-04-09	336145 bytes	sha256
pgbouncer-1.5.4.tar.gz	2012-11-28	339610 bytes	sha256
pgbouncer-1.5.3.tar.gz	2012-09-12	339013 bytes	sha256
pgbouncer-1.5.2.tar.gz	2012-05-29	335338 bytes	sha256
pgbouncer-1.5.1.tar.gz	2012-04-17	334413 bytes	sha256
pgbouncer-1.5.tar.gz	2012-01-05	411488 bytes	sha256

PgBouncer 1.4

Файл	Дата	Размер	SHA256
pgbouncer-1.4.2.tgz	2011-06-16	283204 bytes	sha256
pgbouncer-1.4.1.tgz	2011-04-01	282728 bytes	sha256
pgbouncer-1.4.tgz	2011-01-11	231691 bytes	sha256

PgBouncer 1.3

Файл	Дата	Размер	SHA256
pgbouncer-1.3.4.tgz	2010-09-09	167957 bytes	sha256
pgbouncer-1.3.3.tgz	2010-05-10	167476 bytes	sha256
pgbouncer-1.3.2.tgz	2010-03-15	166756 bytes	sha256
pgbouncer-1.3.1.tgz	2009-07-06	161518 bytes	sha256
pgbouncer-1.3.tgz	2009-02-18	160154 bytes	sha256

PgBouncer 1.2

Файл	Дата	Размер	SHA256
pgbouncer-1.2.3.tgz	2008-08-08	145372 bytes	sha256
pgbouncer-1.2.2.tgz	2008-08-06	145017 bytes	sha256
pgbouncer-1.2.1.tgz	2008-08-04	144903 bytes	sha256
pgbouncer-1.2.tgz	2008-07-29	143915 bytes	sha256

PgBouncer 1.1

Файл	Дата	Размер	SHA256
pgbouncer-1.1.2.tgz	2007-12-10	122054 bytes	sha256
pgbouncer-1.1.1.tgz	2007-10-26	121042 bytes	sha256
pgbouncer-1.1.tgz	2007-10-09	120462 bytes	sha256

PgBouncer 1.0

Файл	Дата	Размер	SHA256
pgbouncer-1.0.8.tgz	2007-06-18	93636 bytes	sha256
pgbouncer-1.0.7.tgz	2007-04-19	93086 bytes	sha256
pgbouncer-1.0.6.tgz	2007-04-12	92244 bytes	sha256
pgbouncer-1.0.5.tgz	2007-04-11	91934 bytes	sha256
pgbouncer-1.0.4.tgz	2007-04-11	91889 bytes	sha256
pgbouncer-1.0.3.tgz	2007-04-11	91489 bytes	sha256
pgbouncer-1.0.2.tgz	2007-03-28	90555 bytes	sha256
pgbouncer-1.0.1.tgz	2007-03-15	89609 bytes	sha256
pgbouncer-1.0.tgz	2007-03-13	88587 bytes	sha256

Двоичные пакеты

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

Параллельная обработка

Mon, 01 Jan 0001 00:00:00 +0000

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

Параметр	Единица параллельной обработки	Лучше всего подходит для	Основное ограничение
`-j N` / `--jobs N`	части одного файла журнала	один большой журнал с произвольным доступом	на границах частей небольшое число запросов может быть продублировано или пропущено
`-J N` / `--Jobs N`	целые файлы журналов	множество независимых журналов	полезно только при достаточном числе файлов для постоянной загрузки рабочих процессов

Разделение одного большого файла с `-j`

$ pgbadger -j 8 /var/log/postgresql/postgresql.log

Алгоритм исходного проекта делит каждый файл на N диапазонов байтов, создаёт по одному процессу синтаксического анализа на диапазон, записывает временную двоичную статистику, а затем объединяет её в итоговый отчёт.

Стандартные возможности

Mon, 01 Jan 0001 00:00:00 +0000

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

3.4.1. Стандартные возможности: извлечение и преобразование сведений

HAProxy поддерживает получение сведений с помощью широкого набора функций извлечения образцов. Они извлекают отдельные сведения, называемые образцами, для немедленного использования. Это применяется для привязки сеансов, построения условий, вывода сведений в журналы или дополнения заголовков HTTP.

Инкрементальные отчёты

Mon, 01 Jan 0001 00:00:00 +0000

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

Создание ежедневных и еженедельных отчётов

Запускайте pgBadger после ежедневной ротации журнала и укажите постоянный каталог вывода:

0 4 * * * /usr/bin/pgbadger -I -q /var/log/postgresql/postgresql.log.1 -O /var/www/pg_reports/

Параметр -I включает инкрементальный режим, а -O выбирает каталог для двоичного состояния, календарного индекса и сгенерированных отчётов. pgBadger самостоятельно ведёт инкрементальное состояние в этом каталоге, поэтому --last-parsed не нужен, если только вы намеренно не хотите хранить файл состояния в другом месте.

Создание образов реплик и начальная инициализация

Mon, 01 Jan 0001 00:00:00 +0000

Patroni позволяет настраивать создание новой реплики и определять действия при начальной инициализации нового пустого кластера. Различие строго определено: Patroni создаёт реплики, только если для кластера в DCS присутствует ключ initialize. Если ключа initialize нет, Patroni выполняет начальную инициализацию исключительно на первом узле, получившем блокировку ключа initialize.

Начальная инициализация

PostgreSQL предоставляет команду initdb для инициализации нового кластера, и Patroni вызывает её по умолчанию. В некоторых случаях, особенно при создании нового кластера как копии существующего, встроенный метод необходимо заменить пользовательскими действиями. Patroni поддерживает сценарии пользователя для начальной инициализации новых кластеров и передаёт им обязательные аргументы, например имя кластера и путь к каталогу данных. Это настраивается в разделе bootstrap конфигурации Patroni. Например:

Расширенные возможности

Mon, 01 Jan 0001 00:00:00 +0000

3.5.1. Расширенные возможности: управление

HAProxy спроектирован для исключительно стабильной работы и безопасного управления в обычной рабочей среде. Он поставляется одним исполняемым файлом и не требует процедуры установки. Несколько версий легко могут сосуществовать: экземпляры можно и рекомендуется обновлять постепенно, в порядке важности, вместо одновременного переноса всех экземпляров. Файлы конфигурации удобно хранить под контролем версий. Проверка конфигурации выполняется отдельно от работающей службы, поэтому не нужно перезапускать службу, рискуя получить сбой. При проверке могут обнаруживаться сложные ошибки (например, правило, скрывающее другое правило, или неработоспособная привязка сеансов); для их устранения выдаются подробные предупреждения и рекомендации. Обратная совместимость конфигурации охватывает очень давние версии: версия 1.5 полностью поддерживала конфигурации версии 1.1, написанные 13 лет назад, а в 1.6 прекращена поддержка лишь почти неиспользуемых устаревших директив, которые можно заменить другими средствами. Обновление конфигурации и программы происходит плавно и без прерывания обслуживания: старые и новые процессы могут сосуществовать в системе, каждый обрабатывая свои соединения. При запуске выводятся состояние системы, параметры сборки и сведения о совместимости библиотек.

Команда справки (help)

Mon, 01 Jan 0001 00:00:00 +0000

Предоставляется три уровня справки. Если команда не указана, будет отображена общая справка. Если указана команда (e.g. pgbackrest help backup), будет отображено полное описание команды вместе со списком допустимых параметров. Если указать параметр вместе с командой (e.g. pgbackrest help backup type), будет отображено полное описание параметра применительно к команде.

Опции команды

Показать сведения о параметре помощи (`--help`)

Показать справку.

Отображает справку даже если команда help не указана и переопределяет опцию --version.

Журнал изменений

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer 1.25.x

2026-05-08 - PgBouncer 1.25.2 - «Человеческое прикосновение и новый поворот в полной неопределённости борьбе за титул»

Безопасность
- Исправлена CVE-2026-6664: целочисленное переполнение в коде разбора сетевых пакетов в PgBouncer до 1.25.2 позволяло обойти проверку границ и могло привести к аварийному завершению. Неаутентифицированный удалённый злоумышленник мог вывести PgBouncer из строя некорректным пакетом аутентификации SCRAM.
- Исправлена CVE-2026-6665: код SCRAM в PgBouncer до 1.25.2 неверно проверял возвращаемое значение strlcat() при построении содержимого SCRAM client-final-message. Злонамеренный бэкенд, отправивший SCRAM server-final-message с длинным nonce, мог вызвать переполнение стека.
- Исправлена CVE-2026-6666: возможное обращение по нулевому указателю в PgBouncer до 1.25.2 могло привести к аварийному завершению, если сервер отправлял ответ об ошибке без поля SQLSTATE.
- Исправлена CVE-2026-6667: PgBouncer до 1.25.2 не выполнял надлежащую проверку авторизации для административной команды KILL_CLIENT. Её могли выполнять все пользователи с доступом к административной консоли, хотя сама консоль требует авторизации. Команда должна быть разрешена только пользователям, перечисленным в параметре admin_users.
Исправления

Расчёт ресурсов и производительность

Mon, 01 Jan 0001 00:00:00 +0000

Типичные показатели использования CPU: в режиме TCP или HTTP с закрытием соединений на HAProxy приходится 15% времени обработки, а на ядро — 85%; в режиме постоянных соединений HTTP на HAProxy приходится около 30%, а на ядро — 70%. Это означает, что операционная система и её настройка сильно влияют на общую производительность.

Сценарии использования сильно различаются: одни пользователи ориентируются на пропускную способность, другие — на интенсивность запросов, число одновременных соединений или производительность SSL. В этом разделе приведены некоторые сведения, помогающие оценить необходимые ресурсы.

Режимы репликации

Mon, 01 Jan 0001 00:00:00 +0000

Patroni использует потоковую репликацию PostgreSQL. Подробнее см. документацию Postgres . По умолчанию Patroni настраивает PostgreSQL на асинхронную репликацию. Выбор схемы репликации зависит от требований бизнеса. Изучите асинхронную и синхронную репликацию, а также другие решения HA, чтобы выбрать подходящий вариант.

Долговечность в асинхронном режиме

В асинхронном режиме ради доступности кластер может потерять часть зафиксированных транзакций. При отказе или недоступности первичного сервера Patroni автоматически повышает достаточно исправный резервный сервер до первичного. Транзакции, не реплицированные на этот резервный сервер, остаются в «ответвившейся временной шкале» первичного и фактически невосстановимы¹.

Форматы вывода

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger выбирает формат вывода по расширению имени файла либо по параметру -x / --extension. Укажите -o / --outfile несколько раз, чтобы создать несколько форматов из одного результата разбора.

Формат	Обычное расширение	Оптимальное применение
HTML	`.html`	интерактивный, удобный для чтения отчёт с диаграммами
Текст	`.txt`	просмотр в терминале и простое архивирование
Двоичный	`.bin`	объединяемая промежуточная статистика и пересборка отчётов
JSON	`.json`	интеграция с другим ПО; требует `JSON::XS`
Необработанный CSV	выбранный файл вывода	построчное извлечение с `--dump-raw-csv`

HTML и текст

По умолчанию результат записывается в out.html:

Выпуски, пакеты и обновления

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy — проект с открытым исходным кодом под лицензией GPLv2. Это означает, что его разрешено распространять при условии предоставления доступа к исходному коду по запросу, особенно если в него внесены изменения.

HAProxy развивается в основной ветке разработки «master» или «mainline», от которой создают новые ветки, когда код считается стабильным. Многие сайты добровольно используют ветки разработки в рабочей среде — чтобы участвовать в проекте или потому, что им нужна самая новая функция. Их обратная связь очень ценна для исправления ошибок и оценки общего качества и стабильности разрабатываемой версии.

Примеры отчётов

Mon, 01 Jan 0001 00:00:00 +0000

Примеры были созданы pgBadger 11.8 в мае 2022 года. Исходные примеры хранятся на этом сайте, поэтому навигация, диаграммы, стили и сценарии отчётов доступны без обращения к серверу исходного проекта.

Пример	Что он демонстрирует	Локальная копия
Полный отчёт	Активность PostgreSQL вместе со статистикой PgBouncer	Открыть полный отчёт
Инкрементальный отчёт	Календарный индекс, еженедельное агрегирование и ежедневные страницы	Открыть индекс инкрементальных отчётов
Ошибки и события	Отчёт, ограниченный ошибками и эксплуатационными событиями	Открыть отчёт об ошибках

Полный отчёт

Полный отчёт — автономный HTML-документ. С помощью верхней панели навигации можно изучить общую статистику, запросы, сеансы, соединения, временные файлы, контрольные точки, активность autovacuum, блокировки и диаграммы, относящиеся к PgBouncer.

Резервный кластер

Mon, 01 Jan 0001 00:00:00 +0000

Patroni также поддерживает настройку каскадной репликации на удалённый центр обработки данных (регион) с использованием функции, называемой «резервный кластер». Такие кластеры обладают следующими характеристиками:

«резервный лидер», который ведёт себя примерно как обычный лидер кластера, за исключением того, что реплицирует данные с удалённого узла.
каскадные реплики, которые реплицируют данные с резервного сервера.

Резервный сервер-лидер удерживает и обновляет блокировку лидера в DCS. Если блокировка лидера истекает, каскадные реплики выполнят голосование для выбора другого лидера из резервных серверов.

Сообщество

Mon, 01 Jan 0001 00:00:00 +0000

Учебные материалы

Настройка PgBouncer для Postgres Plus Standard Server

Хороший обзор основных понятий PgBouncer.
Зачем нужен PgBouncer?

Рассматривает различия между режимами пула.

Поддержка

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

Mon, 01 Jan 0001 00:00:00 +0000

Как подключиться к PgBouncer?

PgBouncer работает как сервер Postgres, поэтому достаточно направить клиент на порт PgBouncer.

Как распределять запросы между несколькими серверами?

PgBouncer не имеет встроенной конфигурации для нескольких узлов. Распределение можно реализовать внешними средствами:

Циклический перебор DNS. Укажите несколько IP-адресов для одного имени DNS. PgBouncer не выполняет поиск DNS при каждом новом соединении: он кэширует все IP-адреса и перебирает их циклически. Обратите внимание: если с одним именем связано более 8 IP-адресов, бэкенд DNS должен поддерживать протокол EDNS0. Подробности приведены в README.

Поддержка сторожевого таймера

Mon, 01 Jan 0001 00:00:00 +0000

Запуск нескольких серверов PostgreSQL в качестве первичных может привести к потере транзакций из-за расхождения временных шкал. Такая ситуация также называется проблемой расщепленного мозга. Чтобы избежать проблемы расщепленного мозга, Patroni должен обеспечить, чтобы PostgreSQL не принимал никаких подтверждений транзакций после истечения срока действия ключа лидера в DCS. В нормальных условиях Patroni пытается достичь этого, останавливая PostgreSQL при неудаче обновления блокировки лидера по любой причине. Однако это может не произойти по различным причинам:

Сопутствующие продукты и альтернативы

Mon, 01 Jan 0001 00:00:00 +0000

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

4.1. HTTP-сервер Apache

Apache — фактический стандарт среди серверов HTTP. Это очень функциональный модульный проект, поддерживающий как выдачу файлов, так и динамическое содержимое. Он может служить фронтендом для серверов приложений, а также проксировать запросы и кешировать ответы. Во всех этих сценариях перед ним обычно требуется балансировщик нагрузки. Apache может работать в разных режимах, одни из которых требуют больше ресурсов, чем другие. Некоторые модули до сих пор требуют более тяжёлой модели с заранее созданными процессами, что мешает Apache эффективно работать с большим числом соединений. В таком случае HAProxy может значительно помочь: он ограничивает число соединений с каждым сервером безопасным значением, заметно ускоряя сервер и сохраняя его ресурсы для приложения.

Как настроить демонстрационный кластер etcd

Mon, 01 Jan 0001 00:00:00 +0000

На каждом узле etcd укажите участников кластера:

TOKEN=token-01
CLUSTER_STATE=new
NAME_1=machine-1
NAME_2=machine-2
NAME_3=machine-3
HOST_1=10.240.0.17
HOST_2=10.240.0.18
HOST_3=10.240.0.19
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

Выполните следующее на каждой машине:

# For machine 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

Или воспользуйтесь общедоступной службой обнаружения:

Режим приостановки/возобновления для кластера

Mon, 01 Jan 0001 00:00:00 +0000

Цель

В некоторых случаях Patroni должен временно прекратить управление кластером, сохраняя при этом состояние кластера в DCS. Возможные сценарии использования — редкие операции с кластером, такие как обновление до новой версии или восстановление после повреждения. В ходе таких операций узлы часто запускаются и останавливаются по причинам, неизвестным Patroni, некоторые узлы могут даже временно повышаться до статуса первичного сервера, что нарушает предположение о наличии только одного первичного сервера. Поэтому Patroni должен уметь «отключаться» от работающего кластера, реализуя эквивалент режима обслуживания, как в Pacemaker.

Поддержка и участие в разработке

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger развивается как открытый проект. Сообщения об ошибках, предложения функций, исправления документации и патчи принимаются через репозиторий исходного проекта на GitHub.

Ошибки и запросы функций

Обновитесь до самой новой выпущенной версии и убедитесь, что проблема сохраняется.
Поищите готовый ответ среди открытых задач и закрытых задач .
Сведите проблему к минимальному безопасному фрагменту журнала и командной строке, на которых она всё ещё воспроизводится.
Удалите учётные данные, конфиденциальный SQL, значения параметров, имена узлов, адреса и деловые данные.
Создайте новую задачу , указав версию pgBadger, операционную систему, формат ввода, точные параметры, наблюдаемый и ожидаемый результаты.

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

Документация и сообщество

Mon, 01 Jan 0001 00:00:00 +0000

1. Доступная документация

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

intro.txt (этот документ): здесь представлены основы балансировки нагрузки, HAProxy как продукт, его возможности и ограничения, известные подводные камни, которых следует избегать, некоторые ограничения конкретных ОС, способы получения, развитие проекта, способы убедиться, что используются все известные исправления, обновление, дополнения и альтернативы.

DCS Отказоустойчивый режим

Mon, 01 Jan 0001 00:00:00 +0000

Проблема

Patroni активно использует распределённое хранилище конфигурации (DCS) для решения задачи выбора лидера и обнаружения сетевых разделений. Узел может запускать PostgreSQL как первичный сервер только в том случае, если ему удаётся обновить блокировку лидера в DCS. В случае неудачи обновления блокировки лидера PostgreSQL немедленно понижается до режима только для чтения. Вероятность возникновения «проблемы» зависит от используемого DCS. Например, при использовании etcd, который применяется исключительно для Patroni, вероятность близка к нулю, тогда как при использовании K8s API (основанного на etcd) такая ситуация может возникать чаще.

Лицензия и благодарности

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger — свободное программное обеспечение с открытым исходным кодом, распространяемое по лицензии PostgreSQL. Его можно бесплатно использовать, копировать, изменять и распространять при условии сохранения уведомлений об авторских правах и лицензии.

Лицензия PostgreSQL

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

Руководство по конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

1. Краткое напоминание об HTTP

Mon, 01 Jan 0001 00:00:00 +0000

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

Когда HAProxy работает в режиме HTTP, и запрос, и ответ полностью анализируются и индексируются. Это позволяет строить критерии сопоставления практически по любым элементам содержимого.

Команда сервера (server)

Mon, 01 Jan 0001 00:00:00 +0000

Сервер pgBackRest позволяет осуществлять доступ с удалённых хостов без использования протокола SSH.

Опции команды

TLS Параметр адреса сервера (`--tls-server-address`)

Адрес сервера TLS.

IP-адрес, на котором сервер будет слушать запросы клиентов.

default: localhost
example: --tls-server-address=*

TLS Параметр авторизованных клиентов сервера (`--tls-server-auth`)

TLS сервер авторизованных клиентов.

Клиенты авторизуются на сервере путём проверки их сертификата и проверки соответствия имени субъекта (CN) сертификата списку на сервере, настроенного с помощью опции tls-server-auth.

Использование Patroni с Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Patroni может использовать объекты Kubernetes для хранения состояния кластера и управления ключом лидера. Это позволяет работать с Postgres в среде Kubernetes без дополнительного хранилища согласованности, то есть не требуется запуск отдельного развёртывания etcd. Patroni может использовать два различных типа объектов Kubernetes для хранения ключей лидера и конфигурации, которые настраиваются с помощью переменной среды kubernetes.use_endpoints или PATRONI_KUBERNETES_USE_ENDPOINTS.

Используйте конечные точки

Несмотря на то что этот режим рекомендуется, по соображениям совместимости он отключён по умолчанию. Когда он включён, Patroni хранит конфигурацию кластера и ключ лидера в полях metadata: annotations соответствующих Endpoints, которые он создаёт. Смена лидера безопаснее, чем при использовании ConfigMaps, поскольку одновременно обновляются и аннотации, содержащие информацию о лидере, и фактические адреса, указывающие на запущенный под-лидер.

2. Настройка HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

2.1. Формат файла конфигурации

Процесс конфигурации HAProxy включает 3 основных источников параметров:

аргументы из командной строки, которые всегда имеют приоритет
конфигурационный файл, формат которого описан здесь
окружение запущенного процесса, в случае если явно указаны переменные среды

Конфигурационный файл следует довольно простому иерархическому формату, который соблюдает несколько базовых правил:

1. a configuration file is an ordered sequence of statements

2. a statement is a single non-empty line before any unprotected "#" (hash)

3. a line is a series of tokens or "words" delimited by unprotected spaces or
 tab characters

4. the first word or sequence of words of a line is one of the keywords or
 keyword sequences listed in this document

5. all other words are all arguments of the first one, some being well-known
 keywords listed in this document, others being values, references to other
 parts of the configuration, or expressions

6. certain keywords delimit a section inside which only a subset of keywords
 are supported

7. a section ends at the end of a file or on a special keyword starting a new
 section

Это всё, что нужно знать, чтобы написать простой, но надёжный генератор конфигурации, но это недостаточно для надёжного парсинга любой конфигурации и для определения того, как обрабатывать определённые крайние случаи.

Команда проверки доступности сервера (server-ping)

Mon, 01 Jan 0001 00:00:00 +0000

Проверьте доступность сервера pgBackRest TLS с помощью ping, чтобы убедиться, что он принимает соединения. Это служит проверкой работоспособности, так как аутентификация не выполняется.

Если на командной строке не указан хост, будет использован параметр tls-server-host.

Опции команды

TLS Параметр адреса сервера (`--tls-server-address`)

Адрес сервера TLS.

IP-адрес, на котором сервер будет слушать запросы клиентов.

default: localhost
example: --tls-server-address=*

Параметр порта сервера TLS (`--tls-server-port`)

Порт сервера TLS.

Поддержка Citus

Mon, 01 Jan 0001 00:00:00 +0000

Patroni делает развертывание кластеров Multi-Node Citus чрезвычайно простым.

TL;DR

Существует лишь несколько простых правил, которым необходимо следовать:

Расширение базы данных Citus для PostgreSQL должно быть доступно на всех узлах. Абсолютно минимальная поддерживаемая версия Citus — 10.0, но для использования всех преимуществ прозрачных плановых переключений и перезапусков рабочих узлов рекомендуется как минимум Citus 11.2.
Имя кластера (scope) должно быть одинаковым для всех узлов Citus!
Учётные данные суперпользователя должны быть одинаковыми на координаторе и всех рабочих узлах, а pg_hba.conf должен разрешать доступ суперпользователя между всеми узлами.
REST API доступ должен быть разрешён с узлов-работников к координатору. E.g, учётные данные должны быть одинаковыми, и, если настроены, клиентские сертификаты с узлов-работников должны быть приняты координатором.
Добавьте следующий раздел в patroni.yaml:

citus:
 group: X  # 0 for coordinator and 1, 2, 3, etc for workers
 database: citus  # must be the same on all nodes

После этого вам нужно просто запустить Patroni, и он сам займётся остальным:

Преобразование отдельного экземпляра в кластер Patroni

Mon, 01 Jan 0001 00:00:00 +0000

В этом разделе описано преобразование отдельного экземпляра PostgreSQL в кластер Patroni.

Чтобы развернуть кластер Patroni без существующего экземпляра PostgreSQL, обратитесь к разделу Запуск и настройка .

Процедура

Ниже приведён обзор преобразования существующего кластера Postgres в кластер под управлением Patroni. Предполагается, что все узлы существующего кластера работают и во время миграции вы не намерены менять конфигурацию Postgres. Выполните следующие действия:

Создайте пользователей Postgres, как описано в разделе аутентификации конфигурации Patroni. В блоке SQL ниже приведены примеры команд; замените имена пользователей и пароли в соответствии со своим окружением. Если необходимые пользователи уже существуют, пропустите этот шаг.

Интеграция с другими инструментами

Mon, 01 Jan 0001 00:00:00 +0000

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

Barman

Patroni предоставляет приложение с именем patroni_barman, в котором реализована логика взаимодействия с pg-backup-api, что позволяет выполнять операции Barman удалённо.

У данного приложения в настоящее время имеется несколько подкоманд: recover и config-switch.

5. Параметры bind и server

Mon, 01 Jan 0001 00:00:00 +0000

Ключи “bind”, “server” и “default-server” поддерживают ряд настроек, зависящих от некоторых опций сборки и от системы, на которой был собран HAProxy. Эти настройки в целом состоят из одного слова, иногда сопровождаемого значением, записанным на той же строке, что и строка “bind” или “server”. Все эти опции описаны в этой секции.

5.1. Параметры bind

Ключ “bind” поддерживает определённое количество настроек, которые передаются как аргументы на той же строке. Порядок, в котором эти аргументы приводятся, не имеет значения, при условии, что они находятся после адреса привязки. Все эти параметры являются необязательными. Некоторые из них состоят из одного слова (логические значения), в то время как другие ожидает значение после них. В этом случае значение должно быть указано немедленно после имени настройки.

Аспекты безопасности

Mon, 01 Jan 0001 00:00:00 +0000

Кластер Patroni имеет два интерфейса, которые необходимо защитить от несанкционированного доступа: хранилище распределённой конфигурации (DCS) и REST API Patroni (REST) (API).

Защита DCS

Patroni и patronictl хранят и извлекают данные из DCS.

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

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

6. Кеш

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy предоставляет кеш, предназначенный для небольших объектов (favicon, css и т. п.). Это минималистичный кеш в оперативной памяти, не требующий сложного обслуживания.

Кеш использует общую для всех потоков область памяти, разделённую на блоки по 1kB.

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

HA-кластер с несколькими центрами обработки данных

Mon, 01 Jan 0001 00:00:00 +0000

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

В обоих случаях важно четко понимать следующие понятия:

PostgreSQL может работать в качестве первичного сервера или резервного сервера-лидера только тогда, когда он владеет ключом лидера и может обновлять этот ключ.
Рекомендуется запускать нечётное количество узлов etcd, ZooKeeper или Consul: 3 или 5!

Синхронная репликация

Для создания кластера с несколькими ЦО, способного автоматически переживать отказ зоны, требуется как минимум 3.

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

Mon, 01 Jan 0001 00:00:00 +0000

В этом разделе приведены ответы на самые частые вопросы о Patroni. Каждый подраздел посвящён отдельной категории вопросов.

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

Сравнение с другими решениями HA

Почему Patroni требует отдельный кластер узлов DCS, а другие решения наподобие repmgr — нет?
Решения HA можно реализовать разными способами, каждый со своими преимуществами и недостатками.

Примечания к выпускам

Mon, 01 Jan 0001 00:00:00 +0000

Версия 4.1.5

Выпущено 2026-08-12

Улучшения совместимости

Совместимость с PostgreSQL 14.24, 15.19, 16.15, 17.11, 18.6 (Alexander Kukushkin)

Добавьте новый output_plugin_libraries GUC, который ограничивает вывод плагинов логического декодирования.

Улучшения

Записывать REST предупреждения о сбросе API соединений в DEBUG вместо WARNING (Kyle McLaren)

Убедитесь, что распространенные варианты “клиент неожиданно завершил операцию записи” не влияют на обработку реальных (не связанных с соединением) ошибок.

Исправления ошибок

Исправить выравнивание при проверке thread_stack_size (Sundong Kim)

9. Поддерживаемые фильтры

Mon, 01 Jan 0001 00:00:00 +0000

Ниже перечислены официально поддерживаемые фильтры и принимаемые ими параметры. В зависимости от параметров сборки некоторые фильтры могут быть недоступны. Список доступных фильтров выводится командой haproxy -vv.

См. также: «filter».

9.1. Трассировка

filter trace [name <name>] [random-forwarding] [max-fwd <max>] [hexdump]

Аргументы:

<name> is an arbitrary name that will be reported in
 messages. If no name is provided, "TRACE" is used.

<quiet> inhibits trace messages.

<random-forwarding> enables the random forwarding of parsed data. By
 default, this filter forwards all previously parsed
 data. With this parameter, it only forwards a random
 amount of the parsed data.

<max> is the maximum amount of data that can be forwarded at
 a time. "max-fwd" option can be combined with the
 random forwarding. <max> must be an positive integer.
 0 means there is no limit.

<hexdump> dumps all forwarded data to the server and the client.

Этот фильтр можно использовать как основу для разработки новых фильтров. Он определяет все обратные вызовы и для каждого из них выводит в стандартный поток ошибок (stderr) сообщение с полезными сведениями. Это может пригодиться для отладки работы других фильтров или самого HAProxy.

Команда версии (version)

Mon, 01 Jan 0001 00:00:00 +0000

Отображает установленную версию pgBackRest.

Опции команды

Параметр вывода (`--output`)

Тип вывода.

Поддерживаются следующие типы вывода:

text — Отображает установленную версию pgBackRest в виде текста.
num — Отображает установленную версию pgBackRest в виде целого числа.

default: text
example: --output=num

Чтение из etcd

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Установите etcdctl

Процедура

Используйте подкоманду get для чтения из etcd:

$ etcdctl --endpoints=$ENDPOINTS get foo
foo
Hello World!
$

где:

foo — запрашиваемый ключ
Hello World! — полученное значение

Или для форматированного вывода:

$ etcdctl --endpoints=$ENDPOINTS --write-out="json" get foo
{"header":{"cluster_id":289318470931837780,"member_id":14947050114012957595,"revision":3,"raft_term":4,
"kvs":[{"key":"Zm9v","create_revision":2,"mod_revision":3,"version":2,"value":"SGVsbG8gV29ybGQh"}]}}
$

где write-out="json" заставляет выводить значение в формате JSON (обратите внимание, ключ не возвращается).

10. Приложения FastCGI

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy может отправлять запросы HTTP приложениям FastCGI с ролью Responder. Эта возможность добавлена в HAProxy 2.1. Для её использования серверы необходимо настроить на протокол FastCGI (с помощью «proto fcgi» в строке server), а в управляющем ими бэкенде нужно настроить и подключить приложение FastCGI (с помощью «use-fcgi-app» в секции прокси). Можно определить несколько приложений FastCGI, но бэкенд одновременно может использовать только одно из них.

11. Таблицы привязок и одноранговые узлы

Mon, 01 Jan 0001 00:00:00 +0000

Таблицы привязок в HAProxy — это механизм, позволяющий ассоциировать определённое количество информации и метрик с ключом определённого типа на определённый срок после последнего обновления. Это можно рассматривать как строку в таблице с несколькими столбцами, где номер строки определяется значением ключа, а столбцы представляют отдельные критерии.

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

12. Другие секции

Mon, 01 Jan 0001 00:00:00 +0000

Секции, описанные ниже, реже используются и обычно поддерживают лишь несколько параметров. Между ними нет неявной связи. Они все начинаются с одного ключевого слова. Ни одна из них не допускается до секции “global”. Поддержка некоторых из них может зависеть от опций сборки (например, что касается SSL).

12.1. Трассировка

Для отладки можно включить трассировку подсистемы HAProxy. При этом выводятся отладочные сообщения об определённой подсистеме. Это мощное средство диагностики проблем. Трассировку можно динамически настраивать через CLI. Некоторые параметры также можно заранее задать в файле конфигурации, в отдельных секциях “traces”. Подробнее о трассировке см. руководство по управлению. Это инструмент разработчика для сложных сеансов отладки. Он выводит много сообщений и требует дополнительных ресурсов, поэтому используйте его осторожно. Поскольку это инструмент разработчика, обратная совместимость этой секции не гарантируется.

Руководство по управлению

Mon, 01 Jan 0001 00:00:00 +0000

1. Предварительные требования

Mon, 01 Jan 0001 00:00:00 +0000

В этом документе описаны запуск, остановка, управление HAProxy и устранение неполадок, а также некоторые известные ограничения и подводные камни, которых следует избегать. Настройка HAProxy здесь не рассматривается (об этом читайте в configuration.txt ).

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

Запись в etcd

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные условия

Установите etcdctl

Процедура

Используйте подкоманду put для записи пары «ключ — значение»:

etcdctl --endpoints=$ENDPOINTS put foo "Hello World!"

где:

foo — имя ключа
"Hello World!" — значение, заключённое в кавычки

2. Архитектура HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy — многопоточный неблокирующий демон с событийной архитектурой. Это означает, что для планирования всех своих действий он использует мультиплексирование событий, вместо того чтобы полагаться на системный планировщик при переключении между ними. Чаще всего он работает как один процесс, поэтому вывод “ps aux” в системе показывает только один процесс “haproxy”, кроме случаев, когда идёт плавная перезагрузка конфигурации и старый процесс завершает работу параллельно с новым. Поэтому его работу всегда легко отслеживать с помощью утилиты strace. Чтобы масштабироваться с ростом числа доступных процессоров, по умолчанию haproxy запускает по одному рабочему потоку на каждый процессор, на котором ему разрешено выполняться. Если явно не задана иная конфигурация, входящий трафик распределяется между всеми этими потоками, каждый из которых выполняет один и тот же цикл событий. Особое внимание уделяется сведению зависимостей между потоками к строгому минимуму, чтобы добиться масштабируемости, близкой к линейной. Это имеет ряд следствий, в частности каждое соединение обслуживается одним потоком. Поэтому для использования всей доступной вычислительной мощности необходимо как минимум столько же соединений, сколько потоков, что почти всегда обеспечивается.

3. Запуск HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy запускается путём вызова программы “haproxy” с передачей на командной строке нескольких аргументов. Фактический синтаксис следующий:

$ haproxy [<options>]*

где [<options>]* — произвольное число параметров. Параметр всегда начинается с ‘-’, за которым следуют одна или несколько букв и, возможно, один или несколько дополнительных аргументов. Без параметров HAProxy показывает страницу справки с перечнем поддерживаемых параметров. Доступные параметры могут немного различаться в зависимости от операционной системы. Многие из них имеют аналоги в секции “global”. В таком случае командная строка всегда имеет приоритет над файлом конфигурации, что позволяет быстро принудительно задать настройки, не изменяя конфигурационные файлы. Текущий список параметров:

4. Остановка и перезапуск HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy поддерживает плавную и жёсткую остановку. Жёсткая остановка проста: при отправке процессу haproxy сигнала SIGTERM он немедленно завершается, а все установленные соединения закрываются. Плавная остановка запускается сигналом SIGUSR1, отправленным процессу haproxy. При этом процесс лишь освобождает прослушиваемые порты, продолжая обрабатывать существующие соединения до их закрытия. После закрытия последнего соединения процесс завершается.

Жёсткая остановка используется для действий «stop» и «restart» сценария управления службой. Плавная остановка применяется для действия «reload», которое пытается незаметно для клиентов загрузить новую конфигурацию в новом процессе.

5. Ограничения файловых дескрипторов

Mon, 01 Jan 0001 00:00:00 +0000

Чтобы обеспечить успешное обслуживание всех входящих соединений, HAProxy при загрузке вычисляет общее число файловых дескрипторов, которые потребуются за время жизни процесса. Обычному процессу Unix по умолчанию обычно предоставляется 1024 файловых дескриптора, а привилегированный процесс может самостоятельно увеличить этот лимит. Это одна из причин запускать HAProxy от имени root и позволять ему настроить лимит. Лимит по умолчанию в 1024 файловых дескриптора позволяет обслуживать примерно 500 одновременных соединений. Расчёт основан на глобальном параметре maxconn, ограничивающем общее число соединений на процесс, числе слушателей, числе серверов с включённой проверкой работоспособности, агентских проверках, одноранговых узлах, получателях журналов и, возможно, нескольких других технических потребностях. Для грубой оценки достаточно удвоить значение maxconn и добавить несколько десятков: получится приблизительное число необходимых файловых дескрипторов.

6. Управление памятью

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy использует простое и быстрое управление памятью на основе пулов. Поскольку он работает с небольшим числом различных типов объектов, гораздо эффективнее брать новые объекты из пула, уже содержащего объекты подходящего размера, чем вызывать malloc() для каждого отдельного размера. Пулы организованы как стек, или LIFO: при выделении используются недавно освобождённые объекты, которые ещё находятся в кэшах CPU. Пулы близких размеров объединяются, чтобы ограничить фрагментацию памяти.

Как получить ключи по префиксу

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Получить ключи по префиксу

$ etcdctl --endpoints=$ENDPOINTS get PREFIX --prefix

Глобальные параметры

--endpoints=[127.0.0.1:2379], gRPC endpoints

Параметры

--prefix, get a range of keys with matching prefix

Пример

etcdctl --endpoints=$ENDPOINTS put web1 value1
etcdctl --endpoints=$ENDPOINTS put web2 value2
etcdctl --endpoints=$ENDPOINTS put web3 value3

etcdctl --endpoints=$ENDPOINTS get web --prefix

7. Использование CPU

Mon, 01 Jan 0001 00:00:00 +0000

Обычно HAProxy проводит большую часть времени в системном режиме, а меньшую — в пользовательском пространстве. Тщательно настроенный CPU с частотой 3.5 GHz способен поддерживать около 80000 установок и закрытий сквозных соединений в секунду при загрузке CPU 100% на одном ядре. При полной загрузке одного ядра типичны следующие показатели:

95% в системном режиме, 5% в пользовательском — для длительных соединений TCP или больших объектов HTTP;
85% в системном режиме и 15% в пользовательском — для коротких соединений TCP или маленьких объектов HTTP в режиме закрытия соединений;
70% в системном режиме и 30% в пользовательском — для маленьких объектов HTTP в режиме постоянных соединений.

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

8. Ведение журнала

Mon, 01 Jan 0001 00:00:00 +0000

Для ведения журнала HAProxy всегда использует сервер syslog, поскольку сам не обращается к файловой системе. Стандартный способ — отправлять журналы по UDP на сервер журналирования (по умолчанию на порт 514). Очень часто используется адрес 127.0.0.1, где работает локальный демон syslog, но также применяется передача по сети на центральный сервер. Центральный сервер даёт дополнительные преимущества, особенно в схемах active-active, где желательно объединять журналы в порядке поступления. HAProxy может отправлять журналы локальному демону syslog и через сокет UNIX, но это совершенно не рекомендуется: если сервер syslog перезапустить во время работы haproxy, сокет будет заменён, а новые записи журналов будут теряться. Поскольку HAProxy изолирован в окружении chroot, он не сможет повторно подключиться к новому сокету. На практике также наблюдалось, что буферы журналирования сокетов UNIX очень малы, из-за чего сообщения теряются даже при очень низкой нагрузке. Однако для тестирования такой вариант вполне допустим.

10. Упрощение управления конфигурацией

Mon, 01 Jan 0001 00:00:00 +0000

Очень часто два узла HAProxy, образующие кластер, используют совершенно одинаковую конфигурацию, за исключением нескольких адресов. Вместо того чтобы сопровождать отдельную копию конфигурации для каждого узла, которые неизбежно начнут различаться, можно включить в конфигурацию переменные окружения. Тогда несколько конфигураций смогут использовать один и тот же файл, различаясь лишь несколькими общесистемными переменными окружения. Эта возможность появилась в версии 1.5, где переменные окружения допускались только в адресах; версия 1.6 расширяет их поддержку на все параметры. Синтаксис такой же, как в оболочке UNIX: переменная начинается со знака доллара (’$’), за которым следуют открывающая фигурная скобка (’{’), имя переменной и закрывающая скобка (’}’). За исключением адресов, переменные окружения интерпретируются только в аргументах, заключённых в двойные кавычки (это ограничение было необходимо, чтобы не нарушить работу существующих конфигураций с регулярными выражениями, содержащими знак доллара).

11. Известные подводные камни, которых следует избегать

Mon, 01 Jan 0001 00:00:00 +0000

Время от времени кто-нибудь сообщает, что после перезагрузки системы служба haproxy не запустилась, но при ручном запуске работает. Чаще всего такие пользователи применяют механизм кластерного IP-адреса, например keepalived, чтобы назначать IP-адрес службы только главному узлу. Пока haproxy был привязан к адресу 0.0.0.0, всё работало, но после привязки к виртуальному IP-адресу запуск перестал удаваться. Причина в том, что при запуске службы виртуальный IP-адрес ещё не принадлежит локальному узлу, и, когда HAProxy пытается к нему привязаться, система отклоняет запрос, поскольку адрес не локальный. Решение состоит не в задержке запуска службы haproxy (это не помогло бы при перезапуске), а в правильной настройке системы, разрешающей привязку к нелокальным адресам. В Linux это легко сделать, установив параметр sysctl net.ipv4.ip_nonlocal_bind в 1. Это также необходимо для прозрачного перехвата IP-трафика, проходящего через HAProxy к определённому адресу назначения.

12. Отладка и проблемы производительности

Mon, 01 Jan 0001 00:00:00 +0000

При запуске HAProxy с параметром «-d» процесс остаётся на переднем плане и выводит по строке на каждое событие — входящее соединение, завершение соединения, каждую встреченную строку заголовка запроса или ответа. Этот отладочный вывод формируется до обработки содержимого, поэтому локальные изменения в нём не учитываются. Основное назначение — показывать запросы и ответы без запуска анализатора сетевого трафика. При одновременной обработке нескольких соединений вывод читается хуже, но скрипты «debug2ansi» и «debug2html» из каталога examples/ заметно помогают, раскрашивая его.

13. Соображения безопасности

Mon, 01 Jan 0001 00:00:00 +0000

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

Чтобы выполнить chroot, процесс сначала нужно запустить от имени root. Создавать окружения chroot вручную и запускать процесс уже внутри них бессмысленно: их трудно создавать, их никогда не сопровождают должным образом, и ошибок в них всегда гораздо больше, чем в основной файловой системе. Кроме того, при компрометации злоумышленник сможет воспользоваться специально подготовленной файловой системой. К сожалению, многие администраторы путают «запустить от имени root» и «работать от имени root», из-за чего меняют UID ещё до запуска haproxy и тем самым ослабляют действующие ограничения безопасности.

Как удалить ключи

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Установите etcd и etcdctl

Добавление или удаление ключей

del для удаления указанного ключа или диапазона ключей:

etcdctl del $KEY [$END_KEY]

Параметры

--prefix[=false]: delete keys with matching prefix
--prev-kv[=false]: return deleted key-value pairs
--from-key[=false]: delete keys that are greater than or equal to the given key using byte compare
--range[=false]: delete range of keys without delay

Параметры, унаследованные от родительских команд

--endpoints="127.0.0.1:2379": gRPC endpoints

Примеры

etcdctl --endpoints=$ENDPOINTS put key myvalue
etcdctl --endpoints=$ENDPOINTS del key

etcdctl --endpoints=$ENDPOINTS put k1 value1
etcdctl --endpoints=$ENDPOINTS put k2 value2
etcdctl --endpoints=$ENDPOINTS del k --prefix

Как выполнить несколько записей в транзакции

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные условия

Установите etcd и etcdctl .
Работающий кластер etcd.

Терминология

Ниже определены ключевые термины, используемые в примере .

Термин	Определение
etcdctl	Инструмент командной строки для взаимодействия с сервером etcd.
Команда `txn`	Название команды `txn` сокращает слово «transaction». Она читает несколько запросов etcd из стандартного ввода и применяет их как одну атомарную транзакцию. Транзакция состоит из списка условий, списка запросов, выполняемых при истинности всех условий, и списка запросов, выполняемых при ложности любого условия. Дополнительные сведения приведены в разделе команд etcdctl для ключей и значений .
`compare`	Секция `compare` в транзакции (`txn`) выполняет условную проверку и определяет, следует ли выполнять операции транзакции. Изменения применяются только тогда, когда текущее состояние хранилища ключей и значений соответствует ожидаемым условиям. Это сохраняет согласованность данных и предотвращает конфликты при параллельной работе. Структура команды показана ниже в разделе Выполнение транзакции .

Транзакции

Команда txn обрабатывает все запросы в одной транзакции:

Как наблюдать за ключами

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Установите etcd и etcdctl

Наблюдение за ключами

watch для получения уведомлений о будущих изменениях:

etcdctl watch $KEY [$END_KEY]

Параметры

-i, --interactive[=false]: interactive mode
--prefix[=false]: watch on a prefix if prefix is set
--rev=0: Revision to start watching
--prev-kv[=false]: get the previous key-value pair before the event happens
--progress-notify[=false]: get periodic watch progress notification from server

Параметры, унаследованные от родительских команд

--endpoints="127.0.0.1:2379": gRPC endpoints

Примеры

etcdctl --endpoints=$ENDPOINTS watch stock1
etcdctl --endpoints=$ENDPOINTS put stock1 1000

etcdctl --endpoints=$ENDPOINTS watch stock --prefix
etcdctl --endpoints=$ENDPOINTS put stock1 10
etcdctl --endpoints=$ENDPOINTS put stock2 20

Как создать аренду

Mon, 01 Jan 0001 00:00:00 +0000

lease записывать с TTL:

etcdctl --endpoints=$ENDPOINTS lease grant 300
# lease 2be7547fbc6a5afa granted with TTL(300s)

etcdctl --endpoints=$ENDPOINTS put sample value --lease=2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS get sample

etcdctl --endpoints=$ENDPOINTS lease keep-alive 2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS lease revoke 2be7547fbc6a5afa
# or after 300 seconds
etcdctl --endpoints=$ENDPOINTS get sample

Как создавать блокировки

Mon, 01 Jan 0001 00:00:00 +0000

LOCK приобретает распределённый мьютекс с указанным именем. Как только блокировка будет получена, она будет удерживаться до завершения работы etcdctl.

Предварительные требования

Установите etcd и etcdctl

Создание блокировки

lock для распределённой блокировки:

etcdctl --endpoints=$ENDPOINTS lock mutex1

Параметры

endpoints — определяет список адресов машин в кластере, разделённых запятыми.
ttl — время ожидания в секундах сессии блокировки.

Быстрый старт

Mon, 01 Jan 0001 00:00:00 +0000

Следуйте этим инструкциям, чтобы локально установить, запустить и проверить кластер etcd из одного участника:

Установите etcd из готовых бинарных файлов или исходного кода. Подробности см. в разделе [Установка][].

Предупреждение

Важно: обязательно выполните последний шаг инструкции по установке и убедитесь, что etcd доступен в пути поиска.
Запустите etcd:
```
$ etcd
{"level":"info","ts":"2021-09-17T09:19:32.783-0400","caller":"etcdmain/etcd.go:72","msg":... }
⋮
```
Примечание

Примечание: вывод etcd представляет собой журналы — сообщения уровня info можно игнорировать.

Как проводить выборы лидера в кластере etcd

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Убедитесь, что установлен etcd и etcdctl .
Проверьте наличие активного кластера etcd.

Проведение выборов лидера

Команда etcdctl используется для проведения выборов лидера в кластере etcd. Она гарантирует, что в один момент времени только один клиент может стать лидером.

etcdctl --endpoints=$ENDPOINTS elect <election-name> [proposal]

etcdctl --endpoints=$ENDPOINTS elect election-name p1

Параметры

--endpoints : $ENDPOINTS

Адрес каждого участника кластера etcd.

Как проверить состояние кластера

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные условия

Установите etcd и etcdctl

Проверка общего состояния

Команда endpoint status проверяет общее состояние каждой конечной точки, указанной флагом --endpoints:

etcdctl endpoint status (--endpoints=$ENDPOINTS|--cluster)

Параметры

--cluster[=false]: use all endpoints from the cluster member list

Проверка работоспособности

Команда endpoint health проверяет работоспособность каждой конечной точки, указанной флагом --endpoints:

Демонстрация

Mon, 01 Jan 0001 00:00:00 +0000

В этом ряду примеров показаны базовые процедуры работы с кластером etcd.

Аутентификация

auth,user,role для аутентификации:

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Как сохранить базу данных

Mon, 01 Jan 0001 00:00:00 +0000

Предварительные требования

Сделать снимок базы данных

snapshot для создания снимка базы данных etcd в определённый момент времени:

etcdctl --endpoints=$ENDPOINT snapshot save DB_NAME

Глобальные параметры

etcdctl

--endpoints=[127.0.0.1:2379], gRPC endpoints

Снимок можно запрашивать только у одного узла etcd, поэтому флаг --endpoints должен содержать только одну конечную точку.

Установка

Mon, 01 Jan 0001 00:00:00 +0000

Требования

Перед установкой etcd ознакомьтесь со следующими страницами:

Установка готовых бинарных файлов

Проще всего установить etcd из готовых бинарных файлов:

Загрузите с Releases сжатый архив для своей платформы, выбрав выпуск v3.7.0 или новее.
Распакуйте архив. В результате появится каталог с бинарными файлами.
Добавьте исполняемые файлы в путь поиска. Например, переименуйте и/или переместите их в каталог из пути поиска, такой как /usr/local/bin, либо добавьте в путь каталог, созданный на предыдущем шаге.

Функциональные шлюзы

Mon, 01 Jan 0001 00:00:00 +0000

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

Описание стадий возможностей приведено в разделе стадий возможностей .

Обзор

Функциональные шлюзы — набор пар key=value, описывающих возможности etcd. Возможности включаются и отключаются флагом командной строки --feature-gates процесса etcd.

etcd позволяет включить или отключить набор функциональных шлюзов. Полный список можно увидеть с помощью флага -h. Чтобы задать шлюзы, присвойте флагу --feature-gates список пар возможностей в командной строке:

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

Mon, 01 Jan 0001 00:00:00 +0000

Общие вопросы об etcd

Что такое etcd?

etcd — согласованное распределённое хранилище ключей и значений. В основном оно используется как отдельная служба координации в распределённых системах и предназначено для небольших объёмов данных, целиком помещающихся в памяти.

Как произносится etcd?

etcd произносится как /ˈɛtsiːdiː/ и означает «распределённый каталог etc».

Должны ли клиенты отправлять запросы лидеру etcd?

Raft основан на лидере: лидер обрабатывает все клиентские запросы, требующие консенсуса кластера. Однако клиенту не нужно знать, какой узел является лидером. Любой требующий консенсуса запрос, отправленный последователю, автоматически пересылается лидеру. Запросы, не требующие консенсуса (например, сериализуемое чтение), может обработать любой участник кластера.

Библиотеки и инструменты

Mon, 01 Jan 0001 00:00:00 +0000

Обратите внимание: перечисленные ниже сторонние библиотеки и инструменты (размещённые не на https://github.com/etcd-io ) не тестируются и не сопровождаются командой etcd. Перед использованием рекомендуется прочитать и изучить их документацию и исходный код.

Инструменты

etcdctl — клиент командной строки для etcd
etcd-dump — утилита командной строки для выгрузки и восстановления etcd.
etcd-fs — файловая система FUSE для etcd
etcddir — синхронизация etcd с локальным каталогом в реальном времени. Работает в Windows и Linux.
etcd-browser — веб-редактор ключей и значений etcd на AngularJS
etcd-lock — реализация выборов главного узла и распределённой блокировки чтения/записи на основе etcd; поддерживает v2
etcd-console — веб-редактор ключей и значений etcd на PHP
etcd-viewer — редактор и средство просмотра хранилища ключей и значений etcd, написанное на Java
etcdtool — экспорт, импорт и редактирование каталога etcd в JSON/YAML/TOML, а также проверка каталога по схеме JSON
etcdloadtest — клиент командной строки для нагрузочного тестирования etcd версии 3.0 и выше.
etcd-tui — современный терминальный пользовательский интерфейс (TUI) для работы с базой данных etcd. Позволяет переходить по ключам, просматривать значения, фильтровать данные и управлять кластером etcd непосредственно из терминала.
etcdfinder — сверхбыстрый современный веб-интерфейс etcd с мгновенным поиском. Поддерживает etcd v2 и v3.
lucas — веб-средство просмотра ключей и значений для кластера kubernetes etcd3.0+.
etcd-manager — современный, эффективный, многоплатформенный и бесплатный графический интерфейс и клиентский инструмент etcd 3.x. Доступен для Windows, Linux и Mac.
etcd-backup-restore — утилита для периодического инкрементного резервного копирования и восстановления etcd.
etcd-druid — оператор Kubernetes для развёртывания кластеров etcd и управления эксплуатационными операциями 2-го дня.
etcdadm — инструмент командной строки для эксплуатации кластера etcd.
etcd-defrag — более удобный и интеллектуальный инструмент дефрагментации etcd.
etcdhelper — плагин платформы intellij для etcd.

Библиотеки

В следующих разделах клиентские библиотеки etcd перечислены по языкам.

Как добавлять и удалять участников

Mon, 01 Jan 0001 00:00:00 +0000

Команда member добавляет, удаляет и обновляет участников:

# For each machine
TOKEN=my-etcd-token-1
CLUSTER_STATE=new
NAME_1=etcd-node-1
NAME_2=etcd-node-2
NAME_3=etcd-node-3
HOST_1=10.240.0.13
HOST_2=10.240.0.14
HOST_3=10.240.0.15
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

# For node 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

Затем замените участника командами member remove и member add:

Сообщение об ошибках

Mon, 01 Jan 0001 00:00:00 +0000

Если в какой-либо части проекта etcd обнаружена ошибка или неточность в документации, сообщите нам, создав issue . Мы очень серьёзно относимся к ошибкам и считаем, что незначительных проблем не бывает. Перед созданием отчёта убедитесь, что issue с описанием той же проблемы ещё не существует.

Чтобы отчёт был точным и понятным, постарайтесь соблюдать следующие требования:

Конкретность. Укажите как можно больше подробностей: версию, окружение, конфигурацию и другие существенные сведения. Если ошибка связана с работой сервера etcd, приложите журнал etcd; особенно важны начальные сообщения с конфигурацией etcd.

Настройка производительности

Mon, 01 Jan 0001 00:00:00 +0000

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

Сеть — не единственный источник задержки. На каждый запрос и ответ могут влиять медленные диски лидера и последователя. Каждый из этих тайм-аутов охватывает полное время от отправки запроса до успешного ответа другой машины.

Временные параметры

Базовый протокол распределённого консенсуса использует два независимых временных параметра, чтобы узлы могли передать лидерство при зависании или отключении лидера. Первый параметр — интервал heartbeat. Он определяет, как часто лидер сообщает последователям, что по-прежнему остаётся лидером. Рекомендуется устанавливать его примерно равным времени кругового обхода между участниками. По умолчанию etcd использует интервал heartbeat 100ms.

Протокол службы обнаружения

Mon, 01 Jan 0001 00:00:00 +0000

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

Протокол используется только при начальной инициализации и не подходит для реконфигурации во время выполнения или мониторинга кластера.

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

Протокол службы обнаружения

Mon, 01 Jan 0001 00:00:00 +0000

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

Протокол используется только во время начальной инициализации и не подходит для реконфигурации во время выполнения или мониторинга кластера.

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

Соглашения по ведению журнала

Mon, 01 Jan 0001 00:00:00 +0000

etcd использует библиотеку zap для ведения журнала вывода приложения, категоризированного по уровням. Уровень сообщения в журнале определяется в соответствии со следующими соглашениями:

Логи DebugLevel обычно объёмные и обычно отключены в рабочей среде.
- Примеры:
  - Отправка обычного сообщения удалённому узлу
  - Запись записи журнала на диск
Уровень InfoLevel является уровнем ведения журнала по умолчанию.
- Примеры:
  - Конфигурация при запуске
  - Начало создания снимка
  - Добавление нового узла в кластер
  - Добавление нового пользователя в подсистему аутентификации
Журналы уровня Warn более важны, чем Info, но не требуют индивидуального человеческого контроля.

Модули Golang

Mon, 01 Jan 0001 00:00:00 +0000

Начиная с версии 3.5 проект etcd организован как несколько модулей Golang , размещённых в одном репозитории .

Проект включает следующие модули:

go.etcd.io/etcd/api/v3 — определения API, например protos и созданные из proto библиотеки, которые задают протокол взаимодействия между клиентами и сервером etcd.
go.etcd.io/etcd/pkg/v3 — набор вспомогательных пакетов, используемых etcd, но не зависящих от его специфики. Пакет следует размещать здесь только в том случае, если в будущем его можно будет вынести в отдельный репозиторий. Не добавляйте сюда код с большим числом собственных зависимостей: они автоматически станут зависимостями клиентской библиотеки, которую важно сохранять легковесной.

Модель данных

Mon, 01 Jan 0001 00:00:00 +0000

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

etcd хранит данные в многоверсионном постоянном хранилище ключей и значений. Когда значение пары заменяется новыми данными, постоянное хранилище сохраняет её предыдущую версию. Фактически хранилище неизменяемо: операции не обновляют структуру на месте, а всегда создают новую обновлённую структуру. После изменения все прежние версии ключей остаются доступными для чтения и наблюдения. Чтобы хранилище не росло бесконечно и не сохраняло старые версии, его можно компактизировать, удалив самые старые версии замещённых данных.

Конструкция клиента etcd

Mon, 01 Jan 0001 00:00:00 +0000

Конструкция клиента etcd

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Введение

Сервер etcd доказал свою надёжность многолетним тестированием с внедрением отказов. Большая часть сложной логики приложений уже обрабатывается сервером etcd и его хранилищами данных (например, состав кластера прозрачен для клиентов, а уровень Raft пересылает предложения лидеру). Хотя серверные компоненты корректны, их взаимодействие с клиентом требует иного набора сложных протоколов, обеспечивающих корректность и высокую доступность в условиях отказов. В идеале сервер etcd представляет множество физических машин как единый логический кластер, а клиент реализует автоматическое переключение между репликами при отказе. В этом документе описаны архитектурные решения клиента и подробности их реализации.

Конструкция обучающегося участника etcd

Mon, 01 Jan 0001 00:00:00 +0000

Обучающийся участник etcd

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Предпосылки

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

1. Новый участник кластера перегружает лидера

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

Конструкция аутентификации etcd v3

Mon, 01 Jan 0001 00:00:00 +0000

Почему не используется система аутентификации v2?

Вместо RESTful-интерфейса, как в v2, протокол v3 использует gRPC в качестве транспорта. Новый протокол даёт возможность развить и улучшить конструкцию v2. Например, аутентификация v3 выполняется для соединения, а не для каждого запроса, как более медленная аутентификация v2. Кроме того, на практике семантика аутентификации v2 неудобна для рассуждений о согласованности, что будет описано в следующих разделах. Для v3 существует чёткое описание и реализация механизма аутентификации, устраняющие недостатки системы v2.

API etcd

Mon, 01 Jan 0001 00:00:00 +0000

Этот документ содержит обзор основной конструкции API etcd v3. Не следует путать его с API etcd v2, объявленным устаревшим в etcd v3.5. Документ не претендует на полноту, а сосредоточен на основных идеях, необходимых для понимания etcd, без отвлечения на менее распространённые вызовы API. Все API etcd определены в службах gRPC , которые группируют удалённые вызовы процедур (RPC), распознаваемые сервером etcd. Полный перечень RPC etcd приведён в формате Markdown в справочнике API gRPC .

Файлы постоянного хранилища etcd

Mon, 01 Jan 0001 00:00:00 +0000

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

Предварительные сведения

Для понимания документа полезны следующие вводные материалы:

обзор модели данных etcd
обзор Raft (особенно раздел “5.3 Log replication”).

Обзор

Долгоживущие файлы

Имя файла Высокоуровневое назначение

./member/snap/db

b+tree bbolt, хранящее все применённые данные, сведения об авторизации состава кластера и метаданные. Оно знает последний применённый индекс журнала WAL ("consistent_index").

./member/snap/0000000000000002-0000000000049425.snap
./member/snap/0000000000000002-0000000000061ace.snap

Периодические снимки устаревшего хранилища v2, содержащие:

основные сведения о составе кластера
версию etcd

Гарантии API etcd

Mon, 01 Jan 0001 00:00:00 +0000

etcd — согласованное и долговечное хранилище ключей и значений. Доступ к нему предоставляют службы gRPC . etcd обеспечивает наиболее строгие гарантии согласованности и долговечности для распределённой системы. В этой спецификации перечислены гарантии API etcd.

Рассматриваемые API

KV APIs
- Range
- RangeStream
- Put
- Delete
- Transaction
API наблюдения
- Watch
API аренды
- Grant
- [Отзыв][Revoke]
- Keep alive

API KV позволяет напрямую читать и изменять хранилище ключей и значений. API наблюдения позволяет подписываться на изменения хранилища. API аренды позволяет назначать ключу время существования.

etcd в сравнении с другими хранилищами ключей и значений

Mon, 01 Jan 0001 00:00:00 +0000

Название «etcd» образовано из двух идей: каталога Unix «/etc» и распределённых («d»istributed) систем. В «/etc» хранятся данные конфигурации одной системы, тогда как etcd хранит конфигурацию крупных распределённых систем. Поэтому распределённый («d»istributed) «/etc» называется «etcd».

etcd задуман как универсальная основа крупных распределённых систем. Такие системы не допускают split-brain и готовы ради этого пожертвовать доступностью. etcd хранит метаданные согласованно и отказоустойчиво. Кластер etcd предоставляет хранилище ключей и значений с высокой стабильностью, надёжностью, масштабируемостью и производительностью.

Глоссарий

Mon, 01 Jan 0001 00:00:00 +0000

Этот документ определяет различные термины, используемые в документации, командной строке и исходном коде etcd.

Аварийный сигнал

Сервер etcd подаёт аварийный сигнал, когда для сохранения надёжности кластера требуется вмешательство оператора.

Аутентификация

Аутентификация управляет правами доступа пользователей к ресурсам etcd.

Клиент

Клиент подключается к кластеру etcd и отправляет служебные запросы: получает пары «ключ — значение», записывает данные или наблюдает за обновлениями.

Настройка локального кластера

Mon, 01 Jan 0001 00:00:00 +0000

Для тестирования и разработки быстрее и проще всего настроить локальный кластер. Промышленное развёртывание описано в разделе кластеризации .

Локальный автономный кластер

Запуск кластера

Чтобы развернуть автономный кластер etcd, выполните:

$ ./etcd
...

Если бинарный файл etcd отсутствует в текущем рабочем каталоге, он может находиться в $GOPATH/bin/etcd или /usr/local/bin/etcd. Укажите правильный путь при запуске.

Работающий участник etcd принимает клиентские запросы на localhost:2379.

Интеракция с etcd

Mon, 01 Jan 0001 00:00:00 +0000

Пользователи чаще всего взаимодействуют с etcd, устанавливая или получая значение ключа. В этом разделе описано, как это сделать с помощью etcdctl — командной строки для взаимодействия с сервером etcd. Концепции, описанные здесь, должны применимы к gRPC–API или API клиентской библиотеки.

Версию API 2 или 3, которую etcdctl использует для связи с etcd, задаёт переменная окружения ETCDCTL_API. По умолчанию etcdctl из master (3.4) использует API v3, а версии 3.3 и старше — API v2.

Зачем нужен шлюз gRPC

Mon, 01 Jan 0001 00:00:00 +0000

etcd v3 использует gRPC как протокол обмена сообщениями. Проект etcd включает основанный на gRPC клиент Go и утилиту командной строки etcdctl для взаимодействия с кластером etcd через gRPC. Для языков без поддержки gRPC etcd предоставляет JSON-шлюз gRPC . Он служит RESTful-прокси, преобразующим запросы HTTP/JSON в сообщения gRPC.

Использование шлюза gRPC

Шлюз принимает JSON-сопоставление определений сообщений protocol buffer etcd. Поля key и value определены как массивы байтов, поэтому в JSON их обязательно кодировать в base64. В следующих примерах используется curl, но подойдёт любой клиент HTTP/JSON.

Именование и обнаружение gRPC

Mon, 01 Jan 0001 00:00:00 +0000

etcd предоставляет резолвер gRPC для альтернативной системы имён, которая получает конечные точки из etcd при обнаружении служб gRPC. Механизм основан на наблюдении за обновлениями ключей с префиксом имени службы.

Эта возможность является экспериментальной, поскольку зависит от пакета google.golang.org/grpc/resolver , который всё ещё считается экспериментальным в grpc-go.

Использование обнаружения etcd с go-grpc

Клиент etcd предоставляет резолвер gRPC для разрешения конечных точек gRPC с бэкендом etcd. Резолвер инициализируется клиентом etcd:

Встраивание etcd в Go-приложение

Mon, 01 Jan 0001 00:00:00 +0000

Пакет go etcd embed предоставляет простой способ встраивания сервера etcd непосредственно в ваше приложение.

Дополнительные сведения см. в документации пакета embed .

Ограничения системы

Mon, 01 Jan 0001 00:00:00 +0000

Ограничение размера запроса

etcd разработан для обработки небольших пар ключ-значение, характерных для метаданных. Более крупные запросы будут работать, но могут увеличить задержку других запросов. По умолчанию максимальный размер любого запроса составляет 1.5 MiB. Этот лимит можно настроить с помощью флага --max-request-bytes для сервера etcd.

Ограничение размера хранилища

По умолчанию ограничение размера хранилища составляет 2 GiB, настраивается с помощью флага --quota-backend-bytes. 8 GiB — рекомендуемый максимальный размер для обычных сред, etcd выдает предупреждение при запуске, если сконфигурированное значение превышает его.

Возможности etcd

Mon, 01 Jan 0001 00:00:00 +0000

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

Возможности etcd проходят три стадии: экспериментальную, стабильную и небезопасную. Получить их список можно командой etcd --help.

Экспериментальные

Чтобы получить обратную связь на раннем этапе, новые возможности обычно добавляются как экспериментальные. Их можно определить по имени флага с префиксом --experimental. При использовании экспериментальной возможности учитывайте следующее:

Справочник API

Mon, 01 Jan 0001 00:00:00 +0000

Этот справочник API автоматически создан из указанных файлов .proto.

Служба `Auth` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
AuthEnable	AuthEnableRequest	AuthEnableResponse	AuthEnable включает аутентификацию.
AuthDisable	AuthDisableRequest	AuthDisableResponse	AuthDisable отключает аутентификацию.
AuthStatus	AuthStatusRequest	AuthStatusResponse	AuthStatus отображает состояние аутентификации.
Authenticate	AuthenticateRequest	AuthenticateResponse	Authenticate обрабатывает запрос аутентификации.
UserAdd	AuthUserAddRequest	AuthUserAddResponse	UserAdd добавляет нового пользователя. Имя пользователя не может быть пустым.
UserGet	AuthUserGetRequest	AuthUserGetResponse	UserGet получает подробные сведения о пользователе.
UserList	AuthUserListRequest	AuthUserListResponse	UserList получает список всех пользователей.
UserDelete	AuthUserDeleteRequest	AuthUserDeleteResponse	UserDelete удаляет указанного пользователя.
UserChangePassword	AuthUserChangePasswordRequest	AuthUserChangePasswordResponse	UserChangePassword изменяет пароль указанного пользователя.
UserGrantRole	AuthUserGrantRoleRequest	AuthUserGrantRoleResponse	UserGrant предоставляет указанному пользователю роль.
UserRevokeRole	AuthUserRevokeRoleRequest	AuthUserRevokeRoleResponse	UserRevokeRole отзывает роль указанного пользователя.
RoleAdd	AuthRoleAddRequest	AuthRoleAddResponse	RoleAdd добавляет новую роль. Имя роли не может быть пустым.
RoleGet	AuthRoleGetRequest	AuthRoleGetResponse	RoleGet получает подробные сведения о роли.
RoleList	AuthRoleListRequest	AuthRoleListResponse	RoleList получает список всех ролей.
RoleDelete	AuthRoleDeleteRequest	AuthRoleDeleteResponse	RoleDelete удаляет указанную роль.
RoleGrantPermission	AuthRoleGrantPermissionRequest	AuthRoleGrantPermissionResponse	RoleGrantPermission предоставляет указанной роли разрешение на заданный ключ или диапазон.
RoleRevokePermission	AuthRoleRevokePermissionRequest	AuthRoleRevokePermissionResponse	RoleRevokePermission отзывает у указанной роли разрешение на ключ или диапазон.

Служба `Cluster` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
MemberAdd	MemberAddRequest	MemberAddResponse	MemberAdd добавляет участника в кластер.
MemberRemove	MemberRemoveRequest	MemberRemoveResponse	MemberRemove удаляет существующего участника из кластера.
MemberUpdate	MemberUpdateRequest	MemberUpdateResponse	MemberUpdate обновляет конфигурацию участника.
MemberList	MemberListRequest	MemberListResponse	MemberList перечисляет всех участников кластера.
MemberPromote	MemberPromoteRequest	MemberPromoteResponse	MemberPromote повышает обучающегося участника raft без права голоса до участника raft с правом голоса.

Служба `KV` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
Range	RangeRequest	RangeResponse	Range получает ключи диапазона из хранилища ключей и значений.
Put	PutRequest	PutResponse	Put помещает заданный ключ в хранилище ключей и значений. Запрос put увеличивает ревизию хранилища и создаёт одно событие в истории событий.
DeleteRange	DeleteRangeRequest	DeleteRangeResponse	DeleteRange удаляет заданный диапазон из хранилища ключей и значений. Запрос удаления увеличивает ревизию хранилища и создаёт событие удаления в истории для каждого удалённого ключа.
Txn	TxnRequest	TxnResponse	Txn обрабатывает несколько запросов в одной транзакции. Запрос txn увеличивает ревизию хранилища ключей и значений и создаёт события с одной ревизией для каждого выполненного запроса. Многократное изменение одного ключа в одной txn недопустимо.
Compact	CompactionRequest	CompactionResponse	Compact компактизирует историю событий в хранилище ключей и значений etcd. Хранилище следует периодически компактизировать, иначе история событий будет расти бесконечно.

Служба `Lease` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
LeaseGrant	LeaseGrantRequest	LeaseGrantResponse	LeaseGrant создаёт аренду, которая истекает, если сервер не получает keepAlive в течение заданного срока жизни. При истечении аренды все присоединённые к ней ключи истекают и удаляются. Каждый истёкший ключ создаёт событие удаления в истории событий.
LeaseRevoke	LeaseRevokeRequest	LeaseRevokeResponse	LeaseRevoke отзывает аренду. Все присоединённые к ней ключи истекают и удаляются.
LeaseKeepAlive	LeaseKeepAliveRequest	LeaseKeepAliveResponse	LeaseKeepAlive поддерживает аренду активной, передавая потоком запросы поддержания активности от клиента серверу и ответы от сервера клиенту.
LeaseTimeToLive	LeaseTimeToLiveRequest	LeaseTimeToLiveResponse	LeaseTimeToLive получает сведения об аренде.
LeaseLeases	LeaseLeasesRequest	LeaseLeasesResponse	LeaseLeases перечисляет все существующие аренды.

Служба `Maintenance` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
Alarm	AlarmRequest	AlarmResponse	Alarm активирует, деактивирует и запрашивает аварийные сигналы о состоянии кластера.
Status	StatusRequest	StatusResponse	Status получает состояние участника.
Defragment	DefragmentRequest	DefragmentResponse	Defragment дефрагментирует базу данных бэкенда участника для освобождения места.
Hash	HashRequest	HashResponse	Hash вычисляет хеш всего пространства ключей бэкенда, включая сегменты key, lease и другие сегменты хранилища. Предназначено ТОЛЬКО для тестирования! Не полагайтесь на операцию в рабочей среде с текущими транзакциями, поскольку Hash не удерживает блокировки MVCC. Для проверки согласованности сегмента “key” используйте API “HashKV”.
HashKV	HashKVRequest	HashKVResponse	HashKV вычисляет хеш всех ключей MVCC до заданной ревизии. Перебирает только сегмент “key” в хранилище бэкенда.
Snapshot	SnapshotRequest	SnapshotResponse	Snapshot передаёт снимок всего бэкенда от участника клиенту потоком.
MoveLeader	MoveLeaderRequest	MoveLeaderResponse	MoveLeader запрашивает у текущего узла-лидера передачу лидерства назначенному узлу.
Downgrade	DowngradeRequest	DowngradeResponse	Downgrade запрашивает понижение версии, проверяет его допустимость или отменяет его для версии кластера. Поддерживается начиная с etcd 3.5.

Служба `Watch` (api/etcdserverpb/rpc.proto)

Метод	Тип запроса	Тип ответа	Описание
Watch	WatchRequest	WatchResponse	Watch наблюдает за происходящими или уже произошедшими событиями. Ввод и вывод являются потоками: входной поток создаёт и отменяет наблюдателей, выходной отправляет события. Один RPC watch может наблюдать несколько диапазонов ключей и одновременно передавать события нескольких наблюдений. Всю историю событий можно наблюдать с последней ревизии компактизации.

Сообщение `AlarmMember` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
memberID	memberID — идентификатор участника, связанного с активированным аварийным сигналом.	uint64
alarm	alarm — тип активированного аварийного сигнала.	AlarmType

Сообщение `AlarmRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
action	action — тип отправляемого запроса аварийного сигнала. Действие может GET состояния сигналов, ACTIVATE сигнал или DEACTIVATE активированный сигнал.	AlarmAction
memberID	memberID — идентификатор участника, связанного с сигналом. Если memberID равен 0, запрос относится ко всем участникам.	uint64
alarm	alarm — тип аварийного сигнала, рассматриваемого запросом.	AlarmType

Сообщение `AlarmResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
alarms	alarms — список аварийных сигналов, связанных с запросом.	(slice of) AlarmMember

Сообщение `AuthDisableRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option

Сообщение `AuthDisableResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthEnableRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option

Сообщение `AuthEnableResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthRoleAddRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name	name — имя роли, добавляемой в систему аутентификации.	string

Сообщение `AuthRoleAddResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthRoleDeleteRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
role		string

Сообщение `AuthRoleDeleteResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthRoleGetRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
role		string

Сообщение `AuthRoleGetResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
header		ResponseHeader
perm		(slice of) authpb.Permission

Сообщение `AuthRoleGrantPermissionRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name	name — имя роли, которой будет предоставлено разрешение.	string
perm	perm — разрешение, предоставляемое роли.	authpb.Permission

Сообщение `AuthRoleGrantPermissionResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthRoleListRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option

Сообщение `AuthRoleListResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
roles		(slice of) string

Сообщение `AuthRoleRevokePermissionRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
role		string
key		bytes
range_end		bytes

Сообщение `AuthRoleRevokePermissionResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthStatusRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option

Сообщение `AuthStatusResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
enabled		bool
authRevision	authRevision — текущая ревизия хранилища аутентификации	uint64

Сообщение `AuthUserAddRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name		string
password		string
options		authpb.UserAddOptions
hashedPassword		string

Сообщение `AuthUserAddResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthUserChangePasswordRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name	name — имя пользователя, пароль которого изменяется.	string
password	password — новый пароль пользователя. Обратите внимание: это поле будет удалено на уровне API.	string
hashedPassword	hashedPassword — новый пароль пользователя. Обратите внимание: это поле будет инициализировано на уровне API.	string

Сообщение `AuthUserChangePasswordResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthUserDeleteRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name	name — имя удаляемого пользователя.	string

Сообщение `AuthUserDeleteResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthUserGetRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name		string

Сообщение `AuthUserGetResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
roles		(slice of) string

Сообщение `AuthUserGrantRoleRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
user	user — имя пользователя, которому следует предоставить указанную роль.	string
role	role — имя роли, предоставляемой пользователю.	string

Сообщение `AuthUserGrantRoleResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthUserListRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option

Сообщение `AuthUserListResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
users		(slice of) string

Сообщение `AuthUserRevokeRoleRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name		string
role		string

Сообщение `AuthUserRevokeRoleResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader

Сообщение `AuthenticateRequest` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
name		string
password		string

Сообщение `AuthenticateResponse` (api/etcdserverpb/rpc.proto)

Поле	Описание	Тип
(versionpb.etcd_version_msg)		option
header		ResponseHeader
token	token — авторизованный токен, который можно использовать в последующих RPC	string

Сообщение `CompactionRequest` (api/etcdserverpb/rpc.proto)

CompactionRequest компактизирует хранилище ключей и значений до заданной ревизии. Все замещённые ключи с ревизией меньше ревизии компактизации удаляются.

Справочник API: конкурентность

Mon, 01 Jan 0001 00:00:00 +0000

Этот справочник API автоматически создан из указанных файлов .proto.

служба `Lock` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Служба блокировок предоставляет клиентские средства блокировки через интерфейс gRPC.

Метод	Тип запроса	Тип ответа	Описание
Lock	LockRequest	LockResponse	Lock получает распределённую совместную блокировку с указанным именем. При успехе возвращается уникальный ключ, существующий, пока вызывающая сторона удерживает блокировку. Вместе с транзакциями ключ позволяет безопасно гарантировать, что etcd обновляется только при владении блокировкой. Блокировка удерживается до вызова Unlock для ключа или истечения аренды владельца.
Unlock	UnlockRequest	UnlockResponse	Unlock принимает ключ, возвращённый Lock, и освобождает блокировку. Следующий ожидающий вызов Lock пробуждается и получает владение блокировкой.

сообщение `LockRequest` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Поле	Описание	Тип
name	name — идентификатор получаемой распределённой совместной блокировки.	bytes
lease	lease — идентификатор аренды, привязанной к владению блокировкой. Если удерживающая блокировку аренда истекает или отзывается, блокировка освобождается автоматически. Вызовы Lock с одной арендой считаются одним получением; повторная блокировка с той же арендой ничего не делает.	int64

сообщение `LockResponse` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Поле	Описание	Тип
header		etcdserverpb.ResponseHeader
key	key — ключ, существующий в etcd, пока вызывающая Lock сторона владеет блокировкой. Пользователи не должны изменять ключ, иначе поведение блокировки не определено.	bytes

сообщение `UnlockRequest` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Поле	Описание	Тип
key	key — ключ владения блокировкой, выданный Lock.	bytes

сообщение `UnlockResponse` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Поле	Описание	Тип
header		etcdserverpb.ResponseHeader

служба `Election` (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Служба выборов предоставляет клиентские средства выборов через интерфейс gRPC.

Аутентификация

Mon, 01 Jan 0001 00:00:00 +0000

auth,user,role для аутентификации:

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Примечание:

Это всего лишь заглушка, которую необходимо заполнить и обновить, добавив больше информации об аутентификации. Текст выше — всего лишь пример кода.

Параметры конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

etcd можно настроить следующими способами:

Флаги командной строки
Переменные окружения: каждому флагу соответствует переменная окружения с тем же именем, префиксом ETCD_, прописными буквами и форматом snake case . Например, --some-flag соответствует ETCD_SOME_FLAG.
Файл конфигурации

Предупреждение

Внимание: при сочетании разных способов конфигурации действуют следующие правила.

Флаги командной строки имеют приоритет над переменными окружения.
Если указан файл конфигурации, все флаги командной строки и переменные окружения игнорируются.

Флаги командной строки

Ниже флаги представлены в формате --flag-name DEFAULT_VALUE.

Управление доступом на основе ролей

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

Аутентификация появилась в etcd 2.1. В API etcd v3 интерфейс API и пользовательский интерфейс аутентификации немного изменены для соответствия новой модели данных. Это руководство поможет настроить базовую аутентификацию и управление доступом на основе ролей в etcd v3.

Специальные пользователи и роли

Существует один специальный пользователь root и одна специальная роль root.

Пользователь `root`

Пользователя root с полным доступом к etcd необходимо создать до включения аутентификации. Он предназначен для административных задач: управления ролями и обычными пользователями. Пользователь root должен иметь роль root и может изменять любые данные в etcd.

Модель транспортной безопасности

Mon, 01 Jan 0001 00:00:00 +0000

etcd поддерживает автоматический TLS и аутентификацию по клиентским сертификатам как для связи клиентов с сервером, так и для связи одноранговых узлов (серверов друг с другом внутри кластера). Обратите внимание: по умолчанию etcd не включает аутентификацию на основе RBAC и аутентификацию на транспортном уровне, чтобы упростить начало работы с базой данных. Кроме того, изменение этого значения по умолчанию нарушило бы совместимость проекта, установленную с 2013 года. Кластер etcd без включённых функций безопасности может открыть свои данные любым клиентам.

Руководство по кластеризации

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

При статическом запуске кластера etcd каждый участник должен знать других участников кластера. В некоторых случаях IP-адреса участников заранее неизвестны. Тогда кластер etcd можно инициализировать с помощью службы обнаружения.

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

В руководстве рассматриваются следующие механизмы начальной инициализации кластера etcd:

Статическая инициализация
Обнаружение etcd
Обнаружение DNS

Каждый механизм будет использован для создания кластера etcd из трёх машин со следующими параметрами:

Запуск кластеров etcd в контейнерах

Mon, 01 Jan 0001 00:00:00 +0000

В этом руководстве показано, как запустить etcd в Docker с помощью процесса статической начальной инициализации .

Docker

Чтобы предоставить клиентам вне узла Docker доступ к API etcd, используйте IP-адрес узла контейнера. Способ получения IP-адреса подробно описан в документации docker inspect . Также можно передать команде docker run флаг --net=host, чтобы не помещать контейнер в отдельный сетевой стек.

Запуск одного узла etcd

При настройке etcd используйте IP-адрес узла:

Запуск кластеров etcd как StatefulSet Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ниже показано, как выполнить статическую начальную инициализацию в виде StatefulSet Kubernetes.

Пример манифеста

Этот манифест содержит службу и StatefulSet для развёртывания статического кластера etcd в Kubernetes.

Если скопировать содержимое манифеста в файл etcd.yaml, его можно применить к кластеру следующей командой.

$ kubectl apply --filename etcd.yaml

После применения дождитесь готовности подов.

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-0 1/1 Running 0 24m
etcd-1 1/1 Running 0 24m
etcd-2 1/1 Running 0 24m

Используемый в примере контейнер содержит etcdctl, который можно вызывать непосредственно внутри подов.

Режимы отказа

Mon, 01 Jan 0001 00:00:00 +0000

В крупных развёртываниях машин отказы неизбежны. Машина выходит из строя при неисправности оборудования или программного обеспечения. Несколько машин могут отказать одновременно из-за перебоя питания или проблем с сетью. Разные виды отказов также могут происходить одновременно; перечислить все возможные случаи практически невозможно.

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

Восстановление после аварии

Mon, 01 Jan 0001 00:00:00 +0000

etcd рассчитан на отказы машин. Кластер etcd автоматически восстанавливается после временных сбоев, например перезагрузки машины, и допускает до (N-1)/2 постоянных отказов в кластере из N участников. При постоянном отказе из-за неисправности оборудования или повреждения диска участник теряет доступ к кластеру. Если кластер навсегда теряет более (N-1)/2 участников, происходит катастрофический отказ с безвозвратной потерей кворума. Без кворума кластер не может достичь консенсуса и продолжать принимать обновления.

Для восстановления после катастрофического отказа etcd v3 предоставляет средства снимков и восстановления, позволяющие воссоздать кластер без потери данных ключей v3. Восстановление ключей v2 описано в руководстве администратора v2 .

Шлюз etcd

Mon, 01 Jan 0001 00:00:00 +0000

Что такое шлюз etcd

Шлюз etcd — простой TCP-прокси, пересылающий сетевые данные кластеру etcd. Шлюз не хранит состояния и работает прозрачно: он не анализирует клиентские запросы и не вмешивается в ответы кластера. Он не завершает TLS-соединения, не выполняет TLS-рукопожатия от имени клиентов и не проверяет защищённость соединения.

Шлюз поддерживает несколько конечных точек серверов etcd и использует простую циклическую политику. Он направляет трафик только доступным конечным точкам и скрывает от клиентов отказы. В будущем могут появиться другие политики повторных попыток, например взвешенная циклическая.

Прокси gRPC

Mon, 01 Jan 0001 00:00:00 +0000

Прокси gRPC — это не сохраняющий состояние обратный прокси etcd, работающий на уровне gRPC (L7). Он предназначен для снижения общей вычислительной нагрузки на основной кластер etcd. Для горизонтального масштабирования прокси объединяет запросы API наблюдения и аренды. Для защиты кластера от злоупотребляющих клиентов он кэширует запросы диапазонов ключей.

Прокси gRPC поддерживает несколько конечных точек сервера etcd. При запуске прокси случайным образом выбирает одну конечную точку сервера etcd. Она обслуживает все запросы, пока прокси не обнаружит её отказ. Обнаружив отказ конечной точки, прокси gRPC переключается на другую доступную точку, скрывая сбой от клиентов. В будущем могут поддерживаться и другие политики повторных попыток, например взвешенный циклический выбор.

Обслуживание

Mon, 01 Jan 0001 00:00:00 +0000

Обзор

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

Все операции обслуживания etcd управляют ресурсами хранилища, занятыми пространством ключей etcd. Недостаточный контроль его размера предотвращается квотами дискового пространства: если у участника etcd заканчивается место, квота активирует аварийные сигналы для всего кластера и переводит систему в режим обслуживания с ограниченными операциями. Чтобы не исчерпать место для записи в пространство ключей, его историю необходимо компактизировать. Само дисковое пространство можно освободить дефрагментацией участников etcd. Наконец, регулярное резервное копирование состояния участника с помощью снимков позволяет восстановиться после непреднамеренной логической потери или повреждения данных, вызванных ошибкой эксплуатации.

Мониторинг etcd

Mon, 01 Jan 0001 00:00:00 +0000

Каждый сервер etcd предоставляет локальные сведения мониторинга через конечные точки HTTP на клиентском порту. Эти данные полезны для проверки состояния системы и отладки кластера.

Конечная точка отладки

Если задан --log-level=debug, сервер etcd экспортирует отладочные сведения по пути /debug на клиентском порту. Используйте --log-level=debug осторожно: он снижает производительность и включает подробное ведение журнала.

/debug/pprof — стандартная конечная точка профилирования среды выполнения Go. Она позволяет профилировать использование CPU, кучи, мьютексов и goroutine. В примере go tool pprof получает 10 функций, на которые etcd тратит больше всего времени:

Производительность

Mon, 01 Jan 0001 00:00:00 +0000

Понимание производительности

etcd обеспечивает стабильную и устойчиво высокую производительность. Её определяют два фактора: задержка и пропускная способность. Задержка — время выполнения одной операции. Пропускная способность — общее число операций, завершённых за определённый период. Обычно средняя задержка растёт вместе с общей пропускной способностью, когда etcd принимает параллельные клиентские запросы. В типичной облачной среде, например на стандартной машине n-4 в Google Compute Engine (GCE) или сопоставимой машине AWS, кластер etcd из трёх участников при небольшой нагрузке завершает запрос менее чем за одну миллисекунду, а при высокой выполняет более 30,000 запросов в секунду.

Устройство реконфигурации во время выполнения

Mon, 01 Jan 0001 00:00:00 +0000

Реконфигурация во время выполнения — одна из самых сложных и подверженных ошибкам возможностей распределённой системы, особенно основанной на консенсусе системы вроде etcd.

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

Двухфазное изменение конфигурации сохраняет безопасность кластера

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

Динамическое изменение конфигурации

Mon, 01 Jan 0001 00:00:00 +0000

etcd поддерживает поэтапное изменение конфигурации во время работы, позволяя обновлять состав кластера без остановки.

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

Архитектура описана в документе о динамическом изменении конфигурации .

Сценарии реконфигурации

В этом разделе рассмотрены распространённые причины изменения конфигурации. Обычно это сочетания добавления и удаления участников, описанные в разделе Операции изменения конфигурации кластера .

Поддерживаемые платформы

Mon, 01 Jan 0001 00:00:00 +0000

Уровни поддержки

etcd работает на разных платформах, однако предоставляемые гарантии зависят от уровня поддержки платформы:

Уровень 1: полностью поддерживается сопровождающими etcd ; гарантируется прохождение всех тестов, включая функциональные тесты и тесты надёжности.
Уровень 2: гарантируется прохождение интеграционных и сквозных тестов, но не обязательно функциональных тестов или тестов надёжности.
Уровень 3: гарантируется успешная сборка; тестирование может быть минимальным или отсутствовать, поэтому платформу следует считать нестабильной.

Текущая поддержка

В следующей таблице перечислены поддерживаемые платформы и соответствующие уровни поддержки etcd:

Версионирование

Mon, 01 Jan 0001 00:00:00 +0000

Данный документ описывает версии, поддерживаемые проектом etcd.

Версионирование сервиса и поддерживаемые версии

Версии etcd выражаются как x.y.z, где x — мажорная версия, y — минорная версия, а z — версия исправления, в соответствии с терминологией Semantic Versioning .
Новые минорные версии могут добавлять дополнительные функции в API.

Проект etcd поддерживает ветки релизов для текущей версии и предыдущего выпуска. Например, когда v3.5 является текущей версией, поддерживается v3.4. Когда выпускается v3.6, v3.4 прекращает поддержку.

Повреждение данных

Mon, 01 Jan 0001 00:00:00 +0000

В etcd встроено автоматическое обнаружение повреждения данных, предотвращающее расхождение состояния участников.

Включение обнаружения повреждения данных

Повреждение данных можно обнаруживать с помощью:

Начальной проверки, включаемой флагом --experimental-initial-corrupt-check.
Периодической проверки:
- Хеша сжатой ревизии, включаемой флагом --experimental-compact-hash-check-enabled.
- Хеша последней ревизии, включаемой флагом --experimental-corrupt-check-time.

Начальная проверка выполняется при начальной инициализации участника etcd. Участник сравнивает своё постоянное состояние с другими участниками и завершает работу при несовпадении.

Обе периодические проверки выполняются лидером уже работающего кластера. Лидер сравнивает своё постоянное состояние с другими участниками и при несовпадении подаёт аварийный сигнал CORRUPT. Обе проверки решают одну задачу, однако для баланса между производительностью и временем обнаружения стоит включить обе.

Тестирование использования памяти хранилищем

Mon, 01 Jan 0001 00:00:00 +0000

Физическую память потребляют два компонента хранилища etcd. Для ускорения поиска ключей процесс etcd выделяет индекс в памяти. Управляемый операционной системой страничный кеш процесса хранит недавно прочитанные с диска данные для быстрого повторного использования.

Индекс в памяти хранит все ключи в структуре данных B-tree вместе с указателями на данные на диске — значения. Каждый ключ в B-tree может содержать несколько указателей на разные версии значения. Поэтому теоретическое потребление памяти индексом можно приблизительно оценить формулой:

Тестирование использования памяти наблюдателями

Mon, 01 Jan 0001 00:00:00 +0000

Примечание

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

Одна из основных целей etcd — поддерживать очень большое число наблюдателей, выполняющих огромное количество наблюдений. etcd стремится поддерживать O(10k) клиентов, O(100K) потоков наблюдения (O(10) потоков на клиента) и O(10M) наблюдений в сумме (O(100) наблюдений на поток). На каждое отдельное наблюдение приходится наибольшая часть общего потребления памяти etcd, поэтому именно оно находится в центре текущей и будущей оптимизации.

Тестирование производительности etcd v3

Mon, 01 Jan 0001 00:00:00 +0000

Физические машины

GCE тип машинного оборудования n1-highcpu-2

1x выделенный локальный диск SSD, подключённый под /var/lib/etcd
1x выделенный медленный диск для ОС
1.8 GB памяти
2x процессора
версия etcd 2.2.0

etcd Кластер

1 участник etcd, работающий в режиме демонстрации v3

Тестирование

Используйте инструмент тестирования производительности etcd v3 .

Производительность

чтение одного ключа

размер ключа в байтах	количество клиентов	чтение QPS	90-й процентиль задержки (мс)
256	1	2716	0.4
256	64	16623	6.1
256	256	16622	21.7

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

Тестирование памяти etcd v2.2.0-rc

Mon, 01 Jan 0001 00:00:00 +0000

Физическая машина

Тип машины GCE n1-standard-2

1x выделенный локальный SSD, подключённый в /var/lib/etcd
1x выделенный медленный диск для ОС
7.5 GB памяти
2x CPU

etcd

etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64

Тестирование

Запускается кластер etcd из 3 участников, каждый из которых использует 2 ядра.

Тестирование производительности etcd v2.2.0-rc

Mon, 01 Jan 0001 00:00:00 +0000

Физическая машина

Тип машины GCE n1-highcpu-2

1x выделенный локальный SSD, подключённый в /var/lib/etcd
1x выделенный медленный диск для ОС
1.8 GB памяти
2x CPU

Кластер etcd

3 участника etcd 2.2.0-rc, каждый работает на отдельной машине.

Точные версии:

etcd Version: 2.2.0-alpha.1+git
Git SHA: 59a5a7e
Go Version: go1.4.2
Go OS/Arch: linux/amd64

Кроме того, базовая производительность измеряется на кластере из 3 участников etcd 2.1.0 стадии alpha. Текущий коммит etcd — c7146bd5 , тот же, что использован в тестировании etcd 2.1 .

Тестирование производительности etcd v2.2.0

Mon, 01 Jan 0001 00:00:00 +0000

Физические машины

Тип машины GCE n1-highcpu-2

1x выделенный локальный SSD, используемый как каталог данных etcd
1x выделенный медленный диск для ОС
1.8 GB памяти
2x CPU

Кластер etcd

3 участника etcd 2.2.0, каждый работает на отдельной машине.

Точные версии:

etcd Version: 2.2.0
Git SHA: e4561dd
Go Version: go1.5
Go OS/Arch: linux/amd64

Тестирование

Запустите ещё одну машину вне кластера etcd и примените инструмент HTTP-тестирования hey с патчем повторного использования соединений для отправки запросов каждому участнику кластера etcd. Патч и шаги для воспроизведения процедуры приведены в инструкции по тестированию .

Тестирование производительности etcd v2.1.0

Mon, 01 Jan 0001 00:00:00 +0000

Физические машины

Тип машины GCE n1-highcpu-2

1x выделенный локальный SSD, подключённый в /var/lib/etcd
1x выделенный медленный диск для ОС
1.8 GB памяти
2x CPU
etcd версии 2.1.0 alpha

Кластер etcd

3 участника etcd, каждый работает на отдельной машине

Тестирование

Запустите ещё одну машину и с помощью инструмента HTTP-тестирования hey отправляйте запросы каждому участнику etcd. Подробные инструкции приведены в руководстве по разработке тестов производительности .

Обновление кластеров etcd и приложений

Mon, 01 Jan 0001 00:00:00 +0000

В этом разделе содержатся документы, специфичные для обновления кластеров etcd и приложений.

Политика обновления

Перед обновлением обратите внимание, что etcd поддерживает только следующие два случая обновления:

Обновление патча: обновление между выпусками патча в рамках одной минорной версии (e.g. 3.7.0 - 3.7.1).
Минорное обновление: обновление по одной минорной версии за раз (e.g. 3.6 - 3.7). Обновления, пропускающие минорную версию, не поддерживаются и, скорее всего, завершатся неудачно. Обновитесь до последней версии патча перед обновлением до следующей минорной версии.

Обновление кластера etcd v3.x

Обновление с etcd v2.3

Обновление кластера v2.3 до v3.0

Снижение версии кластеров etcd и приложений

Mon, 01 Jan 0001 00:00:00 +0000

В этом разделе содержатся документы, специфичные для понижения версии кластеров etcd и приложений.

Снижение версии кластера etcd v3.x

Обновление etcd с v3.5 до v3.6

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd v3.5 на v3.6 можно выполнить как скользящее обновление без простоя:

поочерёдно останавливать процессы etcd v3.5 и заменять их процессами etcd v3.6
после запуска всех процессов v3.6 кластеру становятся доступны новые возможности v3.6

До начала обновления прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки обновления

Обновление 3.5

Важно

Перед обновлением до 3.6 убедитесь, что все участники 3.5 обновлены до 3.5.32 или более поздней версии . Корректирующие выпуски с 3.5.24 по 3.5.26 устраняют несколько потенциальных препятствий обновлению; в 3.5.32 добавлен --v2-deprecation=write-only-skip-check, а etcdutl check v2store расширен для проверки не только снимка v2, но и записей WAL.

Понижение версии etcd с v3.7 до v3.6

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd v3.7 на v3.6 можно выполнить как скользящее понижение версии без простоя:

поочерёдно останавливать процессы etcd v3.7 и заменять их процессами etcd v3.6
после включения понижения версии новые возможности v3.7 становятся недоступны кластеру

До начала понижения версии прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки понижения версии

Основные различия между v3.7 и v3.6:

Различия во флагах

v3.7 не добавляет новых флагов, поэтому процесс v3.6 принимает все флаги конфигурации v3.7 и при понижении версии изменять конфигурацию не требуется.

Обновление etcd с 3.4 до 3.5

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd 3.4 на 3.5 можно выполнить как скользящее обновление без простоя:

поочерёдно останавливать процессы etcd v3.4 и заменять их процессами etcd v3.5
после запуска всех процессов v3.5 кластеру становятся доступны новые возможности v3.5

До начала обновления прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки обновления

Предупреждение

При миграции с v2 без данных v3 сервер etcd v3.2+ аварийно завершается, если etcd восстанавливается из существующих снимков, но файл v3 ETCD_DATA_DIR/member/snap/db отсутствует. Это происходит, когда сервер был перенесён с v2 и ранее не содержал данных v3. Такое поведение также предотвращает случайную потерю данных v3 (например, если файл db перемещён). etcd требует, чтобы после миграции на v3 работа продолжалась только при наличии данных v3. Не обновляйтесь до более новых версий v3, пока сервер v3.0 не содержит данные v3.

Понижение версии etcd от 3.5 до 3.4

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае, понижение версии от etcd 3.5 к 3.4 может быть безостановочным и ролевым:

по одному останавливайте процессы etcd 3.5 и заменяйте их на процессы etcd 3.4
после запуска любых процессов 3.4 новые функции в 3.5 больше не доступны для кластера

Перед началом понижения версии прочитайте остальную часть руководства и подготовьтесь.

Проверочные списки для понижения версии

содержимое/enhttps://etcd.io/docs/v3.5/op-guide/authentication/rbac.md

Предупреждение

Если в кластере включена аутентификация, поэтапное понижение с 3.5 не поддерживается: 3.5 изменяет формат связанных с аутентификацией записей WAL . Сначала следуйте инструкциям по аутентификации , чтобы отключить её и удалить всех пользователей.

Понижение версии etcd с v3.6 до v3.5

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd v3.6 на v3.5 можно выполнить как скользящее понижение версии без простоя:

поочерёдно останавливать процессы etcd v3.6 и заменять их процессами etcd v3.5
после включения понижения версии новые возможности v3.6 становятся недоступны кластеру

До начала понижения версии прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки понижения версии

Основные нарушающие совместимость изменения между v3.6 и v3.5:

Различия во флагах

Если в конфигурации v3.6 используются какие-либо из следующих флагов, при переходе на v3.5 обязательно удалите или переименуйте их либо измените значение по умолчанию.

Обновление etcd с 3.3 до 3.4

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd 3.3 на 3.4 можно выполнить как скользящее обновление без простоя:

поочерёдно останавливать процессы etcd v3.3 и заменять их процессами etcd v3.4
после запуска всех процессов v3.4 кластеру становятся доступны новые возможности v3.4

До начала обновления прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки обновления

Предупреждение

Обновление etcd с v3.6 до v3.7

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd v3.6 на v3.7 можно выполнить как скользящее обновление без простоя:

поочерёдно останавливать процессы etcd v3.6 и заменять их процессами etcd v3.7
после запуска всех процессов v3.7 кластеру становятся доступны новые возможности v3.7

До начала обновления прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки обновления

Обновление 3.6

Важно

Перед обновлением до 3.7 убедитесь, что все участники 3.6 обновлены до 3.6.11 или более поздней версии. Предыдущие корректирующие выпуски 3.6 могут быть несовместимы со скользящим обновлением до 3.7.

Обновление etcd с 3.2 до 3.3

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае переход с etcd 3.2 на 3.3 можно выполнить как скользящее обновление без простоя:

поочерёдно останавливать процессы etcd v3.2 и заменять их процессами etcd v3.3
после запуска всех процессов v3.3 кластеру становятся доступны новые возможности v3.3

До начала обновления прочитайте оставшуюся часть руководства и подготовьтесь.

Контрольные списки обновления

Предупреждение

При миграции с v2 без данных v3 сервер etcd v3.2+ аварийно завершается, если etcd восстанавливается из существующих снимков, но файл v3 ETCD_DATA_DIR/member/snap/db отсутствует. Это происходит, когда сервер был перенесён с v2 и ранее не содержал данных v3. Такое поведение также предотвращает случайную потерю данных v3, например если файл db перемещён. etcd требует, чтобы после миграции на v3 работа продолжалась только при наличии данных v3. Не обновляйтесь до более новых версий v3, пока сервер v3.0 не содержит данные v3.

Обновление etcd от 3.1 до 3.2

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае, обновление от etcd 3.1 до 3.2 может быть обновлением с нулевым временем простоя:

по одному, останавливайте процессы etcd v3.1 и заменяйте их процессами etcd v3.2
после запуска всех процессов v3.2, новые функции в v3.2 становятся доступны для кластера

Перед обновлением внимательно прочитайте оставшуюся часть этого руководства для подготовки.

Обновление списков проверки

Предупреждение

При миграции с v2 без данных v3 сервер etcd v3.2+ аварийно завершается при восстановлении из снимка без файла v3 ETCD_DATA_DIR/member/snap/db. Это происходит после миграции с v2 без прежних данных v3 и предотвращает случайную потерю v3, например при перемещении db. После миграции на v3 etcd требует данные v3. Не обновляйтесь до более новых версий v3, пока сервер v3.0 не содержит данные v3.

Обновление etcd с 3.0 до 3.1

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае обновление etcd с 3.0 до 3.1 можно выполнить поэтапно без простоя:

по очереди останавливать процессы etcd v3.0 и заменять их процессами etcd v3.1;
после запуска всех процессов v3.1 кластеру станут доступны новые возможности v3.1.

Перед началом обновления прочитайте остальную часть руководства и подготовьтесь.

Контрольные списки обновления

Предупреждение

При миграции с v2 без данных v3 сервер etcd v3.2+ аварийно завершается при восстановлении из существующих снимков, если отсутствует файл v3 ETCD_DATA_DIR/member/snap/db. Это происходит, когда сервер мигрировал с v2 и ранее не содержал данных v3. Такое поведение также предотвращает случайную потерю данных v3, например при перемещении файла db. После миграции на v3 etcd может работать только с данными v3. Не обновляйтесь до более новых версий v3, пока сервер v3.0 не содержит данных v3.

Обновление etcd с 2.3 до 3.0

Mon, 01 Jan 0001 00:00:00 +0000

В общем случае обновление etcd с 2.3 до 3.0 можно выполнить поэтапно без простоя:

по очереди останавливать процессы etcd v2.3 и заменять их процессами etcd v3.0;
после запуска всех процессов v3.0 кластеру станут доступны новые возможности v3.0.

Перед началом обновления прочитайте остальную часть руководства и подготовьтесь.

Контрольные списки обновления

Предупреждение

Управление PR

Mon, 01 Jan 0001 00:00:00 +0000

Назначение

Ускорить управление PR.

PR проекта etcd перечислены на странице https://github.com/etcd-io/etcd/pulls У PR могут быть различные метки, этап, рецензент и другие атрибуты. Подробный список меток находится на странице https://github.com/kubernetes/kubernetes/labels

Для удобства ниже приведено несколько примеров поиска PR:

Область применения

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

Атрибуция и лицензирование

Mon, 01 Jan 0001 00:00:00 +0000

pig.center повторно публикует документацию, написанную шестью исходными проектами. В конце каждой страницы документации приведена строка атрибуции: из какой работы она получена, кому принадлежат авторские права, по какой лицензии распространяется и в каком разделе этой страницы приведены соответствующие сведения.

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

Примечание

Русская версия полностью охватывает Patroni, PgBouncer, pgBadger и etcd. Для pgBackRest, HAProxy и отдельных ещё не переведённых маршрутов ссылки открывают соответствующую английскую страницу.

Поиск

Mon, 01 Jan 0001 00:00:00 +0000