Let’s talk dirty

Important disclaimer: the module that I'm writing about was written by my colleague Phil Sorber.

We all have been in, or heard about, situation like this:

$ UPDATE users SET password = '...'; WHERE id = 123;

(hint: first ; is before where).

Of course you should have backups, and you can protect yourself from it. But what if backup is too old, and you didn't protect yourself?

Continue reading Let's talk dirty

OmniPITR 0.3.0

Just released version 0.3.0 of our tool for handling WAL based replication in PostgreSQL – OmniPITR.

Version jump is related to addition of another tool – omnipitr-synch. This tool is used to copy PostgreSQL data dir (including all tablespaces of course) to remote location(s).

While this process is usually simple (call pg_start_backup(), transfer data, call pg_stop_backup()), thanks to the tool it can be wrapped as single call, with standardized logging, and tested logic. It also makes it trivial, and cheap, to setup more than one new slave at a time, without need to read data off master more than once.

Tablespaces support for omnipitr-backup-*

Really cool news. Thanks to sponsoring from AWeber.com, and code by Brian Dunavant OmniPITR has now support for additional tablespaces in backup creation.

This works on both master and slave, and happens automatically without any kind of user interaction or changing options – OmniPITR simply detects if you have additional tablespaces and backs them up to data tarball.

More details are places in TABLESPACES part of omnipitr-backup-* docs.

OmniPITR – update

OmniPITR project that I wrote about some time ago is going on.

Just today I finished tests for omnipitr-backup-slave – part of OmniPITR which lets you make hot-backups of WAL-slave machine – without any additional load on master.

As previously – please download (svn co) and test. In case you have problems – please mail me or contact me on irc.freenode.net – I'm usually on #postgresql.