--On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain jephte.clain@univ-reunion.fr wrote:
No. Replicas do not accept writes. Replicas do not have a master configuration for cn=config. Replica's do not have server IDs.
ok I guess I understand. this is the reason why I usually call them "slaves", not replicas (but I messed things up and called them replicas this time ^^) I also have replicas that only replicate data (or a subset of data) for some services
No. The terms replica and slave are interchangeable. As are master and provider. Given the very negative connotations of the concept of masters and slaves, the preferred terms are "provider" instead of "master" and "replica" instead of "slaves".
the slaves are there in case of catastrophic failure of both masters (we had one of these failure for another service due to a problem with the shared storage. No one want to have this kind of emergency...) If the master(s) crash, I just have to choose a slave as the new master, slapcat the cn=config database, update the provider address, slapadd the updated config, and update the loadbalancer settings. this is a bit of work but at least we can restore service in a (relatively) small amount of time.
If they accept writes, they are not slaves/replicas. If you are replicating cn=config across all the systems, then they must all be masters. Your general description above sounds like you do not correctly understand how MMR functions.
Accesslog is unique to a given master.
Ok that's what I wanted to know for sure
Shouldn't the doc stat this clearly?
Please file an ITS noting the docs should be updated on this point.
Thanks a lot for the clarification. In case you come to the reunion island someday, I owe you a beer!
:)
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration