Re: synchronous replication: blocking commit on the master
| От | Jameison Martin |
|---|---|
| Тема | Re: synchronous replication: blocking commit on the master |
| Дата | |
| Msg-id | 1330453334.24279.YahooMailNeo@web39406.mail.mud.yahoo.com обсуждение исходный текст |
| Ответ на | Re: synchronous replication: blocking commit on the master (Adrian Klaver <adrian.klaver@gmail.com>) |
| Ответы |
Re: synchronous replication: blocking commit on the master
(Fujii Masao <masao.fujii@gmail.com>)
|
| Список | pgsql-general |
i don't think i've explained things very clearly. the implied contradiction is that i'd be using asynchronous replication to catch up a slave after a slave failure and thus i'm losing the transactional consistency that i suggest i need. if a slave fails and is brought back on line i am indeed proposing that it catch up with the master asynchronously; however, the slave wouldn't be promoted to a hot standby until it is completely caught up and could be reestablished as a synchronous replica (at least that is what i'd like to do in theory). so i'm proposing that a slave would never be a candidate for a HA failover unless it is completely in sync with a master: if there is no slave that is in sync with the master at the time the master fails, then the master would have to be recovered from the filesystem via traditional recovery. the fact that i envision 'catching up' a slave to a master using asychronous replication is not particularly relevant to the transactional guarantees of the system as a whole if the slave is effectively unavailable while catching up.
similarly, any slave that isn't caught up to its master would also not be eligible for queries.
i can understand why the master might hang when there is no reachable replica during synchronous commit, this is exactly the right thing to do if you want to guarantee that you have at least 2 distinct spheres of durability. but i'd prefer to sacrifice the extra durability guarantee in favor of availability in this case given that recovery from the file system is still an option should the master subsequently fail. my availability issue is that the master would clearly be hung/unavailable for an unbounded amount of time without a strong guarantee about the time it might take to bring a replica back up which is not acceptable in my case.
if the master hangs commits because there is no active slave, i believe that an administrator would have to
- detect that there are no active slaves
- shut the master down
- disable synchronous replication
- bring the master back up
or, alternatively:
- detect that there are no active slaves
- interrupt any connections that are blocking on commit
- set synchronous_replication = local or off on all connections, effectively disabling synchronous replication going forward
i envision some kind of time out after which the slave is removed from the master's synchronous replica set. and of course i'd need to work out the mechanics of bringing the slave back up to sync with the master and adding it back to the replica set, which would clearly require some additional machinery.
i hope that clears it up.
thanks.
From: Adrian Klaver <adrian.klaver@gmail.com>
To: Jameison Martin <jameisonb@yahoo.com>
Cc: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Sent: Tuesday, February 28, 2012 7:32 AM
Subject: Re: [GENERAL] synchronous replication: blocking commit on the master
On Monday, February 27, 2012 10:21:24 pm Jameison Martin wrote:
> I have specific needs for wanting synchronous replication instead of
> asynchronous replication, notwithstanding my desire to continue processing
> work on the master if there are no active slaves. I would like to use
> replication for both HA and for query scaling. I'd like replication to be
> synchronous to ensure that any slaves are up to date, and I cannot afford
> even the small data potential loss implied by asynchronous replication.
> However, should there be a situation where no slaves are alive (e.g.
> there is a single slave and it fails for whatever reason), I do not want
> to compromise the availability of the master while the slave is being
> restored. Instead, I'd like to be able to continue processing transactions
> on the master unimpeded until a slave can be brought back online. Once a
> slave is caught back up to the master I'd like to switch back to
> synchronous replication and again be able to use the slave to scale reads
> and as a failover target should the master fail.
>
> Does that make sense?
No not really:)
The two statements below seem to be at odds with each other:
"I'd like replication to be synchronous to ensure that any slaves are up to
date, and I cannot afford even the small data potential loss implied by
asynchronous replication."
"Instead, I'd like to be able to continue processing transactions on the master
unimpeded until a slave can be brought back online."
It seems you want async sync replication and, under the observation that a chain
is only as strong as its weakest link, you are really getting async replication.
That being said, it is your set up and you have the options to have it run the
way you want.
--
Adrian Klaver
adrian.klaver@gmail.com
В списке pgsql-general по дате отправления:
Предыдущее
От: Andy ColsonДата:
Сообщение: Re: strategies for dealing with frequently updated tables