Thanks Venkata, I am able to setup replication now. Just wondering when I check replication_delay and lag, I am getting negative number, any idea why?
receive | replay | replication_delay | lag --------------+--------------+-------------------+----- 796/BA9D8000 | 796/BA9D7FF0 | -00:00:01.612415 | -2 Thanks, Ashish From: Venkata Balaji N [mailto:nag1...@gmail.com] Sent: Sunday, February 21, 2016 2:14 AM, 2:14 To: Ashish Chauhan Cc: Andreas Kretschmer; pgsql-general@postgresql.org Subject: Re: [GENERAL] Live steraming replication setup issue! On Fri, Feb 19, 2016 at 6:24 PM, Ashish Chauhan <ashish.chau...@support.com<mailto:ashish.chau...@support.com>> wrote: Below is recovery.conf on slave #--------------------------------------------------------------------------- # STANDBY SERVER PARAMETERS #--------------------------------------------------------------------------- # # standby_mode # # When standby_mode is enabled, the PostgreSQL server will work as a # standby. It will continuously wait for the additional XLOG records, using # restore_command and/or primary_conninfo. # standby_mode = 'on' # # primary_conninfo # # If set, the PostgreSQL server will try to connect to the primary using this # connection string and receive XLOG records continuously. # primary_conninfo = 'host=<master server ip> port=5432' # # # By default, a standby server keeps restoring XLOG records from the # primary indefinitely. If you want to stop the standby mode, finish recovery # and open the system in read/write mode, specify path to a trigger file. # The server will poll the trigger file path periodically and start as a # primary server when it's found. # trigger_file = '/data/main/primary.trigger' Can you consider putting recovery_target_timeline='latest' as well ? and can you help us know if you can see anything weird in the postgresql logfiles @ DR ? Is DR in complete sync with the slave ? Regards, Venkata B N Fujitsu Australia
