sync_log_chain - is it always needed?

[ellie timoney]

On Wed, Apr 29, 2020, at 1:12 AM, Olaf Frączyk wrote:
> I was wondering why do we need to use this option on middle servers in 
> replication chain?

When a user/delivery/admin/etc action happens on a mailbox/user/etc, an entry is recorded in the sync log saying that something has happened to that mailbox/user/etc, and that it will need to be checked and replicated at some point.

sync_client in rolling mode (or log-replay mode) reads that sync log, and for each mailbox/user/etc that the sync log reports as having been changed, it compares its current state against the replica, and updates the replica to match if necessary.

When a change arrives by replication, it is NOT logged to the sync_log -- unless sync_log_chain has been enabled.

So if you want a rolling replication arrangement such that Master -> Replica1 -> Replica2, then Replica1 _must_ have sync_log_chain enabled, otherwise there will never be anything in its sync log, and it will therefore never forward the replications on to Replica2.  This arrangement has the advantage that Master only needs to do one replication (and can focus its energy on servicing clients instead), but the disadvantage that the state on Replica2 will not be as fresh as the state on Master or Replica1.

But if you want an arrangement such that Master -> Replica1 and Master -> Replica2, then you don't need sync_log_chain anywhere.  This arrangement has the disadvantage that Master must do more replication work, but the advantage that Replica1 and Replica2 are more likely to both be up-to-date at any given moment.

> I don't use sync_server. The replication is done using IMAP protocol. Is 
> in this case this setting also necessary?

It makes no difference; replication is replication.  The replication support in imapd is a thin wrapper around the exact same implementation as used by sync_server.

> Shouldn't the middle server catch all changes that are done via IMAP 
> protocol and forward them to the next server in the replication chain?

The changes are not done "via IMAP protocol", they are done "via replication protocol, over an IMAP connection".  For example, you couldn't use Cyrus replication to update some other non-Cyrus IMAP server -- it would not understand the replication commands.

If you want a chained configuration, then you need sync_log_chain, regardless of whether you use imapd or sync_server.

> BTW. Does anyone has some description how sieve scripts replication is 
> done via IMAP protocol?

Can you clarify what you want to know here?  It's replicated the same way as it would be to sync_server:

The sync_client queries the replica's state, decides whether it needs updating, and if so, then it sends the new state, and checks for an OK response from the replica.

Depending on the Cyrus version of your master server, it might (in older versions) try to send both the sieve script file and the compiled bytecode file; or (in recent versions) just the script file.

Depending on the Cyrus version of your replica servers, it might accept and update a bytecode file as-is; or (in recent versions) simply accept and ignore it, and recompile the bytecode on demand from the script file that was also sent.

If, for some reason, you're replicating from a recent version (that only sends the script file) to an old version (that expects both), then your replica will not have up to date compiled bytecode.  If your replica needs to be brought into service taking real traffic, you will first need to manually (re)compile all your scripts using sievec.  This is almost certainly not the only quirk of replicating to an older server and then trying to run it with real traffic, so try to not need to do that! :)

It's not safe/possible to run bytecode on one Cyrus version that was compiled by a different Cyrus version, which is why in recent versions we do not bother to replicate bytecode at all.  Recent Cyrus versions instead have a mechanism to recompile bytecode on demand if it's missing, out of date, or the wrong version, so that you will always be running the correct, up-to-date bytecode for the current Cyrus version for the current contents of the script.

Regardless of your Cyrus version, the state of "which script is currently activated for the user" is also replicated in the same way.

Hope this helps,

ellie