2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount quanah@zimbra.com:
--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".
Aaargh, now I can't help thinking about "providers" whipping "replicas". slapd can be so cruel sometimes :-)
And in case you wonder, here in reunion island we have a (relatively) long history of slavery. We even have a day to commemorate abolition of slavery: december 20th
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.
OK... I finally understand what was bothering you My replicas do _not_ accept writes. Sorry to have let you think so
I have two setups: - a "legacy" one, with one master accessible to the applications that can write, and two complete replicas (data + cn=config) behind a loadbalancer for the reads. One of these replicas could become the new master if the needs arise. And there are a bunch of partial replicas (only a subset of data) for some specific services. The reason is on our vmware farm, network access is regularly cut (don't know why, the system guy neither), and these services cannot reconnect on their own... piece of #$*! software :( - a "new" one, with two masters in mirror mode (only one get the writes at anytime thanks to the loadbalancer), and two replicas (only data) which get all the reads. I feel like configuring chaining to be able to write from the replicas, but I have no experience of the benefits of this configuration...
I have read the admin guide several times, but I am open to any suggestion to improve my skills
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.
Ok. I may even provide a patch. I'll do it tomorrow.
Have a nice day/night (don't know where you live ^^) Regards, Jephté
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.
Ok. I may even provide a patch. I'll do it tomorrow.
http://www.openldap.org/its/index.cgi?findid=8344
--On Wednesday, December 30, 2015 11:01 PM +0400 Jephte Clain jephte.clain@univ-reunion.fr wrote:
- a "new" one, with two masters in mirror mode (only one get the
writes at anytime thanks to the loadbalancer), and two replicas (only data) which get all the reads. I feel like configuring chaining to be able to write from the replicas, but I have no experience of the benefits of this configuration...
Why not just make them all providers? You can pretend the two that aren't behind the master URL are replicas and direct read traffic to them, and if they do happen to get a write, the correct steps will occur, with no need to set up chainging at all.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org