Replication & Upgrades - PostgreSQL 9 Administration - page 300

F Adjust Master parameters in postgresql.conf as follows:
wal_level = 'archive'
archive_mode = on
archive_command = ‹scp %p $STANDBYNODE:$PGARCHIVE/%f›
archive_timeout = 30
F Adjust hot Standby parameters if required (see later recipe).
F Take a base backup, very similar to the process for taking a physical backup as
described in the Backup chapter.
Start the backup by running the following:
psql -c "select pg_start_backup('base backup for log shipping')"
Copy the data files (excluding the pg_xlog directory). Note that this requires
some security configuration to ensure that rsync can be executed without
needing to provide a password when it executes. If you skipped step 2, do
this now as follows:
rsync -cva --inplace --exclude=*pg_xlog* \
${PGDATA}/ $STANDBYNODE:$PGDATA
Stop the backup by running the following:
psql -c "select pg_stop_backup(), current_timestamp"
F Set the recovery.conf parameters on the Standby server as follows:
standby_mode = 'on'
restore_command = ‹cp $PGARCHIVE/%f %p›
archive_cleanup_command = ‹pg_archivecleanup $PGARCHIVE %r›
trigger_file = ‹/tmp/postgresql.trigger.5432›
F Start the Standby server.
F Carefully monitor replication delay until catch-up period is over. During the initial
catch-up period, the replication delay will be much higher than we would normally
expect it to be. You are advised to set hot_standby = off for the initial period only.
Use a script; don't do this by hand, even when testing or just exploring the capabilities. If you
make a mistake, you'll want to re-run things from the start again quickly, and doing things
manually is both laborious and an extra source of error.
How it works...
Transaction log (WAL) files will be written on the Master. Setting wal_level ensures that we
collect all changed data, and that WAL is never optimized away. WAL is sent from the Master
to the archive using archive_command and from there the Standby reads WAL files using
restore_command , and then replays the changes.