Re: BDR with Postgres

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: "Deole, Pushkar (Pushkar)" <pdeole(at)avaya(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: BDR with Postgres
Date: 2015-03-17 13:21:31
Message-ID: CAMsr+YEWE=2f=RQCVhFfPKSOk--FzjezcxNew6u7x0WzL8dKQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 17 March 2015 at 17:01, Deole, Pushkar (Pushkar) <pdeole(at)avaya(dot)com>
wrote:

> Hi,
>
>
>
> I just tried a POC with PostgreSQL’s streaming replication for the use
> case of my product. Since streaming replication is master-slave, when
> failover occurs there are some configuration changes required to promote
> slave to master.
>

repmgr can help here - see http://repmgr.org/ .

> Also, my requirement is to failback to old master again after the old
> master is started back (i.e. when old master is started back, it should
> become the master rather than the slave), which is bit tricky and is not
> straight forward to achieve without restarting any of the nodes.
>

You have to *resynchronise* the old master from the newly promoted master -
essentially, take a new base backup and overwrite the old master with the
new base backup from the newly promoted master.

Otherwise the old master won't have writes since the new master took over,
and that's ... well, bad. You'll also be unable to demote the new master to
follow the old master again, since it will have increased its timeline
specifically to prevent that.

Pg 9.4 adds wal_log_hints which permits the external pg_rewind extension to
do this re-syncing with less I/O and less work. Or you can enable checksums
(since 9.3). See
http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-wal_log_hints-for-consistent-relation-page-tracking/
.

> I am also evaluating BDR which is asynchronous master-master
> replication. Since both nodes will be master, I don’t need to worry about
> promoting slave to master etc. However, I have a query regarding adding a
> new node to the BDR. Suppose I have a BDR setup done with 2 nodes (Node1
> and Node2). Let’s assume node1 goes down. Node2 is up and running. I now
> add a new node say node3 and setup BDR with node2.
>
> In this scenario…
>
> 1. How does the initial data sync of node3 with node2 takes place?
>
If you use the bdr_init_copy command, by basebackup. If you use
bdr_init_replica via the config, it's done internally with a dump and
reload.

> 2. For node3 and replication data to/from node2, does node2 needs
> a restart or it is not required?
>
In 0.8.0 and older, adding a node requires a restart of all existing nodes.

This requirement no longer exists in the pending 0.9.0 release. However,
all nodes are expected to be up and reachable when you add a new node. Node
addition won't complete until they are. Allowing node addition while one or
more peers are down is not on the current roadmap. If you have a dead node
you must remove it before adding new nodes.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-general by date

  From Date Subject
Next Message jaime soler 2015-03-17 13:38:28 Re: pgpool + BDR, is it possible?
Previous Message Craig Ringer 2015-03-17 13:10:17 Re: BDR with Postgres