Задача on PIG.CENTER

Использование команды 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

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

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

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

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

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

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

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

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

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

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

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

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

Задачи

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

Задачи оператора

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

Как настроить демонстрационный кластер 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.

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

Преобразование отдельного экземпляра в кластер 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

Чтение из 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 (обратите внимание, ключ не возвращается).

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!" — значение, заключённое в кавычки

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 — время ожидания в секундах сессии блокировки.

Как проводить выборы лидера в кластере 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

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

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

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

Команда 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

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 предоставляет резолвер 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

Руководство по операциям

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

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

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

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

Архитектура описана в документе о динамическом изменении конфигурации .

Сценарии реконфигурации

В этом разделе рассмотрены распространённые причины изменения конфигурации. Обычно это сочетания добавления и удаления участников, описанные в разделе Операции изменения конфигурации кластера .

Повреждение данных

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

Снижение версии

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

Обновление кластеров 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.

Перед началом обновления прочитайте остальную часть руководства и подготовьтесь.

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

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

Триаж

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

Управление 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.

Задача on PIG.CENTER

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

Синтаксис

Описание

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

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

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

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

Задачи

Задачи оператора

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

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

Цель

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

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

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

Процедура

Задачи разработчика

Рекомендации по участию в разработке

Общение

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

Запуск тестов

Чтение из etcd

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

Процедура

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

Запись в etcd

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

Процедура

3. Запуск HAProxy

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

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

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

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

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

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

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

Параметры

Пример

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

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

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

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

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

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

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

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

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

Параметры

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

Примеры

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

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

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

Транзакции

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

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

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

Параметры

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

Примеры

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

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

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

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

Параметры

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

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

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

Параметры

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

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

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

Параметры

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

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

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

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

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

etcdctl

Пользователь `root`