Концепция on PIG.CENTER

Документация Patroni 4.1.5

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

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

Работа Patroni на системах с ограниченной памятью и Python 3.11+

Если Patroni работает в системе со строгими ограничениями памяти, например с vm.overcommit_memory=2 (рекомендуется для PostgreSQL), и используется Python 3.11 или новее, может наблюдаться неожиданное поведение:

Patroni выглядит исправным
PostgreSQL продолжает работать
REST API Patroni перестаёт отвечать
Операционная система сообщает, что Patroni прослушивает порт REST API
Журналы Patroni выглядят нормально, однако однократно могут появиться сообщения Exception ignored in thread started by: <object repr() failed>, MemoryError
Журналы ядра могут содержать сообщения наподобие not enough memory for the allocation

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

Введение

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 не требуется получать пакеты целиком.

pgBackRest 2.59.1 Документация

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

Введение

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

pgBackRest v2.59.1 — текущий стабильный выпуск. Примечания к выпуску находятся на странице Releases .

Поставьте нам звезду на GitHub , если вам нравится pgBackRest!

Новости

Август 17, 2026 — pgBackRest 2.59.1Выпуск

Июль 20, 2026 - Новый архив с дистрибутивом

Июль 20, 2026 — pgBackRest 2.59.0Выпуск

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

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

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

Документация PgBouncer 1.25.2

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

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

Цель PgBouncer — уменьшить влияние открытия новых соединений с PostgreSQL на производительность.

Чтобы объединение соединений в пул не нарушало семантику транзакций, PgBouncer поддерживает несколько режимов пула при перераспределении соединений:

Сеансовый режим пула: наиболее щадящий метод. При подключении клиента ему назначается серверное соединение на всё время клиентского соединения. После отключения клиента серверное соединение возвращается в пул. Это режим по умолчанию.
Транзакционный режим пула: серверное соединение назначается клиенту только на время транзакции. Когда PgBouncer определяет завершение транзакции, серверное соединение возвращается в пул.
Режим пула на уровне операторов: наиболее строгий метод. Серверное соединение возвращается в пул сразу после завершения запроса. В этом режиме запрещены транзакции из нескольких операторов.

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

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

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

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

HAProxy — это:

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

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

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

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

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

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

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

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

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

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

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

etcd 3.7 Документация

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

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

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

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

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

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

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

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

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

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

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

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

Сообщество

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

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

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

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

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

Поддержка

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

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 может значительно помочь: он ограничивает число соединений с каждым сервером безопасным значением, заметно ускоряя сервер и сохраняя его ресурсы для приложения.

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

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

Проблема

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

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

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

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

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

Поддержка 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, и он сам займётся остальным:

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

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

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

Barman

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

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

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

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 описаны в настройки .

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

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

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

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

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

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

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

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

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

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

Внутренности

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

Учеба

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

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

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 предоставляет хранилище ключей и значений с высокой стабильностью, надёжностью, масштабируемостью и производительностью. Зачем нужен шлюз 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. Режимы отказа Mon, 01 Jan 0001 00:00:00 +0000 В крупных развёртываниях машин отказы неизбежны. Машина выходит из строя при неисправности оборудования или программного обеспечения. Несколько машин могут отказать одновременно из-за перебоя питания или проблем с сетью. Разные виды отказов также могут происходить одновременно; перечислить все возможные случаи практически невозможно. В этом разделе описаны виды отказов и механизмы, позволяющие etcd сохранять работоспособность. Почти любой конкретный отказ можно отнести к одной из этих категорий. Чтобы подготовиться к редким или невосстановимым отказам , всегда создавайте резервные копии кластера 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. Версионирование сервиса и поддерживаемые версии Версии etcd выражаются как x.y.z, где x — мажорная версия, y — минорная версия, а z — версия исправления, в соответствии с терминологией Semantic Versioning . Новые минорные версии могут добавлять дополнительные функции в API. Проект etcd поддерживает ветки релизов для текущей версии и предыдущего выпуска. Например, когда v3.5 является текущей версией, поддерживается v3.4. Когда выпускается v3.6, v3.4 прекращает поддержку.

./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 предоставляет хранилище ключей и значений с высокой стабильностью, надёжностью, масштабируемостью и производительностью.

Зачем нужен шлюз 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.

Режимы отказа

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

В крупных развёртываниях машин отказы неизбежны. Машина выходит из строя при неисправности оборудования или программного обеспечения. Несколько машин могут отказать одновременно из-за перебоя питания или проблем с сетью. Разные виды отказов также могут происходить одновременно; перечислить все возможные случаи практически невозможно.

В этом разделе описаны виды отказов и механизмы, позволяющие etcd сохранять работоспособность. Почти любой конкретный отказ можно отнести к одной из этих категорий. Чтобы подготовиться к редким или невосстановимым отказам , всегда создавайте резервные копии кластера 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.

Версионирование сервиса и поддерживаемые версии

Версии etcd выражаются как x.y.z, где x — мажорная версия, y — минорная версия, а z — версия исправления, в соответствии с терминологией Semantic Versioning .
Новые минорные версии могут добавлять дополнительные функции в API.

Проект etcd поддерживает ветки релизов для текущей версии и предыдущего выпуска. Например, когда v3.5 является текущей версией, поддерживается v3.4. Когда выпускается v3.6, v3.4 прекращает поддержку.