У меня есть приложение в production, которое использует PostgreSQL 12, и мне нужно обновиться на версию 15. Я читал про pg_dump, но не уверен, подходит ли это для базы данных объёмом почти в 50GB. Кто-нибудь это делал раньше без простоев?
Может ли твоё приложение какое-то время не писать в БД или тебе нужен абсолютный нулевой downtime? Если можешь остановить записи хотя бы на 5-10 минут, pg_upgrade - твой лучший друг, потому что преобразует файлы на том же диске без экспорта, так что на 50GB ты сэкономишь часы.
А если нужно избежать downtime полностью, есть трюк, который редко упоминают: можешь использовать логическую репликацию (logical replication) для синхронизации старой БД с новой параллельно, пока она продолжает работать, а потом переключиться, когда всё будет актуально - это немного сложнее настраивать, но золото, если сервис останавливать нельзя.
Но перед всем этим протестируй в staging-окружении хотя бы с дампом в несколько гигабайт, чтобы увидеть, сколько времени это займет при твоей специфической конфигурации.
Не делай просто pg_dump и restore в пустую базу, если не хочешь часы простоя - вместо этого используй pg_upgrade, который работает на том же сервере без экспорта/импорта, или если хочешь мигрировать на другой сервер, используй логическую репликацию, чтобы приложение продолжало работать во время синхронизации. С 50GB ты сэкономишь кучу времени и стресса, сделав это таким способом.
Ты уже проверила, что твоя версия 12 совместима напрямую с 15, или нужно пройти через промежуточные версии?
Что никто не упоминает - помимо pg_upgrade, ты должна рассмотреть полный backup перед чем-либо, потому что хотя pg_upgrade довольно надёжный, наличие такой запасной копии даст тебе спокойствие - особенно при 50GB.
Если совсем нельзя допустить полный downtime, есть логическая репликация (logical replication), где ты настраиваешь вторичный экземпляр версии 15, синхронизируешь его параллельно и потом делаешь failover, когда он готов, но это посложнее. Большинство людей, которых я знаю, в итоге выбирают pg_upgrade с коротким окном обслуживания, потому что это самый практичный и быстрый вариант для такого объёма.
При 50GB нужно быть осторожным, но pg_upgrade - это правильный выбор, если ты можешь допустить downtime в 5-10 минут. Многие не упоминают, что переход с PostgreSQL 12 на 15 - это большой скачок, который pg_upgrade спокойно обрабатывает за один раз, поэтому промежуточные версии не нужны.
Мой совет: перед всем остальным сделай полный backup с помощью pg_basebackup или pg_dump параллельно (используй pg_dump с опцией -j для параллелизации, это значительно сокращает время), а потом запусти pg_upgrade на production-сервере во время окна обслуживания.
И после upgrade обязательно запусти ANALYZE на больших таблицах, потому что меняются некоторые внутренние статистики и у тебя могут быть медленные запросы, если этого не сделать.
Если ты можешь позволить себе даже 10-15 минут простоя, pg_upgrade - это определённо твой вариант, потому что он делает миграцию на том же сервере без экспорта/импорта всех данных (с 50GB это сэкономит тебе кучу времени).
То, что здесь никто не упомянул, - это то, что перед всем остальным тебе нужно проверить, нет ли установленных расширений, несовместимых между версиями, потому что это может всё затормозить в последний момент и оставить тебя с неприятными сюрпризами, когда ты уже будешь в процессе конвертации. Мой совет: сделай полный бэкап с pg_basebackup в любом случае (на всякий случай), протестируй всё на сервере staging сначала, а потом уже запускай pg_upgrade в продакшене.
PostgreSQL 12 на 15 работает напрямую без промежуточных версий, поэтому pg_upgrade - это твой путь. Но здесь важно то, что перед запуском pg_upgrade нужно сделать полный бэкап с помощью pg_dump или физического бэкапа - не для самой миграции, а как подстраховка. Много людей пропускают этот шаг, потому что уверены, что pg_upgrade сработает, но если что-то пойдет не так с 50GB данных, не захочешь молиться.
Процесс довольно прямолинеен: устанавливаешь PostgreSQL 15 на том же сервере (или на отдельном, если предпочитаешь), останавливаешь записи в БД, запускаешь pg_upgrade с флагом `-k`, чтобы сохранить старые файлы как резервные копии, и даешь ему работать. С 50GB это может занять 5-15 минут в зависимости от железа, но потом у тебя всё преобразовано на месте без экспорта/импорта. Как только подтвердишь, что всё работает, только тогда удаляешь старые файлы версии 12.
Важный момент, который часто не упоминают - проверка расширений и пользовательских конфигураций. Если у тебя установлены расширения, pg_upgrade может столкнуться с проблемами - им нужно существовать и в PostgreSQL 15. Перед тем как что-то делать, выполни `SELECT extname FROM pg_extension;` в текущей БД и убедись, что все эти расширения поддерживают версию 15. Вот где чаще всего всё ломается, а не в самой миграции данных.
Войдите, чтобы ответить.
