Comments 5
А кто мешал поднять еще один полноценный кластер на pg18, и логически мигрировать в него? А то ваше решение через временную деградацию кластера - такое себе…
Никто не мешал, кроме ресурсов и скорости переключения.
А так - переключение на другой кластер на обновлённой версии было расписано в предыдущей статье, на которую в данной есть отсылки. Там переключались на новую строку подключения, использованную для "обновлённого" кластера.
Если же речь про два поднятых кластера: один по логической репликации получает данные от другого, и при этом строку подключения не меняем. Тогда надо выключить кластер патрони, удалить его через patronictl , далее включить новый кластер под старым имененем. Времени больше. Что также упомянуто.
То есть в этой статье сценарий под некоторые случаи, которые у нас пригодились.
Логическая репликация без мониторинга лага слота – это тихая бомба: WAL ротируется, слот отстаёт, данные теряются без алертов. Один SELECT pg_replication_slots в мониторинг решает вопрос.
Есть такое. Спасибо. Стоит добавить.
Пока такой сценарий для не нагруженных плюс без "гигантских" транзакций сервисов применяется.
да она вообще штука хрупкая, любой DDL её ломает де-факто. ХЗ ещё ломается ли она при репликации partitioned table если вдруг создался новый сегмент (логика говорит да, но не тестировал), в состоянии логической репликации возможно придется сидеть довольно долго.
Обновление базы за время смены мастера Patroni