From: | Ravi Tammineni <rtammineni(at)partner(dot)aligntech(dot)com> |
---|---|
To: | "tomas(dot)vondra(at)2ndquadrant(dot)com" <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Postgresql BDR Replication Setup Issue |
Date: | 2015-06-08 17:31:51 |
Message-ID: | afd2bc1e42064de490ef1ae73618c3ce@prscexmbx02.aligntech.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
We are setting up 2-node Postgresql BDR replication at our place and I am getting the following error after bdr_init_copy command.
FYI, We have a production Postgres database and we are setting up the Master-Master BDR replication for the production database.
==== Postgres Version
Postgres Version: psql (9.4.2)
apimgtdb=# SELECT bdr.bdr_version();
bdr_version
0.9.1-2015-05-26-1519509
==== bdr_init_copy running from Node2
-bash-4.1$ /usr/pgsql-9.4/bin/bdr_init_copy -d "host=10.10.145.111 dbname=apimgtdb port=5432" --local-dbname="host=10.10.145.110 dbname=apimgtdb port=5432" -n nodeawswest -D /postgres/pgsql-9.4/data
bdr_init_copy: starting ...
Getting remote server identification ...
Detected 1 BDR database(s) on remote server
Updating BDR configuration on the remote node:
apimgtdb: validating BDR configuration ...
apimgtdb: creating replication slot ...
apimgtdb: creating node entry for local node ...
Creating base backup of the remote node...
3616364/3616364 kB (100%), 1/1 tablespace
Creating restore point on remote node ...
Bringing local node to the restore point ...
Could not update security label: ERROR: cannot execute DELETE in a read-only transaction
==== Recovery file on Node2
cat recovery.conf
standby_mode = 'on'
primary_conninfo = 'dbname=apimgtdb host=10.10.145.111 port=5432'
recovery_target_name = 'bdr_6158050998150972399'
recovery_target_inclusive = true
====== Data from Node2 log file
< 2015-06-08 10:08:45.957 PDT >LOG: entering standby mode
< 2015-06-08 10:08:45.958 PDT >LOG: starting up replication identifier with ckpt at 9/F9000028
< 2015-06-08 10:08:45.965 PDT >LOG: redo starts at 9/F9000028
< 2015-06-08 10:08:45.969 PDT >LOG: consistent recovery state reached at 9/F90000F0
< 2015-06-08 10:08:45.970 PDT >LOG: database system is ready to accept read only connections
< 2015-06-08 10:08:45.980 PDT >LOG: started streaming WAL from primary at 9/FA000000 on timeline 1
< 2015-06-08 10:08:46.180 PDT >LOG: recovery stopping at restore point "bdr_6158052372057789529", time 2015-06-08 10:08:31.448384-07
< 2015-06-08 10:08:46.180 PDT >LOG: recovery has paused
< 2015-06-08 10:08:46.180 PDT >HINT: Execute pg_xlog_replay_resume() to continue.
< 2015-06-08 10:08:46.236 PDT >ERROR: cannot execute DELETE in a read-only transaction
< 2015-06-08 10:08:46.236 PDT >STATEMENT: DELETE FROM pg_catalog.pg_shseclabel WHERE provider = 'bdr';
< 2015-06-08 10:08:46.251 PDT >LOG: received smart shutdown request
< 2015-06-08 10:08:46.253 PDT >FATAL: terminating walreceiver process due to administrator command
< 2015-06-08 10:08:46.255 PDT >LOG: shutting down
< 2015-06-08 10:08:46.317 PDT >LOG: database system is shut down
Thanks for your help!
Regards,
ravi
________________________________________________________________________
The preceding e-mail message (including any attachments) contains
information that may be confidential, be protected by the
attorney-client or other applicable privileges, or constitute non-public
information. It is intended to be read only by the individual or entity
to whom it is addressed or by their designee. If you are not an intended
recipient of this message, please notify the sender by replying to this
message and then delete it from your system. You are on notice that
further use, dissemination, distribution, or reproduction of this
message is strictly prohibited and may be unlawful.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-06-08 17:33:17 | Re: [HACKERS] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Previous Message | Alvaro Herrera | 2015-06-08 17:23:32 | Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |