Nico Kadel-Garcia wrote:
> On Fri, Sep 25, 2015 at 7:51 AM, Andreas Stieger <Andreas.Stieger_at_gmx.de> wrote:
> > Nico Kadel-Garcia wrote:
> >> On Fri, Sep 25, 2015 at 4:37 AM, Andreas Stieger <Andreas.Stieger_at_gmx.de> wrote:
> >> > Nico Kadel-Garcia wrote:
> >> >> On Thu, Sep 24, 2015 at 3:34 PM, Aaron Friesen <AFriesen_at_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
Received on 2015-09-25 14:50:48 CEST