Потребовалось сделать кластер для PostgreSQL, ну – поехали.
За основу “прохождения” принимается статья о1 1С – « Построение отказоустойчивого кластера PostgreSQL. Настройка внешней синхронизации на PostgreSQL для механизма копий баз данных».
Предвариловка
Устанавливаем русскую локаль. dpkg-reconfigure locales . По умолчанию для операционки я оставляю английскую, но русская нужна, чтобы потом выставить её в качестве основной для СУБД. Сравнения там, сортировки,…
etcd
Нетривиально: при нахождении кластера внутри сети организации, приходится использовать прокси для доступа к внешним ресурсам. Репозиториям или ещё к чему. Стандартный вариант – через переменные окружения http[s]_proxy. Но! etcdctl обращается через тот же http протокол, как следствие – лезет через прокси. Можно добавить хосты в no_proxy, однако, надо помнить, что no_proxy заточено под работу именно с именами, а не с ip. *.domain.ru – работает, а 10.* – нет. При этом, использование dns имён в конфиге etcd сомнительная практика (моя личная точка зрения), ибо сам по себе софт предназначен для контроля кластеризации и завязывать его на dns … Ну, не уверен, что это хорошая идея. Я перечисляю все ip серверов кластера в явном виде в переменной no_proxy.
Set a network range in the no_proxy environment variable
no_proxy: This variable should contain a comma-separated list of domain extensions proxy should not be used for
patroni
stats_temp_directory – я наступил на ситуации, когда пришлось снести базу на ведомом узле кластера. После этого, при запуске: инициализация базы происходит, репликатор всасывает с мастера, но потом postgres не стартует, ругается на отсутствующий каталог. Ибо он создаётся при стандартном запуске сервиса postgres, но не при запуске через patroni. Соответственно, в конфиге patroni должна быть эта опция.
wal_keep_segments – в примере от 1С – стоит 8. Но, это несерьёзно. Если потребуется пересоздать базу на слейве или добавить узел в кластер, то репликатор на ведомом просто не будет успевать всосать в себя базу за то время, пока файлы wal не перезапишутся. И реплика не создастся. Ну, вот у меня нагрузка такая, я наступал на эти грабли. Моё мнение: должно хватать на максимальный размер технологического окна, чтобы на слейве можно было сделать всё, что требуется. Каждый сегмент – 16 метров, 1000 должно хватать часа на четыре 🙂
haproxy
Самая беспроблемная (пока) часть. Тупо, по инструкции и работает, на удивление.
TimescaleDB
Расширение должно быть доступно при работе с любой схемой пользователя. Для некоторых прикладух, типа zabbix, это важно. Соответственно, я ставлю в pg_catalog. Т.е., команда \dx должна выдавать что-то типа:
=> \dx
List of installed extensions
Name | Version | Schema | Description
--------------------+---------+------------+------------------------------------------------------------------------
...
timescaledb | 2.8.1 | pg_catalog | Enables scalable inserts and complex queries for time-series data
Поскольку для меня данный опыт будет, возможно, первым и последним, тонкие настройки – потом. Да и вообще, сделана куча ляпов, но “на скорость не влияет”, а описывать все изменения, которые я уже внёс – лень.
Использованные материалы. Извините, если кого забыл
- https://its.1c.ru/db/metod8dev/content/5971/hdoc – основная статья
- https://arctype.com/blog/postgres-patroni/ – добавка к ней, заодно можно на сравнении понять, что на что влияет, да и, хотя бы, обозначает.
- https://patroni.readthedocs.io/en/latest/dynamic_configuration.html – дока по patroni
- Управление высокодоступными PostgreSQL кластерами с помощью Patroni. А.Клюкин, А.Кукушкин – для понимания
- https://patroni.readthedocs.io/en/latest/watchdog.html – вот тут меня переклинило. Не доделано. В том смысле, что сам watchdog есть, но до перезагрузки. Надо бы сделать, но у меня сервера живут годами, когда будет перезагрузка, возможно, уже и кластер будет не нужен.
- Для последующей оптимизации/настройки
- https://pgconfigurator.cybertec.at/ – калькулятор для прикидки параметров PostgreSQL
- https://pgtune.leopard.in.ua/ – и ещё один
- https://postgrespro.ru/docs/postgrespro/14/non-durability – оптимизация, угрожающая стабильности
- Настройка Write Ahead Log для PostgreSQL – на удивление, 1С неплохие инструкции публикует.
- https://eax.me/timescaledb/ – описание TimescaleDB, работы с временными рядами