Комментарии 13
то есть при обновлении можно данные потерять))) ну его тогда, работает и ладно, чего его обновлять, геммор лишний
Спасибо за интересную статью.
А не засекали по времени, сколько занимает pg_upgrade без analyze? По опыту обычно не долго, несколько секунд.
План мог бы быть:
Делаем физическую реплику 13->13
Мастера переводим в readonly и делаем чекпоинт.
На новом инстансе делаем pg_upgrade 13->16 и promote
На pgbouncer/odyssey переключаем трафик в 16-й постгрес
Делаем analyze/reindex в фоновом режиме на новом мастере
Чтение мы не потеряем (будем читать с 13 постгреса который в ридонли), простой операций записи будет только на пунктах 3-4. Пункт 3 это по факту создание хардлинков и занимает несколько секунд. Пункт 4 это отправка -HUP в pgbouncer. А еще можно заморочиться с PAUSE в pgbouncer, и для приложений, работающих с БД, это будет выглядеть как "медленный ответ БД" вместо "упавшие запросы на запись в бд"
Какие минусы видите в таком подходе? Меня смущает деградация производительности после pg_upgrade без analyze, но честно говоря логическая репликация меня смущает ещё больше, так как сильно зависит от структуры таблиц. Не реплицируемые секвенции - это только одна из проблем.
Делаем физическую реплику 13->13
я не автор, но физическая очень требовательная, логическая дает возможности сменить/обновить ОС на которой стоит постгресс, то есть не будет дополнительных затрат на смену ОС.
Честно говоря никогда не сталкивался с проблемой по смене ОС при смене версии PG. Но обычно я менял ubuntu 20 на ubuntu 22, или CentOS 6 на CentOS 7. А FreeBSD x64 на Debian arm менять не доводилось.
Можете как-то подсветить, в чем может быть проблема при смене версии ОС, чтобы на эти грабли случайно не наступить?
а вы протестируйте
перенос как автор в самом начале дампом перенос с ubuntu 20.4 на 24.4 и что там разные локализации о чем будет в логах постгреса
обновление убунты 22.04 на 24.04 и что будет в процессе обновления
Я ошибся тут
перенос как автор в самом начале дампом перенос с ubuntu 20.4 на 24.4 и что там разные локализации о чем будет в логах постгреса
все получится при работе через дамп, т.к. несколько кластеров так и перенес.
Проблема при переносе с 20 на 24 у меня кажется была в другом, кажется при тестировании силами pro backup PG15 перенес базу с ubuntu 20.04 на 24.04 и были ошибки как ниже " The database was created using collation version X, but the operating system provides version Y. "
Обычно проблемы из-за смены библиотеки сопоставлений (collation)
Из свежего — физическая реплика PG 16 c Ubuntu 22.04 -> 24.04 не стартовала[104672] DETAIL: The database was created using collation version 2.35, but the operating system provides version 2.39.
[104672] HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE test REFRESH COLLATION VERSION
Нужны дополнительные приседания.
Изменение версии glibc может поломать некоторые индексы.
Пункт 3 это по факту создание хардлинков и занимает несколько секунд.
Нет. Надо тестировать. Потому что, помимо хардлинков создаётся из старой версии и накатывается на новую полный дамп схемы. А тут возможны варианты, особенно при наличии large objects (https://postgrespro.ru/docs/postgresql/17/largeobjects), которые живут в системном каталоге, соответственно, попадают в упомянутый дамп схемы. Да, наличие подобных объектов не вот уж распространено, но тем, не менее. Я встречался с такими БД.
Никогда не сталкивался с проблемами при миграции через логическую репликацию. Ключевая проблема у автора похоже заключается во фразе FOR ALL TABLES, в этом случае нужно дополнительно контролировать объем хранения журнала. Лучше всё же добавлять таблицы в репликацию порциями, начиная с неизменяемых или медленнее меняющихся, это позволяет как решить проблему с журналом так и избежать некоторых других рисков, например остановки репликации если кто-нибудь добавит таблицу на мастере, также позволяет перенастроить репликацию для отдельной таблицы (например изменив уникальный ключ).
например остановки репликации если кто-нибудь добавит таблицу на мастере
чуть дополню - поломать могут без добавления таблицы простым изменением структуры одной из реплицируемых таблиц. Чуть облегчить процесс восстановления при остановке репликации можно разнеся таблицы по нескольким репликациям, но их количество ограничено настройками, для увеличения количества нужно минимум перезапускать постгресс.
vacuumdb --all --analyze-in-stages
Не забывайте что vacuumdb можно выполнять параллельно , я обычно использую 8 потоков:
vacuumdb --all --analyze-in-stages --jobs 8
Как обновить PostgreSQL и не потерять данные: метод минимизации простоя