У меня есть таблица размером 1 ТБ (X), которую сложно резервировать.
Таблица X содержит исторические данные журнала, которые не часто обновляются после создания. Обычно мы обращаемся только к одной строке за раз, поэтому производительность по-прежнему очень хорошая.
В настоящее время мы делаем полные логические резервные копии каждую ночь и исключаем X для экономии времени и места для резервного копирования. Нам не нужны исторические резервные копии X, поскольку файлы журналов, из которых он заполняется, копируются сами. Однако восстановление X путем повторной обработки файлов журнала заняло бы ненужное много времени.
Я хотел бы включить X в нашу стратегию резервного копирования, чтобы время восстановления могло быть намного быстрее. Не представляется возможным включать X в ночную логическую резервную копию.
В идеале мне нужна одна полная резервная копия для X, которая обновляется постепенно (исключительно для экономии времени).
Мне не хватает опыта, чтобы самостоятельно исследовать решения, и мне интересно, какие у меня есть варианты?
Бармен для дополнительных обновлений? Раздел X? Оба?
Прочитав еще немного, я склонен разделить таблицу и написать ночной сценарий для выполнения логического резервного копирования только измененных разделов таблицы (и замены предыдущих резервных копий). Однако эта стратегия может занять много времени во время восстановления с pg_restore
... Мысли?
Спасибо!
@LaurenzAlbe Спасибо, это преимущество, которое я раньше не рассматривал!
Я думаю, что использование barman с опцией потоковой передачи rsync / SSH + WAL и выполнение инкрементных резервных копий - лучший вариант в вашем случае. Такой подход делает ваши ночные резервные копии более легкими и менее затратными, так как вам не нужно самостоятельно выполнять логику после настройки barman. Я скоро обновлю это в своем блоге, в котором подробно описаны шаги.
Логическое резервное копирование может быть неправильным подходом для периодического резервного копирования при работе с большими базами данных. При использовании физических резервных копий, даже если размер вашей резервной копии велик, это более чем компенсируется затратами на приобретение и восстановление (производительность, скорость и простота).
Спасибо
ОБНОВЛЕНИЕ (2020-08-27):
Ниже представлен репозиторий git с конечной демонстрацией. Существует множество версий реализаций, которые сделали это, но если вы хотите сделать что-то с нуля и сохранить простоту изображения (избегая ненужных зависимостей), взгляните на эту реализацию,
https://github.com/softwarebrahma/PostgreSQL-Disaster-Recovery-With-Barman
Спасибо
Вы создали репозиторий Git? Если да, может быть лучше настроить это для работы с более современной версией Postgres, а не с устаревшей 9.5.
Привет, @a_horse_with_no_name, да, это мой репозиторий Git. Я согласен, я использовал его, потому что мы все еще использовали эту версию, и у нее была вся поддержка, необходимая для предполагаемой цели. Я обновлю образ PostgreSQL до последнего и отправлю его вскоре после быстрого тестирования, это должно быть просто изменение версии в Dockerfile образа Postgres.
Думаю, твоя идея верна. Невозможно, чтобы восстановление таблицы размером 1 ТБ не заняло много времени, поэтому я бы не стал слишком беспокоиться об этом. Если вы начнете сначала восстанавливать последние разделы, вы даже можете открыть базу данных до того, как будет восстановлена вся таблица. Люди могут согласиться с тем, что до возвращения старых журналов требуется некоторое время.