[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Help needed: "glued" object.
--On Wednesday, April 03, 2019 4:36 PM -0300 Alex Hebra
<hebraalex@gmail.com> wrote:
Node A:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
Add an index for "reqDN" here as well.
#####
# primary db config
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 2000000
As I noted in the previous email, you want it slightly larger than the
total number of entries in the database. If you have exactly 2 million,
I'd probably set the session log to something like 2.1 million.
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
Depending on how busy the system is in regards to write ops, you may want
to "clean" the accesslog DB more frequently (I generally do 4 hour
increments). Otherwise the entire server can pause while the clean
operation is executed if there is a large amount of data that needs
deleting.
# Global section
serverID 1
I would note that the serverID should technically be one of the first lines
of the slapd.conf file since it is a global option. I can't really tell
from your snippets where it appears. ;)
Node B:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
Same comment as before about reqDN
syncprov-sessionlog 2000000
Same comment as before about the session log size.
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
Same comment as before as to the frequency of purging.
# Global section
serverID 2
Same comment as before about where this should be defined in the slapd.conf
file
After that I made a change on Node A and it replicated to node B, then I
made a change on node B and it replicated to A. So seems it's working. My
doubt is how can I make sure it's working with delta-sync mode?
If you have "stats" logging enabled, you can tell from the bind/search op
of the syncrepl client to the other master by looking at the search filter
and base in use of the default query.
Another question, changing to delta-sync can I use more than 2 nodes, for
instance, 3 servers receiving writing and replicating between them?
Delta-syncrepl is valid for N-way MMR, so yes, 3-way MMR is just fine.
One final note -- I don't know what overlays you have in use on your
servers, nor the order they are instantiated against the primary DB. This
was covered in a different thread yesterday, but on the primary DB, it must
be:
overlay syncprov
<syncprov overlay options>
overlay accesslog
<accesslog overlay options>
overlay WHATEVER
<options>
I.e., syncprov must be the first instantiated overlay, accesslog the second
instantiated overlay. All other overlays occurring after them.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>