Hi
I have been using replication since long time without any issues (and still without issues), but on recent versions I got this warning on the logs:
syncprov_setup_accesslog: couldn't get definition for attribute reqType, is accesslog configured?
The answer is no, I never configured accesslog (this why I'm a bit confused, as I never used/needed on my replication setup). After reviewing the documentation I understand that for syncrepl I should load and configure accesslog overlay.
Although I have some questions/concerns I haven't been able to found/understand from the documentation and would like someone clarifies:
* Is there any way to implement replication without accesslog? (currently I have it but I would like to not get that warning)
* If I setup accesslog, do I need to setup a different accesslog DIT for each target DIT I replicate? Or can a single accesslog be shared with 2 different target DITs?
I mean: I'm currently replicating both cn=config (dynamic configuration) and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a different accesslog DIT for each one or can they share the same DIT as accesslog ?
* Does this log DIT needs to be backup up or is simply a log which I could get rid of in case of recovery?
Any comments, hints or simply answers are welcome
Thanks
On Mon, Jan 29, 2024 at 10:23:10AM +0100, Marc Franquesa wrote:
Hi
I have been using replication since long time without any issues (and still without issues), but on recent versions I got this warning on the logs:
syncprov_setup_accesslog: couldn't get definition for attribute reqType, is accesslog configured?
Hi Marc, are you running with syncprov-reloadhint by any chance? It's just a warning that syncprov might consider using the attribute but it's not defined. I've just moved the check to syncprov-nopresent[0] which doesn't really have any uses without an accesslog DB being around.
The answer is no, I never configured accesslog (this why I'm a bit confused, as I never used/needed on my replication setup). After reviewing the documentation I understand that for syncrepl I should load and configure accesslog overlay.
Although I have some questions/concerns I haven't been able to found/understand from the documentation and would like someone clarifies:
- Is there any way to implement replication without accesslog? (currently I
have it but I would like to not get that warning)
No need for accesslog if you're doing plain syncrepl.
- If I setup accesslog, do I need to setup a different accesslog DIT for
each target DIT I replicate? Or can a single accesslog be shared with 2 different target DITs?
Yes, for delta-MPR you need separate accesslog per DB.
I mean: I'm currently replicating both cn=config (dynamic configuration) and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a different accesslog DIT for each one or can they share the same DIT as accesslog ?
deltasync is not all or nothing, each DB can be set up separately (and AFAIK people don't usually do deltasync for cn=config).
- Does this log DIT needs to be backup up or is simply a log which I could
get rid of in case of recovery?
Unless you're using it for auditing purposes, you just have to make sure to either: - backup and restore both DBs from the same exact version - or not restore accesslog (and wipe it on main DB restore)
[0]. https://git.openldap.org/openldap/openldap/-/merge_requests/677
Regards,
Missatge de Ondřej Kuzník ondra@mistotebe.net del dia dt., 30 de gen. 2024 a les 16:19:
are you running with syncprov-reloadhint by any chance? It's just a warning that syncprov might consider using the attribute but it's not defined. I've just moved the check to syncprov-nopresent[0] which doesn't really have any uses without an accesslog DB being around.
You're right, I realized that I had the Reloadhint setting to true. Once disabled my issue has gone. Thanks much for pointing.
No need for accesslog if you're doing plain syncrepl.
Well, I wanted to use delta-syncrepl, but the small size and changes on my DIT didn't require it, so I kept as is
AFAIK people don't usually do deltasync for cn=config).
Make sense.
This bring me a new question (which I think I already get replied or found in some place but now I'm unable to find)
On a multiple replica setup (N-way Multimaster) setup, how does the server identify itself in the multiple olcSyncrepl attributes to avoid trying to replicate against itself ?
Thanks much
On Mon, Feb 05, 2024 at 10:51:03AM +0100, Marc Franquesa wrote:
This bring me a new question (which I think I already get replied or found in some place but now I'm unable to find)
On a multiple replica setup (N-way Multimaster) setup, how does the server identify itself in the multiple olcSyncrepl attributes to avoid trying to replicate against itself ?
Hi Marc, the main mechanism is that syncrepl stanzas where provider matches one of our configured URIs are not activated. And since you need to have olcServerID URIs set up as well, that's usually it.
There's also some filtering based on the serverID as transmitted in the consumer's cookie but that's only a partial reduction. Regardless, even if a server started replicating from themselves you should experience no issues/endless loops if that's what you're worried about.
Regards,
openldap-technical@openldap.org
-
Marc Franquesa -
Ondřej Kuzník