Nico Kadel-Garcia wrote: > On Fri, Sep 25, 2015 at 7:51 AM, Andreas Stieger <andreas.stie...@gmx.de> > wrote: > > Nico Kadel-Garcia wrote: > >> On Fri, Sep 25, 2015 at 4:37 AM, Andreas Stieger <andreas.stie...@gmx.de> > >> wrote: > >> > Nico Kadel-Garcia wrote: > >> >> On Thu, Sep 24, 2015 at 3:34 PM, Aaron Friesen <afrie...@spirae.com> > >> >> wrote: > >> >> > I have been tasked with setting up a mirror of several repositories > >> >> > with write-through back to the master. > >> >> > >> >> What is your engineering time worth? Wandisco publishes a very nice > >> >> multi-master setup that does precisely this, at > >> > > >> > Not "precisely", it's synchronous replication with a variant of Paxos. > >> > >> It's a more complete multi-master solution. The result is even better: > >> full high availability access with multiple Subversion servers, > >> synchronized write access to the core repository, and you don't have > >> to write the potentially fragile and split-brain prone hooks yourself. > > > > Yes. Synchronous replication. Paxos. Why repeat the definition? > > Because "Paxos" doesn't mean anything to most system admins who are > just starting out, and I wanted it clear for new mailing list members.
You made it appear like it's a "more complete" thing than what the terms describe. There is convenience for an alleged audience and there is skewing. > > Split-brain is an irrelevant consideration for a write-through asynchronous > > configuration. > > Until your primary master goes toes up, for whatever hardware or > software reason, or needs downtime for maintenance, and you wind up > having to manually switch around the services to link to a new > designated master, or lose all write access while the favored master > is offline. Unless ou're ready and able to take the old master > completely offline and never replace it, you than have to pull from > the new "master" to the old "master" to remain consistent. > > That can be.... difficult to avoid when you don't have complete > network control and can't trivially access the disabled previous > master to ensure that it stays read-only. It's also one of the very > classic problem of any master/slave database relationship. Swapping > the master and slave to provide full failover can be quite tricky and > error prone, and it's very easy to accidentally leave two masters live > with divergent histories. If you're able to do that manually, great! > Enjoy the benefits of your expertise and competence. > > For a new admin, the results of a mis-step or failure to fully > implement genuine high availability can be very expensive. Been there, > done that, got paid to clean up the problems, for various source > control systems and databases. You are re-iterating the problems around asynchronous replication. "Split-brain", however, is concerned with consensus in distributed coordination systems (here: global eventual sequence of applied transactions). So I do not see how your narrative can reasonably begin with "Until...", or how you can apply this term as a negative for Subversion's built-in *asynchronous* capabilities. I am under the impression that you keep pointing out the challenges in one method while mixing terms, counting it as a benefit for the other. Both have their benefits and costs and you seem to prefer one in particular. Andreas
