pmb17Павел Лузанов,
Спасибо. Немного стало понятно, но не все.
1. Есть ли в pg std 11 аналог pg_ctlcluster, чтобы управлять отдельным кластером а не всей службой сразу?
2. Как можно увидеть список рабочих кластеров? (аналог pg_lsclusters)


pg_ctlcluster и pg_lsclusters - в стандартном postgresql тоже отсуствуют...

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

pmb17Павел Лузановpmb17,

Насколько я знаю, для управления используется утилита pg_setup .
pg_setup service по командам аналогична pg_ctl. Неудобно конечно, но привыкнуть можно.

Пока не нашел как можно получить список кластеров, которые в принципе есть на сервере?

pg_lsclusters - тоже показывает только те что были средствами убунты поставлены
если вы руками поставите в нестандартное место или из исходников соберете - pg_lsclusters про них ничего знать не будет.

ps: держать несколько независимых кластеров postgresql на сервере идея неудачная (даже на тестовом), лучше тогда по виртуалкам или докерам раскидать для тестовой среды.

mefmanpmb17пропущено...


Почему неудачная? Несколько баз данных, для каждой свой настройка работы с WAL, потоковой репликации.
Опять же можно настроить резервное копирование для каждого кластера свое.
Чем несколько кластеров на одном сервере может быть плохо?
Я тоже не согласен с Maxim Boguk.
Идея иметь несколько баз на одной машине не неудачная , а идиотская .

Ну я всетаки консалтер... мне надо приличия соблюдать стараться (хотя иногда очень тяжело).

pmb17Maxim Bogukps: держать несколько независимых кластеров postgresql на сервере идея неудачная (даже на тестовом), лучше тогда по виртуалкам или докерам раскидать для тестовой среды.

Почему неудачная? Несколько баз данных, для каждой свой настройка работы с WAL, потоковой репликации.
Опять же можно настроить резервное копирование для каждого кластера свое.
Чем несколько кластеров на одном сервере может быть плохо?

1)крайне неэффективное и негибкое распределение ресурсов сервера (память/cpu) получается это раз
2)что еще хуже - крайне повышается риск operator error когда вы думаете что останавливаете или удаляете один кластер а по факту удаляете другой нужный в production (такие вещи происходят чаще чем кажется к сожалению поэтому лучше недопускать возможность подобных ляпов на уровне архитектуры.... он очень обидные и неприятные)
3)вообще все сложнее получается чем несколько виртуалок или несколько баз на одном кластере (в вашем варианте сочетаются все основные минусы как и виртуалок так и нескольких баз на одном кластере.... а плюсов особо и нет).