Снимки хранилища для последовательного резервного копирования postgresql - разные объемы данных и журналов

11

Мы запускаем много виртуальных машин Linux в среде vmware / shared storage, каждая из которых работает со своим собственным экземпляром postgreSQL (смесь 9.0 и 9.3). В настоящее время вся виртуальная машина находится в одном корневом разделе / ​​томе, и мы добились большого успеха (~ 8 лет), используя снимки на основе хранилища базовых томов VMFS для процесса резервного копирования / восстановления (и репликации на наш сайт DR).

Из-за архитектуры нашего хранилища было бы выгодно разделять файлы WAL postgres на некэшируемый том, в основном для записи, чтобы уменьшить отток кэша на стороне хранилища. С нашим хранилищем (Nimble Storage) мы можем назначить оба тома одной группе защиты / моментального снимка, но я не смог выяснить у нашего поставщика, что моментальные снимки будут происходить ровно в одно и то же время на всех томах в группе защиты - вероятно, так и будет, но всегда есть вероятность того, что его миллисекунды разделены.

С этой целью мы провели несколько экспериментов, все во время записи данных в БД как можно быстрее, используя pg_bench. После экспериментов мы восстановили тома с моментальными снимками и запустили VM + postgres.

  • Снимок данных и томов журналов, близких к одновременно, - результат: БД восстановлена
  • Сначала объем данных снимка, объем журнала ~ 1 минута спустя - результат: восстановлена ​​БД
  • Сначала том журнала снимков, объем данных ~ 1 минута спустя - результат: восстановлена ​​БД
  • Сначала том журнала снимков, объем данных ~ 3 минуты спустя, после того, как контрольная точка WAL записала новые данные в файлы данных: результат: БД восстановлена

Таким образом, похоже, что тестирование говорит нам о том, что оба снимка согласованы на уровне тома и относительно близко друг к другу, и вы получите согласованную копию БД, основанную на времени снимка тома WAL / Log.

Мой вопрос: это безопасно? Какие основные случаи мы пропускаем в нашем тестировании, и что может пойти не так?

Документ Postgres указывает, что это небезопасно, но тестирование показывает, что оно довольно надежное: http://www.postgresql.org/docs/9.1/static/backup-file.html.

Если ваша база данных распределена по нескольким файловым системам, не может быть никакого способа получить точно одновременные замороженные снимки всех томов. Например, если ваши файлы данных и журнал WAL находятся на разных дисках, или если табличные пространства находятся в разных файловых системах, может быть невозможно использовать резервное копирование моментального снимка, поскольку моментальные снимки должны быть одновременными. Внимательно прочитайте документацию по файловой системе, прежде чем доверять методике непротиворечивых снимков в таких ситуациях.

ПРИМЕЧАНИЕ. Да, мы знаем о других параметрах, обеспечивающих их согласованность, таких как перевод PostgreSQL в режим «горячего» резервирования или использование интеграции VMware в нашем хранилище для успокоения самих ВМ, но мы ищем решение только для хранилища для скорости, удобства, и нулевое влияние на наших клиентов.

postgresql storage virtualisation Стив Р.
источник
2
Обновление - наш поставщик хранилищ, Nimble Storage, вернулся сегодня, недвусмысленно заявив, что моментальные снимки, сделанные в составе группы защиты, действительно одинаковы для разных томов / снятых в тот же момент времени, поэтому мой вопрос действительно спорный на данный момент. Однако - мне все равно было бы интересно, есть ли у кого-нибудь комментарии, так как в нашем тестировании Postgres кажется достаточно надежным, чтобы выдержать снимки, снятые не одновременно.
Стив Р.
Что вы имеете в виду, когда говорите «Том данных моментального снимка сначала, том журнала ~ 1 минута спустя», если данные и том журнала находятся в одной группе снимков, это будет сделано одновременно. поместите данные и том журнала в одну группу снимков и сделайте снимок, затем восстановите БД из этого снимка, это как восстановление после сбоя экземпляра. Ранее я тестировал резервное копирование на основе хранилища EMC с технологией моментальных снимков для Oracle. Это очень надежно.
fairybetty

Ответы:

2

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

Например, в дополнение к вашим тестам на основе pgbench, попробуйте добавить случайные вызовы, чтобы pg_switch_xlog()вызвать ротацию журналов, сократить и увеличить интервалы между контрольными точками (укорачивать и удлинять checkpoint_timeoutи checkpoint_timeout) и даже использовать файлы малого или большого размера.

Если нет чего-то, что мне не хватает, поскольку ваши снимки не были сделаны одновременно, я бы отнес ваши восстановленные базы данных, возможно, к некоторому удачному выбору времени. В последнем случае, представьте , что вы взяли свой снимок журнала в то время как текущее xlog место было, скажем, 0/A1C0FFEE. Затем у вас есть 3 минуты особенно тяжелой нагрузки на систему, которая вызывает полный цикл работы с файлами WAL, и ваша БД теперь находится в момент, 0/DEADBEEFкогда делается снимок данных. Когда вы пытаетесь восстановить, файлы WAL, записываемые во время моментального снимка данных, давно исчезают, и восстановление завершится неудачно.

atomic77
источник