[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>