Howard Chu a écrit :
Guillaume Rousse wrote:Hello list. I'm using delta-syncrepl in search-and-persist mode between my slaves and my master server. And I'm using a nagios plugin to check sync status, based on value of contextCSN attribute. But I'm often sync alerts for unknown reasons. First issue, is this an expected result to have an higher contextCSN on the slave side ? From what I've understood from contextCSN, this attribute is updated each time a write operation is performed on the server. As the slave server is not supposed not to perform any write operation, this should never happens. However, it does:Ordinarily, a slave cannot initiate any write operations. However, you appear to be using ppolicy. The ppolicy overlay writes Bind status updates to the local server, regardless of master or slave status. Thus, it can cause the slave's contextCSN to be newer than the master's.
OK, I guess it means higher CSN reports on slave side can be discarded.I suggest adding your answer to section 18.1.1.2. (Syncrepl Details) of the Admin guide, with a few modifications.
Ordinarily, a consumer cannot initiate any write operations. However, some specific overlays may bring exceptions to this rule. For instance, the ppolicy overlay writes Bind status updates to the local server, regardless of its master or slave status. Thus, it can cause the consumer's contextCSN to be newer than the provider's.
Also, you didn't answer to my second question: syncrepl is also supposed to sync operational attributes. Does ppolicy also constitute an exception here ?
-- BOFH excuse #217: The MGs ran out of gas.