Is there any way to get a master to divulge the rid of each slave that is using it to keep in sync?
--On Thursday, March 28, 2013 2:11 PM -0500 Sven Jourgensen svenj@uic.edu wrote:
Is there any way to get a master to divulge the rid of each slave that is using it to keep in sync?
No, the whole point of the design is that the provider does not need to know anything about the replicas. Also, RID is entirely internal to the replica. I.e., the only requirement is that if a replica has multiple RIDs in its configuration, they are all unique inside that singular replica. I.e., if you have 500 replicas, they can all use the same RIDs as one another, as long as they remain unique inside the given replicas.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Am I understanding your correctly?
If I have a single provider (master) and 20 replicas (slaves) I can set the rid to 42 on all the replicas and they will maintain sync?
There is no need to keep the rid unique on each replica using the same provider?
On Thu, 28 Mar 2013, Quanah Gibson-Mount wrote:
--On Thursday, March 28, 2013 2:11 PM -0500 Sven Jourgensen svenj@uic.edu wrote:
Is there any way to get a master to divulge the rid of each slave that is using it to keep in sync?
No, the whole point of the design is that the provider does not need to know anything about the replicas. Also, RID is entirely internal to the replica. I.e., the only requirement is that if a replica has multiple RIDs in its configuration, they are all unique inside that singular replica. I.e., if you have 500 replicas, they can all use the same RIDs as one another, as long as they remain unique inside the given replicas.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
You are understanding correctly.
The rid is useful and unique only internally the node.
No other nodes know the rid being used by other nodes.
- chris
----- Original Message ----- From: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Sent: Thu Mar 28 12:48:12 2013 Subject: Re: rid tracking
Am I understanding your correctly?
If I have a single provider (master) and 20 replicas (slaves) I can set the rid to 42 on all the replicas and they will maintain sync?
There is no need to keep the rid unique on each replica using the same provider?
On Thu, 28 Mar 2013, Quanah Gibson-Mount wrote:
--On Thursday, March 28, 2013 2:11 PM -0500 Sven Jourgensen svenj@uic.edu wrote:
Is there any way to get a master to divulge the rid of each slave that is using it to keep in sync?
No, the whole point of the design is that the provider does not need to know anything about the replicas. Also, RID is entirely internal to the replica. I.e., the only requirement is that if a replica has multiple RIDs in its configuration, they are all unique inside that singular replica. I.e., if you have 500 replicas, they can all use the same RIDs as one another, as long as they remain unique inside the given replicas.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
--On Thursday, March 28, 2013 2:48 PM -0500 Sven Jourgensen svenj@uic.edu wrote:
Am I understanding your correctly?
If I have a single provider (master) and 20 replicas (slaves) I can set the rid to 42 on all the replicas and they will maintain sync?
There is no need to keep the rid unique on each replica using the same provider?
That is correct, you can use the same RID on all 20 replicas.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org