Как перенести базу данных PostgreSQL без потери данных?

У меня есть приложение в production, которое использует PostgreSQL 12, и мне нужно обновиться на версию 15. Я читал про pg_dump, но не уверен, подходит ли это для базы данных объёмом почти в 50GB. Кто-нибудь это делал раньше без простоев?

5 ответов

Не делай просто pg_dump и restore в пустую базу, если не хочешь часы простоя - вместо этого используй pg_upgrade, который работает на том же сервере без экспорта/импорта, или если хочешь мигрировать на другой сервер, используй логическую репликацию, чтобы приложение продолжало работать во время синхронизации. С 50GB ты сэкономишь кучу времени и стресса, сделав это таким способом.

Может ли твоё приложение какое-то время не писать в БД или тебе нужен абсолютный нулевой downtime? Если можешь остановить записи хотя бы на 5-10 минут, pg_upgrade - твой лучший друг, потому что преобразует файлы на том же диске без экспорта, так что на 50GB ты сэкономишь часы. А если нужно избежать downtime полностью, есть трюк, который редко упоминают: можешь использовать логическую репликацию (logical replication) для синхронизации старой БД с новой параллельно, пока она продолжает работать, а потом переключиться, когда всё будет актуально - это немного сложнее настраивать, но золото, если сервис останавливать нельзя. Но перед всем этим протестируй в staging-окружении хотя бы с дампом в несколько гигабайт, чтобы увидеть, сколько времени это займет при твоей специфической конфигурации.

DiegoHernandez автор вопроса Мы спокойно можем остановить операции записи на 10 минут. Тогда я попробую pg_upgrade, спасибо за информацию.

Ты уже проверила, что твоя версия 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 в продакшене.

Ваш ответ

Войдите, чтобы ответить.