занимает пол часа . Как ускорить бэкап. Какое архитектурное изменение можно сделать, может вынести жирную таблицу в отдельную базу ну или nosql какой нить заюзать?
Я б логи таблицы сохранил в файле csv на сервере а саму таблицю почистил. И может через через file_fdw или copy
Мы для логов используем партицирование. Первый вариант простотпартиции. Каждый месяц дамп партиции и дроп. Второй вариант вторая нода настроена логическая репликация (у нас реплицируются только insert) это наш архив. На первой ноде так же каждый месяц дроп партиции
Перейти на pg_basebackup.
Ну, то есть это самое просто решэние. Не то, чтобы не было других, но...
postgres готовый скаверный от yandex
партиции есть про дамп партиции и дроп не можно подробнее? Мы пока ни разу не чистили эта таблицу
так как кластер уже сварен яндексом , доступа к файлам нету, но скорее всего она не подойдет, как я понимаю ей нужен доступ к файлам базы, у нас только сетевой конект
А, то есть копии, полученные через что-то вроде pg_basebackup они не выдают? Тогда да, тогда это не вариант.
ну вообще у них есть свой инструмент бэкапа но я по старинке юзаю pgdump, минус ихнего инструмента в том что если форс мажор то нужно рядом новый кластер поднимать и в него разворачивать а это деньги типа
Я часто пересматриваю их доклад о миграции с оракла...
любое решение для физического бэкапа потребует поднятие нового кластера
Ну да. Тогда можно партицыонировать. При бэкапе запрашывать только свежую партицыю, остальные -- верифицыровать через что-то вроде подсчёта сумм.
ну почему, рядом быстро развернули в новую базу с дампа базу, переключили приложение на новую базу
Так в любом случае, если основной навернулся -- то надо ещё один поднимать... И да, если свой инструмент выдаёт файлы базы и WAL -- то можно и это использовать. Заодно потренируетесь у себя поднимать копию яндэксовского сетапа.
по времени примерно тоже самое что и и с дапка через pg_restore
Обсуждают сегодня