Slony1 PostgreSQL Replication - Master or Salave Down

Author

Master or Salave Down

Marcelo Michalek

2005-09-22, 8:25 pm

Hi! if I use Slony to replicate a Master/Slave config.
1) When the slave down and back it=B4s the slave automatic syncrhonized?
2) If the Master go dow, The Slave assumes as Master (automatic o
forced by me?) and when back it is synchronized?
Thanks
Marcelo

David Rees

2005-09-22, 8:25 pm

On 9/22/05, Marcelo Michalek <memichalek- Re5JQEeQqe8AvxtiuMwx
3w@public.gmane.org> wrote:
> Hi! if I use Slony to replicate a Master/Slave config.
> 1) When the slave down and back it=B4s the slave automatic syncrhonized?

Yes, the slave will catch back up automatically once it comes back up.

> 2) If the Master go dow, The Slave assumes as Master (automatic o
> forced by me?) and when back it is synchronized?

The switchover process is a manual one. The master/slave will be
synchronized when done.

-Dave

Christopher Browne

2005-09-22, 8:25 pm

Marcelo Michalek wrote:

>Hi! if I use Slony to replicate a Master/Slave config.
>1) When the slave down and back it=B4s the slave automatic syncrhonized?
> =20
>
Yes, when the slon assigned to that node can one again access both
databases, it will bring the subscriber up to date, no problem.

>2) If the Master go dow, The Slave assumes as Master (automatic o
>forced by me?) and when back it is synchronized?
> =20
>
No, that is definitely NOT how things work.

If the origin node is taken down, and you want to promote some other
node to take over, you would have to submit a FAILOVER request (see docs
here... <http://linuxfinances.info/info/failover.html> ).

At that point, the former origin is discarded, and could not be brought
back without initializing it as a fresh node and subscribing it to the
replication set(s).

The fact that it requires discarding and reinitializing the failed node
makes FAILOVER a pretty undesirable operation.

Ujwal S. Setlur

2005-09-22, 8:25 pm

>=20
> The fact that it requires discarding and
> reinitializing the failed node
> makes FAILOVER a pretty undesirable operation.

I have heard this mentioned a few times now, and I
have always wondered about it...

While replication has many uses such as back-up and
disaster recover, failover is IMHO also a legitimate
use. Nobody wants it to have happen, of course, but it
will and does. In fact, I consider failover as part of
disaster recovery.

So what does "undesirable operation" actually mean?

Ujwal

Christopher Browne

2005-09-22, 8:25 pm

Ujwal S. Setlur wrote:

>
>I have heard this mentioned a few times now, and I
>have always wondered about it...
>
>While replication has many uses such as back-up and
>disaster recover, failover is IMHO also a legitimate
>use. Nobody wants it to have happen, of course, but it
>will and does. In fact, I consider failover as part of
>disaster recovery.
>
>So what does "undesirable operation" actually mean?
>
>
It is a "last resort" for two reasons:

1. You may LOSE DATA, because any updates that have been committed on
the origin node but which have not yet been replicated to another node
will be lost.

This is a particularly bad thing if your applications have, on the basis
of the COMMIT on the origin, reported business transactions as COMMITted
to outside customers.

2. Node abandonment. After you perform...

FAILOVER (id = 1, backup node = 2)

the node which was formerly the origin must be ABANDONED as far as
replication is concerned.

The failed node cannot be brought back into replication without
reinitializing it from scratch as a fresh, new Slony-I node, which
involves deleting all the data and setting up a subscription to one or
another of the nodes that had survived.

If you can get the database back up and accessible long enough to run
MOVE SET, neither of these problems need to occur.

If the disaster is "bad enough," failover is absolutely legitimately usable.

But you have to be prepared to accept both of the above caveats.

Marcelo Michalek

2005-09-23, 11:24 am

DB1 (Master) DB2 (Slave)
down
----- promote DB2 (Master) (Lost the last
commited
transactions)
Master Back
DB1 (Slave) <------------------ DB2 (Master)
reinitializing from scratch
promote as Master again (clean process)
DB1 (Master) DB2 (Slave)

Is it OK?

So, there is no way to promote again the first Master without a
complete reconstruction of the database from scratch (not from Check
Point or somthing like that)
There are other replication tool that make this?

Saludos desde Argentina
Best Regards from Argentina
Thanks
Marcelo

2005/9/22, Christopher Browne <cbbrowne-swQf4SbcV9C7WVzo/KQ3Mw@public.gmane.org>:
> Ujwal S. Setlur wrote:
>
> It is a "last resort" for two reasons:
>
> 1. You may LOSE DATA, because any updates that have been committed on
> the origin node but which have not yet been replicated to another node
> will be lost.
>
> This is a particularly bad thing if your applications have, on the basis
> of the COMMIT on the origin, reported business transactions as COMMITted
> to outside customers.
>
> 2. Node abandonment. After you perform...
>
> FAILOVER (id =3D 1, backup node =3D 2)
>
> the node which was formerly the origin must be ABANDONED as far as
> replication is concerned.
>
> The failed node cannot be brought back into replication without
> reinitializing it from scratch as a fresh, new Slony-I node, which
> involves deleting all the data and setting up a subscription to one or
> another of the nodes that had survived.
>
> If you can get the database back up and accessible long enough to run
> MOVE SET, neither of these problems need to occur.
>
> If the disaster is "bad enough," failover is absolutely legitimately usab=
le.
>
> But you have to be prepared to accept both of the above caveats.
> ____________________
____________________
_______
> Slony1-general mailing list
> Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
> http://gborg.postgresql.org/mailman.../slony1-general
>

Christopher Browne

2005-09-23, 11:24 am

Marcelo Michalek <memichalek- Re5JQEeQqe8AvxtiuMwx
3w@public.gmane.org> writes:
> DB1 (Master) DB2 (Slave)
> down
> ----- promote DB2 (Master) (Lost the last
> commited
> transactions)
> Master Back
> DB1 (Slave) <------------------ DB2 (Master)
> reinitializing from scratch
> promote as Master again (clean process)
> DB1 (Master) DB2 (Slave)
>
> Is it OK?

That appears to describe how things would work, yes.

> So, there is no way to promote again the first Master without a
> complete reconstruction of the database from scratch (not from Check
> Point or somthing like that) There are other replication tool that
> make this?

Feature request #1389 outlines a "clone a database" approach which
should in principle speed up the reconstruction.

http://gborg.postgresql.org/project...update.php?1389

I probably won't have time to work on that until November...
--
output = ("cbbrowne" "@" "ca.afilias.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)

Jan Wieck

2005-09-26, 9:23 am

On 9/23/2005 12:03 PM, Christopher Browne wrote:

> Feature request #1389 outlines a "clone a database" approach which
> should in principle speed up the reconstruction.

Did anyone actually do some timing tests with the bulk index build after
copying the data? I am not sure that there is that much more to gain.

Jan

--
#===================
====================
====================
===========#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#===================
====================
=========== JanWieck- bwPqjjyvM7QAvxtiuMwx
3w@public.gmane.org #

Sponsored Links