Чи можливо швидко створити / відновити знімки бази даних за допомогою PostgreSQL?

Перш за все, я розробник, а не DBA або sysadmin; будь ласка, будь ласкавим :)

Я працюю над робочим процесом програми, де одна дія користувача спровокує складні зміни в базі даних - створення сотень записів в одних таблицях, оновлення сотень записів в інших тощо. Загалом, приблизно 12 таблиць (з ~ 100 ) торкаються цієї дії. Через складність мені дуже важко повернути всі зміни вручну, перш ніж я можу запустити черговий тест. Протягом більшої частини часу моєї розробки я можу просто вставити операцію "ROLLBACK" наприкінці робочого процесу, але коли я наближуюся до внесення змін, мені потрібно перевірити справжню річ.

У мене є локальна копія виробничої бази даних, з якою я працюю. У моєму випадку скидання та відновлення між тестами відбувається швидше, ніж написання сценарію, щоб скасувати всі зміни. Це швидше, але все одно мене дуже сповільнює (відновлення займає близько 20 хвилин на моєму старечому ноутбуці). Чи є спосіб я зберегти знімок поточного стану бази даних, а потім швидко відновити його?

Я гарантовано буду єдиним користувачем у системі, і у мене є кореневий доступ. Дамп бази даних становить ~ 100 МБ, коли таргується та 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 у моїх базах даних, тому ви можете зробити багато тестування більше;)