The version is 2.4.23, the config is the same across all the slaves, including the ones that stay in sync under load, the hardware itself is more than capable, I'm curious however to your clock comment, would an unstable clock on the slave cause the contextCSN token to be out of whack?
Hence me asking rather how the contextCSN is generated and passed from master to slave, rather than, here's all my configs fix it for me.
SJ
On Wed, 10 Oct 2012, Quanah Gibson-Mount wrote:
--On Wednesday, October 10, 2012 11:07 AM -0500 Sven Jourgensen svenj@uic.edu wrote:
I have an odd issue, where I have some new slaves that I added to my pool, they ran fine sync'ing with the master, etc. for weeks, until I added them into use (we're using an F5 frontend) whereupon they started getting a contextCSN which was larger than that of the master.
How is the contextCSN generated, I thought the slave could never get ahead of the master, but it's happening consistently, it's not a transient thing, the slave gets a larger contextCSN and keeps it, until the master is updated again.
master: contextCSN: 20121010154339.775633Z#000000#000#000000 slave1: contextCSN: 20121010154442.858054Z#000000#000#000000 slave2: contextCSN: 20121010154351.807575Z#000000#000#000000
As soon as I remove them from use, and update the master, they come back into sync.
OpenLDAP version? Configs for master and replicas? Have you verified that the clocks on all 3 servers are in sync?
--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