Question about migration 2.2 - 2.3 with replication
Do both replication nodes need to be updated at the same time?
Or can a 2.2(.36.4) node replicate with a 2.3(.10.1)?
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
Am 30.07.20 um 23:02 schrieb Ralf Becker:
Do both replication nodes need to be updated at the same time?
Or can a 2.2(.36.4) node replicate with a 2.3(.10.1)?
Ralf
In case someone's looking here for an answer about 2.2 to 2.3 update with replication and directors:
- I first updated the directors, for which I run into the documented problem with consistent hashing:
- docu says you can NOT run a director rind with different settings for consistent hashing (director_consistent_hashing)
- I thought because I have nothing configured explicit, I wont be affected, but that is wrong, as the default changed and therefore you are!
- to keep the director ring running, you have to explicitly configure consistent hashing under 2.2 (I scaled down our K8s director service to 1 and reloaded that director, maybe you can also reload multiple directors at the same time, I have not tried that)
- then you need to remove the director_consistent_hashing and update your directors one by one I also had to fix a couple of changed config settings eg. ssl_protocols-->ssl_min_protocol
- replicating backends: I updated one of the backends to 2.3 and it started replicating with the old backend. I only been in that situation for a couple of minutes (at night) before I updated the second backend to 2.3.
So far the only thing we noticed: private seen flags on shared user folders (which were never supported for replication!) seem to be not functioning any more in 2.3. Not functioning means, if they are configured you can not set a mail to seen in a shared user folder. After removing this configuration:
location = mdbox:%%h/mdbox:INDEXPVT=~/shared/%%u --> mdbox:%%h/mdbox
seen flags behave as expected / are identical now if you access the mailbox direct or via the shared user folder, and the are identical on both backends.
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
participants (1)
-
Ralf Becker