Назад | Перейти на главную страницу

Стратегия резервного копирования PostgreSQL EC2

Я пытаюсь определить лучший подход к резервному копированию базы данных PostgreSQL на Amazon EC2. Я читал о паре вариантов.

1) Сделайте ежедневный снимок тома EBS, который использует ваша база данных.

Проблема, которую я вижу с этим подходом, заключается в том, что происходит, когда снимок делается во время записи? Не будут ли мои данные повреждены?

2) Используйте pg_dump, сожмите файлы и сохраните в S3.

pg_dump не создает поврежденные данные, однако восстановление базы данных из pg_dump может занять много времени

Какую стратегию следует использовать? Вариант 1 кажется заманчивым, потому что его проще сделать и восстановить, но рискую ли я, используя такой подход?

Я не могу говорить о PostgreSQL, так как не использую его, но я использую вариант вашего варианта 1 для резервного копирования баз данных MySQL на EC2 и успешно восстановил их без проблем.

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

Чтобы начать процесс создания снимков, вы хотите заморозить свои базы данных и очистить таблицы. Есть отличный скрипт, который сделает это, а также заморозит вашу файловую систему (если xfs) называется ec2-согласованный снимок (на сайте есть некоторые комментарии к PostgreSQL, которые могут указать вам приемлемое направление - он разработан для Ubuntu, но без особых проблем работает с другими дистрибутивами (например, Linux / CentOS от Amazon)). Насколько я понимаю, с PostgreSQL люди часто просто делают снимок (после замораживания файловой системы) и полагаются на встроенные в PostgreSQL возможности восстановления, чтобы восстановить все до работоспособного состояния. Тем не менее xfs_freeze по-прежнему важен для получения согласованного снимка.

Как только ваша файловая система заморожена (и ваша база данных будет очищена и заблокирована, если это возможно), сделайте снимок (в идеале используйте API напрямую, а не (очень) медленные команды на основе Java). Для возврата команды моментального снимка требуется всего (несколько) секунд, после чего вы можете разморозить файловую систему - созданный моментальный снимок будет согласованным, несмотря на дополнительные чтения.

Учитывая, что моментальные снимки являются дифференциальными (в некотором смысле) и сжатыми, этот подход намного более экономичен, чем использование S3, а также предлагает больше возможностей, он также позволяет восстанавливать данные намного быстрее и должен блокировать ваши базы данных на более короткий период. чем создание дампа. Также можно вращать ваши снимки, чтобы контролировать их количество - я написал Perl скрипт сделать это для меня.

Если сомневаетесь, попробуйте первый вариант, а затем создайте том EBS и проверьте базу данных, чтобы убедиться, что все работает - не доверяйте только тому, что резервная копия в порядке.