Comments 4
Можно ли использовать такой подход:
— делаем копию базы
— на копии запускаем vacuum full
— подключаем репликацию и применяем WAL логи
— переключаем основную базу на реплику
?
Вижу одну проблему — в теории мощности реплики может не хватить чтобы догнать по WAL основную базу
— делаем копию базы
— на копии запускаем vacuum full
— подключаем репликацию и применяем WAL логи
— переключаем основную базу на реплику
?
Вижу одну проблему — в теории мощности реплики может не хватить чтобы догнать по WAL основную базу
+1
Вы не сможете сделать "подключаем репликацию". Потоковая репликация физического уровня, фактически там прямым текстом сказано "записать такие байты по такому смещению в такой-то файл". А после vacuum full у вас таких файлов и вовсе нет. Зато обработка репликации простая и быстрая штука.
Well, можно соорудить publisher subscriptions из pg10+. При начальном копировании данных будет как раз эффект репака. Только не очень понятно зачем.
PS: сопровождающий pgcompacttable и автор поддержки pg11+ для репака. В работе используем временамт, на грабли deferred ограничений как-то не натыкался. Интересная грабля.
+3
А почему вообще на новой таблице не удалить это ограничение (не создавать)? Создать его на момент переименования новой таблицы в старую?
0
Sign up to leave a comment.
Postgres: bloat, pg_repack и deferred constraints