On Mon, 20 Jun 2016 at 3:36pm, Frank Swasey wrote:
I do make some modifications to the codebase, but have never [changed
auditContext from being DSA]. I'll double check the patch decks to
make sure something did not match and mess that attribute up
unintentionally.
I have confirmed that my code modifications have not changed the
auditContext attribute's definition, it is still "Usage
directoryOperation".
To further complicate the matter, I have pointed my delta-syncrepl slave
consumer at a different MMR configured master and it replicates from
empty just fine. That second MMR configured master is actually a VMware
clone of the one of the two test MMR systems and is identical in all
respects except the slapd configuration (it is paired with my current
non-MMR production master). This leads me to believe it is either
something I've managed to mess up in the configuration of the testing MMR
pair, or it is because the base dn in the testing MMR pair has multiple
contextCSN values (for serverid's 0, 1, and 2) and (so far) the
production setup still has a single contextCSN value.
So, let me back up a few feet and make sure I am not setting myself up
for ultimate failure when I complete the migration of my production
environment to a full MMR master pair with delta-syncrepl slaves.
My plan is that I will have two systems which are configured as MMR, so
that should a datacenter fail, I can (manually) fail-over the service ip
address to the surviving datacenter and continue operation with LDAP
updates. I also will have six read-only delta-syncrepl slaves to carry
the workload of approximately 20 million queries per day.
I did not think that using MMR for the master server would preclude
having delta-syncrepl slaves, and I find no discussion in my googling to
indicate either way.
Have I made a bad design?