<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div style="font-family:Arial;"><br></div><div style="font-family:Arial;"><br></div><div>On Sun, Apr 5, 2020, at 00:45, Olaf Frączyk wrote:<br></div><blockquote type="cite" id="qt"><div style="font-family:Arial;">Hello,<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">1. Is currently master-master replication possible (maybe 3.2) Is it OK <br></div><div style="font-family:Arial;">to sync them two-way?<br></div></blockquote><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">No, not really. It'll mostly be fine, but it doesn't (yet) handle folder create/rename/delete safely.<br></div><div style="font-family:Arial;"><br></div><blockquote type="cite" id="qt"><div style="font-family:Arial;">If yes - how to set up such config?<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">2. If master-master is impossible, is there any guide how to setup <br></div><div style="font-family:Arial;">failover from master to slave and possibly back? If split-brain happens <br></div><div style="font-family:Arial;">- is there an easy recovery from such state?<br></div></blockquote><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">The way we do it at Fastmail is with an nginx proxy in front which knows which one is the master. For a clean shutdown, we shut down the master, then run sync_client -r -f with the log file (if anything was unreplicated) to make sure it's up to date, then shut down both and bring them up with the config pointing the replication the other way.<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">For a case where the master crashed hard, we switch the replica to be master by changing the config (with a restart again) then bring the old master back up and for sync_client everything again like above to switch back, so all new changes from the regular replica are back on the regular master. Then we bring up the regular master as master again, and run sync_client -A from there to replicate all remaining changes. That mostly works.<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">The plan in 3.4+ is to use the mailbox tombstone records to get the create/rename/delete to the same level of split-brain safety as the UIDs inside the mailbox have.<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">Cheers,<br></div><div style="font-family:Arial;"><br></div><div style="font-family:Arial;">Bron.<br></div><div id="sig567075"><div>-- <br></div><div> Bron Gondwana<br></div><div> brong@fastmail.fm<br></div><div><br></div></div><div style="font-family:Arial;"><br></div></body></html>