Re: 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(dot)klaver(at)gmail(dot)com