Unfortunately, speaking to jieyu this is not possible with the current Log implementation (a follower attempting a write will actually succeed and invalidate the leader's lock, causing the former leader to fall over). So a more fruitful approach may be to embed ZooKeeper in Aurora and optionally use that for leader election instead of an external cluster.
On Wed, Aug 19, 2015 at 3:18 AM, Florian Pfeiffer < [email protected]> wrote: > It seems like there's some movement in Mesos to get rid of Zookeeper / make > it replaceable: > https://issues.apache.org/jira/browse/MESOS-1806 > > With this it could (maybe maybe) make sense to drop ZK for leader election > (but then there's at least thermos announcment still around in ZK, isn't > it?) > > > On 18 August 2015 at 19:43, Maxim Khutornenko <[email protected]> wrote: > > > Do you see Aurora eventually getting rid of ZK dependency entirely? > > Given that Mesos still requires ZK, I doubt we would gain much by > > rejecting the existing standard for leader election and replacing it > > with a somewhat forced storage-driven implementation. > > > > Relying on a particular DB engine implementation to enforce leader > > election protocol may be too fragile/limiting. Some engines may not > > have full support for leader election primitives. From our previous > > experience dealing with mysql locks for example, the feature may not > > work as advertised or be severely version-impaired. > > > > >
