Сколько нужно создавать слотов для 10 реплик при потоковой репликации?

Question

[xxx44yyy]

Правильно ли понимаю, что 1 слот = 1 репликация? Т.е. если мне нужно будет иметь 10 репликаций, то и слотов нужно сделать 10. Так?

Answer 1

[Melkij]

Зависит от схемы расположения реплик.

Каждое соединение репликации использует один из допустимых max_wal_senders хоста к которому подключается. Если вы настраиваете слоты репликации - то вдобавок вам нужно соответствующее число max_replication_slots на этом хосте.
pg_basebackup в свою очередь использует до двух коннектов max_wal_senders и до одного max_replication_slots (зависит от параметров запуска и версии)

Так если вы будете копировать все 10 реплик одновременно с помощью basebackup с одной мастер-базы - вам понадобится 20 max_wal_senders и 10 max_replication_slots. После запуска реплик будет использовано 10 max_wal_senders и от 0 до 10 max_replication_slots - смотря как настроите. Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.
Но это если настраивать репликацию без каскада.
Коннекты репликации считаются не по кластеру, а подключённые к конкретному инстансу. В случае каскада у вас легко может быть схема, например:
с мастера репликацию читают 3 реплики, с каждой из них репликацию получают ещё по 3 реплики - вот уже 9 реплик, а использовали только по 3 walsender на хост.

И при таком числе реплик весьма рекомендую делать каскад. И сеть на мастере поберечь и в случае переключения мастера придётся меньше баз рестартовать (primary_conninfo всё ещё меняется только рестартом всей базы, шанс у моего патча быть принятым в pg13 весьма призрачный)

Comments

[xxx44yyy]

Простите, но это слишком сложно всё. У меня вопрос немного проще. Попробую объяснить пунктиками:
- 1 мастер
- на этом мастере 1 БД

отдельно есть:
- replica-1 с 1 БД, полученной с мастера
- replica-2 с 1 БД, полученной с мастера
- replica-3 с 1 БД, полученной с мастера

На мастере, один из шагов - это создание слота, т.е. :

SELECT * FROM pg_create_physical_replication_slot('replica');

Вопрос: нужно делать слот под каждую реплику, то есть так:

SELECT * FROM pg_create_physical_replication_slot('replica-1');
SELECT * FROM pg_create_physical_replication_slot('replica-2');
SELECT * FROM pg_create_physical_replication_slot('replica-3');

или же нужно делать один слот, но во всех репликах использовать его?

[ky0]

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

[xxx44yyy]

ky0, Как раз читал и поэтому возник вопрос. Там не говорилось сколько их надо. Я пока вникаю в тему. Полагал что слот - это как в логической репликации - издатель/подписка. Поэтому думал что publisher примерно как слот. А реплики - примерно как подписчики. Отсюда и сделал вывод, что слот нужен один. Но усомнился, поэтому решил спросить у знающих.

[Melkij]

Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.

Я об этом так же написал в ответе.

- replica-1 с 1 БД, полученной с мастера

Потоковая репликация postgresql - всегда полная копия всего инстанса. Не может быть чтобы реплицировалась одна БД с кластера.

Мы не используем слоты репликации для потоковых реплик, увеличиваем вместо этого wal_keep_segments. Здесь оценка риска: без слота репликации реплика может отстать и её надо будет выключать и копировать заново. Слот репликации же будет удерживать WAL от удаления бесконечно пока их не прочитают. Типичная история - мастер лёг потому что кто-то забыл удалить слот репликации и место на диске в итоге кончилось. И вот между "лёг мастер" и "реплика работает но показывает старые данные" - выбор как-то обычно в сторону второго сценария, влияние на сервис менее болезненное.
Мониторить репликацию разумеется надо, но всё равно почему-то it happens.

[Melkij]

Полагал что слот - это как в логической репликации - издатель/подписка. Поэтому думал что publisher примерно как слот. А реплики - примерно как подписчики.

В логической репликации publisher может быть один, но каждый подписчик создаёт свой отдельный слот логической репликации на мастер-базе. Да, они тоже - replication slots.

[xxx44yyy]

Melkij,

Я об этом так же написал в ответе.

В гуще сложного текста пропустил, извините. Отметил ваш ответ как решение, спасибо.

Мы не используем слоты репликации для потоковых реплик, увеличиваем вместо этого wal_keep_segments. Здесь оценка риска: без слота репликации реплика может отстать и её надо будет выключать и копировать заново. Слот репликации же будет удерживать WAL от удаления бесконечно пока их не прочитают. Типичная история - мастер лёг потому что кто-то забыл удалить слот репликации и место на диске в итоге кончилось. И вот между "лёг мастер" и "реплика работает но показывает старые данные" - выбор как-то обычно в сторону второго сценария, влияние на сервис менее болезненное.
Мониторить репликацию разумеется надо, но всё равно почему-то it happens.

Мне до этого пока далеко. У меня весь обмен данными между мастером и репликами исчисляется килобайтами в день.