[Date Prev][Date Next]
Re: what databases are to be replicated for a slave?
--On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain
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
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
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!
Zimbra :: the leader in open source messaging and collaboration