Джельтмены, позвольте нубский вопрос:
возможно pgAdmin-oм ресторить базу на удаленной машине, при том что файл с бэкапом лежит локально?
с удаленной на локальную он бэкапит. а вот для рестора че та локально файл не находит

Григорий, не ожидается ли поддержка lto стандарта (запись на ленты)?

Сегодня началась pgcon.org -- онлайн, бесплатная, 7 русскоязычных докладчиков.  Илья сегодня уже отстрелялся, теперь моя очередь, через 20 минут 2-часовой тюториал про оптимизацию, подключайтесь! (Это вместо постгрес-вторника у нас сегодня)

Надо сначала научиться в тар складывать

DO $do$
BEGIN
RAISE EXCEPTION 'hello!';
END;
$do$;

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

Коллеги, добрый вечер. А кто-то имел опыт работы с кластером с Patroni? Мы с развалившимся кластером, в тупике и отчаянии. И ничего не гуглится.

а в логах что?

Там история вот в чем. Есть три сервера, на длительное время один из них был выключен. Понятно, что отстал сильно, и можно было бы заново проинициализировать. Но! Ребутали еще и два оставшихся сервера. И теперь в кластере нет ни одного лидера.

Мы готовы смириться с потерей данных. Готовы любого сделать лидером и переинициализировать слейвы.

Но как это сделать не понимаем.

Patroni работает в связке с Consul. Логи могу показать, конечно

давайте

- базы запущены? ( стать пользователем postgres и выполнить ps fx|grep -v idle )
- подключится и проверить реплика или мастер ( psql + SELECT pg_is_in_recovery(); )
- выяснить текущую точку в транзакционном логе для каждой мастер базы ( psql + SELECT pg_current_wal_lsn(); )
- выбираем ту, где самая свежая позиция (больше цифра) — новый мастер
- физически заходим на другой узел и делаем patronictl reinit

вот так выглядит кластер после запуска серверов

вот так после restart первого сервера

journalctl -f -u patroni

в логах pg ничего я думаю интересного2020-05-26 16:04:04.433 EDT [1388] LOG:  database system was shut down in recovery at 2020-05-26 13:41:47 EDT
2020-05-26 16:04:04.433 EDT [1389] FATAL:  the database system is starting up
2020-05-26 16:04:04.434 EDT [1388] WARNING:  specified neither primary_conninfo nor restore_command
2020-05-26 16:04:04.434 EDT [1388] HINT:  The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2020-05-26 16:04:04.434 EDT [1388] LOG:  entering standby mode
2020-05-26 16:04:04.442 EDT [1391] FATAL:  the database system is starting up
2020-05-26 16:04:04.487 EDT [1388] LOG:  redo starts at 5/20C5E930
2020-05-26 16:04:04.998 EDT [1388] LOG:  consistent recovery state reached at 5/2432B440
2020-05-26 16:04:04.998 EDT [1388] LOG:  invalid record length at 5/2432B440: wanted 24, got 0
2020-05-26 16:04:04.999 EDT [1385] LOG:  database system is ready to accept read only connections

это была реплика

Они сейчас все выглядят как реплики