OmniPITR
TODO
Even while developing first version of the OmniPITR, we know there are things that could be improved. But first things first - we have to finish development of base functionality before starting work on new stuff.
Here are the already known about missing features:
Ability to use %r in omnipitr-restore instead of relying on pg_controldata
While definitely good thing, we will still keep code to use pg_controldata as %r is not available in 8.2.
Provide support for --help option
Well, it can be helpful to avoid having to type another command to get to docs
Add support for config file
This has the benefit over command line options that it lets you change the options without Pg restart (in omnipitr-restore case at least).
Add a way to specify "primary" destination for wal segments.
This would be useful if you have WAL-slave in the same network, and additional slave, on a network link that can be down. Problems with non-primary destinations wouldn't stop replication to primary destinations.
Make temp directories inside given temp-dir, based on pid and/or random values - to allow easy running (for example) 2 slaves on the same machine.
Make it possible to provide remote source in omnipitr-restore and omnipitr-backup-slave (remote, via http/ftp)
Make it possible to provide multiple sources for omnipitr-restore
This is for migration purposes - for example, when you're switching your walarchive from compressed to not-compressed.
Add --version option to all programs.
Add option to skip archiving of xlogs to omnipitr-backup-*
This is assuming the user is keeping their own xlog archive and will limit the ability to restore a standalone database.
Support sending to cloud storage such as Amazon S3
Add support for xz compression (similar to lzma)
Add support for using ZFS/LVM snapshops.
This has the benefit of keeping required xlogs to a minimum for backups.
DONE
[0.7.0] Have omnipitr-backup-* look at .backup file to determine exactly what xlogs it needs to keep for backup integrity.
[0.6.0] Deliver to multiple destinations in parallel
When delivering wal segments to slave server, and to backup destination - we can reduce the time it takes, by delivering it in parallel.
[0.4.0] Add specialized program to serve as archive_cleanup_command - with support for compressed walarchive, and pausing removal
COPYRIGHT
The OmniPITR project is Copyright (c) 2009-2012 OmniTI. All rights reserved.