OmniPITR 0.6.0

Just released new version, 0.6.0 (it should be visible on pgxn soon) of OmniPITR set of tools.

New version has one new feature – parallelism.

This works in omnipitr-archive and omnipitr-backup-* programs, and allows for parallel delivery to remote destinations (multiple -dr switches).

Also – if you're using compresses wal archive and omnipitr-backup-slave reading from it – all the wal files have to be decompressed before making backup – and this decompression can be parallelized too.

All parallelization is controled using -PJ option (–parallel-jobs), so you can add “-PJ 10" to get up to 10 decompressions at the same time or up to 10 deliveries at the same time.

Waiting for 9.2 – pg_basebackup from slave

On 25th of January, Simon Riggs committed patch:

Allow pg_basebackup from standby node with safety checking.
Base backup follows recommended procedure, plus goes to great
lengths to ensure that partial page writes are avoided.
Jun Ishizuka and Fujii Masao, with minor modifications

Continue reading Waiting for 9.2 – pg_basebackup from slave

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.

OmniPITR 0.2.0

Just released version 0.2.0 of OmniPITR. There is one important change – that is OmniPITR backup programs can now create checksum files for backups.

Details in docs, but the basic idea is that to all the other options to omnipitr-backup-{master,slave} we added (Phil Sorber to be exact) –digest option, which lets you specify that you want some checksums (md5, sha1, sha2).

OmniPITR – important update

Couple of important points:

  • Fixed omnipitr-backup-slave on Pg 9.0
  • Added tests system which lets me check if the omnipitr actually work after I change stuff
  • Finally added version information.

The fix is important – in some cases, making backups off slave on 9.0 will not work.

By not work I mean that backups would be still done, but Pg wouldn't start from it. If started as slave, it would work OK, but you wouldn't be able to promote it to standalone.

New version of OmniPITR fixes that, as long as you're using -cm switch (and possibly some others like -h, -P, -U or -d – details in docs.

Version information is actually not really simple to get, it requires:

perl -I/opt/omnipitr/lib -le 'use OmniPITR::Program; print $OmniPITR::Program::VERSION'

But it works. It will be changed to normal –version option in near future.

Also, as you can perhaps see, we migrated to github.

OmniPITR – update

As of yesterday OmniPITR got following changes/fixes:

  1. Fixed bug which caused immediate finish request be treated the same as smart finish request.
  2. Fixed problem with using omnipitr-backup-slave on PostgreSQL 9.0 slave, which is using streaming replication.
  3. Added option to omnipitr-restore, so that you can now use it for streaming-replication slaves

I'm very ashamed of the first thing (smart/immediate finish request), as it was simply my lack of test.

Second thing – the problem was that with streaming replication slave behaves a bit differently than normally, and so the backup procedure had to be modified.

As for third – restore command in streaming replication environment has to behave differently than normal restore command – i.e. it should finish, with error, as soon as it will be called for wal file that does not exist in wal archive. Which is direct opposite of what should be done normally.

Now, omnipitr-restore got switch (-sr) to make it work correctly in SR situation.

Links for svn/docs are listed on project page.

Tablespaces support for omnipitr-backup-*

Really cool news. Thanks to sponsoring from, 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 – I'm usually on #postgresql.