Hi Paul, On Tue, 25 Jun 2024, at 4:42 PM, [email protected] wrote: > I noticed the replication feature is in the configure script is still flagged > as experimental; is that still valid? > > --enable-replication enable replication support (experimental)
Yeah wow, good catch. I don't think so! I've created https://github.com/cyrusimap/cyrus-imapd/pull/4948 to get that experimental label removed. > Even so, I've been using replication for quite some time on various > platforms, ever since it was experimental ;-) I typically use it to migrate > between major versions even. Yeah, it's our recommended upgrade path, so it's a bit embarrassing that we're still calling it experimental... > And I even experimented with doing bi-directional replication. (Of which I'm > not entirely sure what the official status is, but in simple deployments it > seemed to work.) It has some smarts for this, but they're meant to deal with cases like: your primary went down, so you reconfigured a replica as the new primary, then fixed the former-primary and brought it back up as a replica. But there were changes on the former-primary that didn't replicate out before it went down, and there's new changes on the current primary that the former-primary hasn't seen yet. Replication will generally handle that okay, bringing the former-primary and the current primary forward to a single state where both sets of changes coexist. But it's not suitable for a deployment where you want to have two primary servers (i.e. two servers serving client traffic) sharing data between each other. The split brain recovery handling might allow this to mostly work in small and carefully controlled circumstances, but that's a coincidence, not a feature. Cheers, ellie ------------------------------------------ Cyrus: Devel Permalink: https://cyrus.topicbox.com/groups/devel/T0f354b019bc535c8-M59653f08d20514c6794e0dc1 Delivery options: https://cyrus.topicbox.com/groups/devel/subscription
