Комментарии 15
Задача казалась простой — я и не думал, что могут возникнуть проблемы
После этой фразы я до конца статьи ждал проблему. Но не дождался. Интересно, спасибо.
Есть множество статей про Патрони, с разными dcs. Версии обновляются, что-то меняется. Суть остается.
Но если бы в вашей статье был подъем версии patroni/etcd/postgre, то это было бы супер. К сожалениию, моего профиля не достаточно чтобы это осознать, а вот появляющиеся плюшки в новых версиях бд я готов понимать, объяснять и потреблять. Научите поднимать версию postgre, пожалуйста. С простоем в 8 секунд.
К сожалению в текущих реалиях (с 11 на 13 или 14 postgres) это равносильно запуску еще одного кластера патрони. Алгоритм прост - делаем 2ой кластер, подымаем логическую репликацию, переключаемся на новый кластер после синхронизации.
Но, на сколько я понимаю, логическая репликация сейчас имеет ограничения (сходу не перечислю) и не гарантирует оригинальную очередность применения dml. Поэтому (с патрони) и используется чтение журнала. И получится ли одновременно настроить два вида репликаций - для поддержания кластера и для наливки нового. Опять же, из мира mssql . Делаем полный бакап, наливаем. Разностный, опять наливаем. Обрубаем клиентов, последняя разница и переключение клиентов на новый кластер. Либо вообще detach-attach базы.
Получается, что нужно делать pg_upgrade. А в 14 версии индексы поменялись, значит несовместимость и хардлинком не получится переехать?
Логическая репликация даёт консистентные таблицы, единственная проблема в том, что она не переносит значения последовательностей и их придётся восстановить в момент переключения. В итоге при схеме с логической репликацией мы получаем много подготовительной работы и мараторий на schema change, но переключение за 8 секунд.
Вариант с pg_upgrade потребует от администратора базы меньше времени на подготовку, однако придётся обновлять все индексы(при обновлении до 12 или 13 версии) и пересобирать toast таблицы(в случае обновления до 14) . На работающем проде это может быть больнее, нежели настройка логической реплики.
Что ж так сложно-то все. Уже лет 10 я жду, когда появится утилита, которая требует вообще нулевого конфигурирования для PostgreSQL-кластера (типа zero config), но она никак не появляется.
Как это может работать: apt-get install super-postgres-cluster, дальше кладем на машину в ~postgresql/.ssh/ один и тот же id_rsa и authorized_keys на всех машинах кластера. Даем всем машинам hostname вида pgNN.xyz где NN - цифра. Это реально необходимый минимум, имея который, данная несуществующая утилита могла бы уже все сама настроить и поддерживать в живом состоянии (с автофэйловером и т.д.). Не нужен ни реестр хостов, ничего (потому что можно тупо взять текущий hostname и затем простучать все цифры от 00 до 99, пытаясь приконнектиться по ssh; если вышло, вот и сосед). Самый первый хост - мастер, остальные автоматически становятся репликами и автосинкаются с текущего мастера, без всяких настроек, и конфиги тоже с мастера стягивают. Даже пароли суперпользователя не нужны, потому что есть же ssh-доступ с любой машины на любую под юзером postgres. И распределенная БД (типа etcd) тоже может сама поставиться, запуститься и держаться в актуальном состоянии, без танцев с бубном с конфигами.
Добавил машину с указанной схемой именования - она автоналилась и стала репликой. Удалил машину - она удалилась из кластера. Положил файлик на нужный хост - он стал мастером, и все реплики на него автоматом переключились. Вообще ноль конфигурации и не нужна даже утилита командной строки.
Вам стоит посмотреть либо в сторону операторов postgres в kubernetes. Либо в сторону repmgr
Да ну щаз, конечно. Там настроек везде и тонкостей огромное количество. Недавно настраивал как раз repmgr, и близко не похоже на автоматику. Ощущение, что авторы утилит не слышали о принципах DRY и convention over configuration просто. Везде гигантская избыточность.
И вообще, если есть доступ по ssh с каждой машины на каждую, никакой etcd тоже не нужен. Можно поверх ssh все реализовать. Ssh - это универсальная штука, и имея ее, не обязательно даже порты постгреса открывать на фаерволе и делать, чтобы все машины друг друга видели по 5432 - можно через ssh просто тупо делать, и будет работать, заодно и энкрипшен трафика еще бесплатно.
Интересно, я понятно излагаю, или впечатление «о чем это вообще, ерунда какая-то»? Раньше ведь и на ассемблере программировали, а про другие языки говорили «да ну хрень какая-то избыточная». И про смартфоны без хардварной клавиатуры тоже.
У постгреса совершенно железобетонный движок репликации и сторадж, которые не ломается просто никогда. Можно даже файлы базы копировать rsync-ом при наливке реплики, всяко быстрее чем через replication протокол (да еще и можно продолжать с прерванного места). Но он очень низкоуровневый, и все существующие утилиты тоже слишком низкоуровневые. Тут громадная пропасть: штука хорошая, а управление ей - кабина экскаватора с 25 избыточными ручками вместо одной кнопки «сделать хорошо». В этом суть.
Если вас не устраивают существующие решения, которые позволяют сделать то, что вы хотите - никто не мешает реализовать свое.
Ваш скептицизм по поводу repmgr или операторов крайне странный. Так как требуется либо создать ресурс из 20 строк либо конфигурационный файл в 5 строк и разложить ключи, как в случае repmgr.
Я в принципе могу расписать, если интересует, как упростить конфигурации, чтобы было легче.
Мне видится, что философия PostgreSQL с самого начала была в минимальном техдолге — в том, чтобы проектировать и делать всё с «самых низов» очень красиво и правильно. Благодаря этому они и достигли той самой железобетонности. В то же время это естественным образом увеличивало порог вхождения. Начинающим пользователям было сложно (что, впрочем, не помешало проекту собрать свою аудиторию…), и тут прослеживается некий такой исторический след, который мешает. Считать ли это техдолгом перед массовыми пользователями? :-)
С другой стороны, с тех пор многое изменилось — в том числе и подход к инфраструктуре. Операторы для K8s, которые здесь предлагает Коля (и по которым он делал обзор), — это как раз новый, сегодняшний взгляд на проблему (и вариант её решения).
У меня обычно это сводится к одной команде: ansible-playbook add_pgnode.yml
Желательно выносить ETCD кластер на отдельные сервера. Это даст несколько преимуществ:
Упрощение администрирования. Например, перезапуск сервера без влияния на работу кластера etcd
Возможность использовать один кластер etcd для нескольких кластеров Patroni
Снижение рисков ухудшения стабильности кластера etcd, вызванного скачками нагрузки на базу данных.
При этом используется pg_basebackup. Если существующая база — большая, может потребоваться много времени для завершения этой операции. Например, в реальном кейсе, который дал начало этой статье, была база объёмом в 2,8 ТБ, и её бутстрап занимал около 10 часов на гигабитном канале.
Наливайте ваши реплики из бэкапа, пример pgbackrest, или wal_g, или pg_probackup). Таким образом Вы избавляете узлы текущего кластера от дополнительной нагрузки вызванной копированием данных с помощью basebackup. Параметр create_replica_methods - https://patroni.readthedocs.io/en/latest/replica_bootstrap.html#building-replicas
Опыт миграции кластера PostgreSQL на базе Patroni