On Fri, Mar 22, 2013 at 11:27 AM, Roberto Scattini <roberto.scattini@xxxxxxxxx> wrote:
primary_conninfo = ''
restore_command = '/opt/omnipitr/bin/omnipitr-restore -l /export/omnipitr/log/omnipitr-^Y^m^d.log -s gzip=/export/vacation_wal_archive -f /export/omnipitr/finish.recovery -r -sr -v -t /export/omnipitr/tmp/ %f %p'
archive_cleanup_command = '/opt/omnipitr/bin/omnipitr-cleanup -l /export/omnipitr/log/cleanup.log -a gzip=/export/vacation_wal_archive %r'
ok. tomorrow i will check that again. i think that when restore_command was enabled in the slave, the wal receiver proccess didnt appear (and i didnt see the changes inmediately happening in the slave).
On Thursday, March 21, 2013, wd <wd@xxxxxxxxx> wrote:
> You can combine warm standby and streaming, we do this in our product database.
> When the standby is to far from the master, the slave will try to use restore_command to restore the database(warm standby), when the standby catch up the master, the steaming will working again.
>
> BTW: we use ominipitr.
>
I think you should use an other restore_command, in warm standby, the resotre_command will not exit and continue check xlog files and restore them, the streaming won't start when in restore. Try use cp instead of it.
can you post your recovery.conf?
primary_conninfo = ''
restore_command = '/opt/omnipitr/bin/omnipitr-restore -l /export/omnipitr/log/omnipitr-^Y^m^d.log -s gzip=/export/vacation_wal_archive -f /export/omnipitr/finish.recovery -r -sr -v -t /export/omnipitr/tmp/ %f %p'
archive_cleanup_command = '/opt/omnipitr/bin/omnipitr-cleanup -l /export/omnipitr/log/cleanup.log -a gzip=/export/vacation_wal_archive %r'
thanks for the reply!
--
Roberto Scattini
