с одного сервера на другой.
Размер BD около 100GB
Время простоя до часа допускается!
Смотрю в сторону pg_basebackup
Или это сильно извращенно будет для данной задачи?
Спасибо!
https://t.me/pgsql/335316
У для похожего размера БД хорошо сработал pg_dump. Дамп в 6 потоков (сколько не жалко ядер) занял минут 10, сам дамп в формате tgz — около 10 Гб, восстановление — около часа. Кажется, восстановление можно тоже делать в несколько потоков. В pg_basebackup я честно пытался, но не смог правильно приготовить перенос журналов.
Это перенос BD Zabbix, боюсь что долго будет этим всем заниматься pg_dump...
ну вот у меня было несколько таблиц с десятками миллионов записей.
настроить между ними репликацию. Если версии пг одинаковые - то физическую. Если разные, то логическую. После синка, отрубаем клиентов на основном сервера(можно запретить дополнительно коннекты к базе, чтобы новые коннекты не успели ничего закоммитить), и промоутим реплику до мастера(если физическая реплика). Если логическая - синкануть сиквенсы. Меняем днс или настрокий приложений на новый адрес. Простой - минут 5
проблема с pg_dump в том, что рестор занимает непредсказуемое время, в отличие от pg_basebackup, время которого пропорционально размеру БД. Сам переносил БД в датацентр с другим уровнем допуска, не помню, чтобы были какие-либо проблемы с журналами: сначала накатили на новом месте БД с нуля (без рабочих пользовательских данных), а также остальную инфраструктуру, проверили, что всё работали, затем, в день миграции, остановили все сервисы на обоих площадках и postgres на новом сервере, переименовали директорию с кластером, на старом выполнили checkpoint (не факт, что это нужно было), через заранее открытый порт скопировали старый кластер на новый сервер через pg_basebackup, удалили инфу о бекапе и всё запустили. Собственно, при подготовке плана миграции потребовалась только дока на pg_basebackup.
для меньшего простоя надо реплику делать. и при переносе ее промотить и переключать запросы на нее
Обсуждают сегодня