Можно ли быстро создавать / восстанавливать снимки базы данных с PostgreSQL?

Прежде всего, я разработчик, а не администратор или администратор; Пожалуйста, будьте нежны :)

Я работаю над рабочим процессом приложения, где одно действие пользователя вызовет сложные изменения в базе данных - создание сотен записей в одних таблицах, обновление сотен записей в других и т. Д. Всего около 12 таблиц (из ~ 100 ) тронуты этим действием. Из-за сложности, мне очень трудно вручную отменить все изменения, прежде чем я смогу запустить другой тест. В течение большей части моего времени разработки я могу просто вставить оператор «ROLLBACK» ближе к концу рабочего процесса, но когда я близок к принятию своих изменений, мне нужно проверить реальную вещь.

У меня есть локальная копия рабочей базы данных для работы. В моем случае создание дампов и восстановление между тестами происходит быстрее, чем написание скрипта для отмены всех изменений. Это быстрее, но все равно сильно тормозит (восстановление занимает около 20 минут на моем старом ноутбуке). Есть ли способ сохранить снимок текущего состояния базы данных, а затем быстро восстановить его?

Я гарантированно буду единственным пользователем в системе, и у меня есть root-доступ. Дамп базы данных составляет ~ 100 МБ, когда tar'ed и gzip'ed. Версия PostgreSQL - 8.3.

Заранее спасибо за любые полезные идеи.

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

Как насчет того, чтобы создать базовое состояние в качестве базы данных, а затем создать из него новую базу данных для тестового запуска, используя CREATE DATABASE ... TEMPLATEфункциональные возможности. После теста вы выбрасываете эту базу данных. Тогда ваше ограничение скорости - это, по сути, только время для cp -Rкаталога базы данных. Это почти так же быстро, как вы собираетесь без магии снимка файловой системы.

Используйте Stellar , это как git для баз данных:

Stellar позволяет вам быстро восстанавливать базу данных, когда вы, например, пишете миграцию базы данных, переключаете ветки или работаете с SQL. PostgreSQL и MySQL (частично) поддерживаются.

Если ваша база данных работает в Virtualbox , вы можете легко сохранять снимки и восстанавливать снимки состояния базы данных и самой ОС за несколько секунд (или 1-2 минуты, если у вас действительно много данных в базе данных или в ОС или очень мало памяти выделено для виртуальной машины) бесплатно.

В большинстве случаев было бы лучше установить облегченный linux (чем сервер Windows) для запуска виртуальной машины, на которой размещена база данных, если вы упомянули, что на вашем ноутбуке есть небольшие ресурсы.

На производственном сайте я использую резервные копии моментальных снимков MediaTemple для достижения того же результата (но это 20 $ на слот для резервных копий и зависит от этой службы веб - хостинга , так что она может не подойти вам).

Возможно, это не тот ответ, на который вы надеетесь, но рассматривали ли вы более низкий уровень моментальных снимков - например, LVM?

Нашел этот вопрос при попытке сделать то же самое и в итоге использовал git в каталоге данных postgresql. Отказаться от изменений так же просто, как:

git reset --hard

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

Хотя я должен сказать , Stellarи git reset --hardэто интересное решение, я буду иметь проблемы с большими базами данных и тестами, и я использовать и Virtualboxт.д. решение, как всегда, в больших испытаний, они , чтобы стать немного более «проблематичны» , когда вы используют голые металлические и т. д. решения.

Таким образом, я должен упомянуть ZFSв качестве файловой системы для рассмотрения в будущем по следующим причинам, которые @Peter Eisentraut также упомянул:

1. Снимки - особенно когда вы выполняете репликацию из Prod в QA / DR, вы можете использовать ту же «файловую систему» ​​для тестов:

#On a replication node, rather stop, snap, restore for a "consistent" backup ;)
su -l -c "/usr/bin/m2ee stop" acw_qa
pg_ctlcluster ${=QA} stop --force
zfs destroy -R $SNAPSHOT
pg_ctlcluster ${=REPLICATION} stop --force
zfs snapshot $SNAPSHOT
pg_ctlcluster ${=REPLICATION} start

zfs destroy $CLONE
zfs clone -o mountpoint=$CLONEDIR $SNAPSHOT $CLONE
rm $CLONEDIR/$CLUSTER/recovery.conf
pg_ctlcluster ${=QA} start
su -l -c "/usr/bin/m2ee start" acw_qa

1. чтобы выполнить тестирование, непосредственно перед тестом выполните остановку postgresql, как описано выше, zfs snapshot $SNAPSHOTзапустите postgresql, затем выполните откат, остановите postgresql и простоzfs rollback $SNAPSHOT

2. Сжатие - Postgresql получает типичное сжатие 3: 1 в моих базах данных, так что вы можете проводить больше тестов;)