Am I correct to understand from this page[0] that the consumer gets its 'new' contextCSN from the slapcat import. (I saw it in the file). And will get all data since that date at startup?
The replication id is of no influence. So if I would stop slapd import again the same old slapcat file. It would again receive all new data since that contextCSN? Regardless of the same rid being used with the provider.
The idea behind this is that if you create a container with a default imported slapcat/slapadd file. Every time the task is stopped and started. It will go back to it initial container state. (unless you make it statefull of course) I am not adding that much data so I could make a new default image every week or so, this would be used every time a container is launched. (which only happens in a failover situation)
I am not sure if this is true. Because it looks like provider and consumer are a bit to long on high load for the changes that were made.
-----Original Message----- Subject: Initial syncreplication details
Am I correct to understand from this page[0] that the consumer gets its 'new' contextCSN from the slapcat import. (I saw it in the file). And will get all data since that date at startup?
The replication id is of no influence. So if I would stop slapd import again the same old slapcat file. It would again receive all new data since that contextCSN? Regardless of the same rid being used with the provider.
The idea behind this is that if you create a container with a default imported slapcat/slapadd file. Every time the task is stopped and started. It will go back to it initial container state. (unless you make it statefull of course) I am not adding that much data so I could make a new default image every week or so, this would be used every time a container is launched. (which only happens in a failover situation)
--On Saturday, August 17, 2019 8:52 PM +0200 Marc Roos M.Roos@f1-outsourcing.eu wrote:
I am not sure if this is true. Because it looks like provider and consumer are a bit to long on high load for the changes that were made.
a) Don't use standard syncrepl, use delta-syncrepl
b) Don't use 2.4.44 with replication
c) If the slapcat contains a contextCSN, then it will be present on import. I.e., you need to slapcat from a server that already has replication enabled (generally best if it is a master)
d) Ensure that your export is younger than the expiry time on the accesslog database configuration for delta-syncrepl. I.e., if the accesslog keeps 1 week of changes, ensure what you're importing is less than a week old, etc.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Marc Roos -
Quanah Gibson-Mount