Posts Tagged secondary server
This is an inbuilt replication system in PostgreSQL that uses wal files to apply changes to the secondary server. Since this replication uses wal files any changes on the primary server(schema or data)are automatically applied to the secondary server.
Points to note:
*One thing to keep into consideration is that primary and secondary database servers should have the same major release installed in order to have this replication working. For eg if you have PostgreSQL 9.3.3 installed on your secondary server you can have 9.3.x on your master or vice a versa. However, any major release 9.1.x will not work with 9.3.x.
*Another point to take into cosideration is that whatever data objects you have on your primary server instance, all of that will be replicated to the secondary instance. You cannot have selective tables database or schemas replicate to your secondary database as it applies wal logs to the secondary server. Exceptional objects that are not replicated to your secondary database are the unlogged tables for eg temp tables.
*I assume you have postgreSQL 9.0 or higher installed on both primary and secondary server.
*I am using rsync to copy the wal files over to the standby. Make sure rsync works from the primary to the secondary server without using a password (public private key sharing).
On the Primary server:
1. Open the postgresql.conf file and make the following changes:
wal_level = hot_standby archive_mode = on archive_command = 'rsync %p hostname_or_ipaddress_secondary_server:path_to_the_archive_dir_on_secondary_server/%f' (create this directory on the secondary server) max_wal_senders = 1 #This is the number of secondary servers you want to send the wal files to. If you add another server to replication increment this value to 2. wal_keep_segments = 1200 (this is the number of wal files to keep in case the replication lags behind. Make sure there is enough space in the pg_xlog mount point to accomodate the wal files in the pg_xlog dir. 1200*16/1024=18.75GB)
2. Edit the pg_hba.conf file and grant the secondary server access for replication
host replication postgres ip_address_of_secondary_server/22 trust
3. Restart the PostgreSQL database
4. Make sure that wal files are being pushed to the archive directory on the secondary server (if not check the error in postgreql log file and rectify any permission or file transfer related issues)
5. Now take online-backup of the primary database
$ psql -c "SELECT pg_start_backup('label', true)" $ rsync -av --exclude pg_xlog --exclude postgresql.conf --exclude postgresql.pid path_of data_dir_on_primary/* ip_address_of_secondary_server:path_of data_dir_on_secondary $ psql -c "SELECT pg_stop_backup()"
On the Secondary server:
1. Edit the postgresql.conf file:
hot_standby = on archive_mode = off
2. Create recovery.conf and add following entries:
# Note that recovery.conf must be in $PGDATA directory. standby_mode = 'on' primary_conninfo = 'host=ip_address_of_primary port=5432 user=postgres' trigger_file = '/path_to/trigger.tg' (this is the file that will be created when we want to make the secondary server as primary) restore_command = 'rsync /path_to/archive/%f "%p"'
3. Start the standby database
You can calculate the replication lag by comparing the current WAL write location on the primary with the last WAL location received/replayed by the standby. They can be retrieved using pg_current_xlog_location on the primary and the pg_last_xlog_receive_location/pg_last_xlog_replay_location on the standby, respectively.
$ psql -c "SELECT pg_current_xlog_location()" -h ip_address_of_primary (primary host) pg_current_xlog_location -------------------------- 0/5000000 (1 row) $ psql -c "select pg_last_xlog_receive_location()" -h ip_address_of_secondary (standby host) pg_last_xlog_receive_location ------------------------------- 0/5000000 (1 row) $ psql -c "select pg_last_xlog_replay_location()" -h ip_address_of_secondary (standby host) pg_last_xlog_replay_location ------------------------------ 0/5000000 (1 row)
Streaming replication process can also be checked by using ps -ef
$ ps -ef | grep sender postgres 4950 4925 0 12:32 ? 00:00:00 postgres: wal sender process postgres 127.0.0.1(4925) streaming 0/5000000
$ ps -ef | grep receiver postgres 5955 5941 1 12:33 ? 00:00:01 postgres: wal receiver process streaming 0/5000000