Резервное копирование Postgresql PITR: лучшие практики для обработки нескольких баз данных?

Привет, ребята, у меня есть сервер postgresql 8.3 со многими базами данных.

На самом деле, я планирую сделать резервную копию этих БД с помощью скрипта, который будет хранить всю резервную копию в папке с таким же именем БД, например:

/mypath/backup/my_database1/
/mypath/backup/my_database2/
/mypath/backup/foo_database/

Каждый день я делаю 1 дамп каждые 2 часа, перезаписывая файлы каждый день... например, в папке my_database1 у меня есть:

my_database1.backup-00.sql  //backup made everyday at the 00.00 AM
my_database1.backup-02.sql  //backup made everyday at the 02.00 AM
my_database1.backup-04.sql  //backup made everyday at the 04.00 AM
my_database1.backup-06.sql  //backup made everyday at the 06.00 AM
my_database1.backup-08.sql  //backup made everyday at the 08.00 AM
my_database1.backup-10.sql  //backup made everyday at the 10.00 AM
[...and so on...]

Вот как я на самом деле уверяю себя, что смогу восстановить каждую базу данных, потеряв как минимум 2 часа данных.

2 часа все еще выглядит слишком много.

Я взглянул на postgresql pitr, который разбирал файлы WAL, но эти файлы, похоже, содержат все данные обо всей моей базе данных.

Мне нужно разделить эти файлы, так же, как я делаю файлы дампа.

Как?

Иначе, есть другая простая в установке процедура резервного копирования, которая позволяет мне восстанавливать только 1 резервную копию на 10 секунд раньше, но без создания файла дампа каждые 10 секунд?

Источник

3 ответа

Решение

Почему вы хотите разделить базы данных?

То, как работает PITR, невозможно, поскольку он работает на всем кластере. В этом случае вы можете создать каталог данных и отдельный кластер для каждой из этих баз данных (хотя и не рекомендуется, поскольку для этого потребуются разные порты и экземпляры postmaster).

Я считаю, что преимущества использования PITR вместо обычных дампов перевешивают наличие отдельных резервных копий для каждой базы данных, поэтому, возможно, вы сможете переосмыслить причины, по которым вам нужно разделить его.

Другим способом может быть настройка репликации с использованием Slony-I, но для этого потребуется отдельный компьютер (или экземпляр), который получает данные. С другой стороны, таким образом вы получите реплицированную систему практически в реальном времени.

Обновление для комментария:

Чтобы исправить ошибки, такие как удаление таблицы, PITR был бы идеальным вариантом, поскольку вы можете воспроизводить их в определенное время. Тем не менее, для 500 баз данных я понимаю, что это может быть много накладных расходов. Слони-я бы наверное не работал, так как это тиражирование. Не уверен, как он обрабатывает удаление таблиц.

Я не знаю ни о каких других путях, по которым ты можешь идти. То, что я сделал бы, вероятно, все еще будет идти на PITR и просто не делать никаких ошибок;). Помимо шуток, в зависимости от того, как часто допускаются ошибки, это может быть решением:

  • Установите это для PITR
  • второй экземпляр готов в режиме ожидания.
  • Если произошла ошибка, воспроизведите восстановление до момента времени во втором экземпляре.
  • Сделайте pg_dump для уязвимой базы данных из этого экземпляра.
  • Сделайте pg_restore в производственном экземпляре для этой базы данных.

Однако для этого потребуется готовый второй экземпляр, либо на том же сервере, либо на другом (рекомендуется другой). Кроме того, время восстановления будет немного больше, поскольку вам потребуется сделать один дополнительный дамп и восстановить.

Источник

Это невозможно с одним экземпляром PostgresSQL.

Вы можете разделить ваши 500 таблиц между несколькими экземплярами, каждый из которых прослушивает другой порт, но это будет означать, что они не будут эффективно использовать ресурсы, такие как память (память, зарезервированная, но не использованная в одном экземпляре, не может использоваться другим).

Slony также не будет работать здесь, так как он не реплицирует операторы DDL, например, отбрасывает таблицу.

Я бы порекомендовал сделать оба:

  • продолжайте делать ваши резервные копии pg_dump, но попробуйте сгладить его - throttle pg_dump io bandwith, чтобы он не наносил вред серверу и работал непрерывно - когда он заканчивает работу с последней базой данных, затем сразу же начинает работу с первой;

  • дополнительно настройка ПИТР.

Таким образом, вы можете быстро восстановить одну базу данных, но можете потерять некоторые данные. Если вы решите, что не можете позволить себе потерять такое количество данных, вы можете восстановить свою резервную копию PITR во временное хранилище (с fsync=off и символической ссылкой pg_xlog на ramdisk для скорости), оттуда pg_dump затронет базу данных и восстановит ее на основной база данных.

Источник

Я думаю, что вы делаете это ошибочно. У вас должна быть одна база данных с несколькими схемами и ролями. Тогда вы можете использовать PITR. Однако PITR не является заменой свалок.

Источник
Другие вопросы по тегам