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 ?