I've nearly incorporated all of the information you fine folks have
provided, at least as far as common usage scenarios go, into the docs.
One final gap remains in my knowledge...
I have the impression that a replica can be set up to have a subset of
all the users/mailboxes of a master. Have I mi
On Fri, Jul 24, 2015, at 18:29, Michael Menge wrote:
> One possible problem I am seeing is that after a split brain, or
> switch of primary and replica for some users there might be some
> problems for renamed folders, subsciptions and folder annotations.
> Cyrus is able to handle changes on both s
On Thu, Jul 23, 2015, at 23:42, Nic Bernstein wrote:
>
This raises potential problems when one deploys replication within a
murder (Cyrus aggregation). Only one server may claim ownership of
any given mailbox, via a mupdate call, so an instance which is a
replica MAY NOT push updat
(sorry, started this while in the USA and forgot to come back to it)
On Thu, Jul 23, 2015, at 16:14, ellie timoney wrote:
> Here's my understanding, and my understanding is limited and probably
> incorrect, so I'd appreciate corrections from anyone who actually
> knows this stuff.
>
> > Do we have
On 07/24/2015 12:07 AM, ellie timoney wrote:
- a single cyrus instance may be the primary server for some
users but a replica server for other users
Are you sure about that?
I'm not sure about any of this. But you make a good point: I
thought I could see a way
Hi,
Quoting ellie timoney :
- a single cyrus instance may be the primary server for some users
but a
replica server for other users
Are you sure about that?
I'm
not sure about any of this. But you make a good point: I thought I
could see a way that this was possible, but now I don't
Hi,
Quoting ellie timoney :
Okay, I'll bite. Here's what a bit of a sync_log looks like:
Thanks! So anything processing a sync_log (sync_client, squatter, etc)
needs to look at an actual copy of the user/mailbox in order to
determine its current state, and needs to look at both copies
>>> - a single cyrus instance may be the primary server for some users
>>> but a
replica server for other users
>> Are you sure about that?
>
> I'm
not sure about any of this. But you make a good point: I thought I
could see a way that this was possible, but now I don't think I can.
I think I
> Okay, I'll bite. Here's what a bit of a sync_log looks like:
Thanks! So anything processing a sync_log (sync_client, squatter, etc)
needs to look at an actual copy of the user/mailbox in order to
determine its current state, and needs to look at both copies to work
out what to replicate b
On 07/23/2015 01:14 AM, ellie timoney wrote:
Is the file format of the sync log defined anywhere? I assume it
>correlates with a set of commands. (Not that this is important to a
>user: it may as well be opaque, but it made me wonder!)
I'm a bit confused about this myself. Each time I go diggin
Another quick reply, in case it wasn't clear from my last, that it
sounds like your understanding of the purpose of sync_client and
sync_server are neatly reversed:
> Do we have multiple sync_clients because a new one is spawned by a
> master for each change (and then the process finishes), or is
Here's my understanding, and my understanding is limited and probably
incorrect, so I'd appreciate corrections from anyone who actually knows
this stuff.
> Do we have multiple sync_clients because a new one is spawned by a
> master for each change (and then the process finishes), or is there an
>
Hi Cyrus,
I'm currently working on some basic architecture diagrams that will
complement the documentation to show the moving parts. Today's topic:
replication.
Based on a delightfully drawn whiteboard session with Bron, I am left
with a couple of queries:
Do we have multiple sync_clients becaus
13 matches
Mail list logo
