Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
O
OpenLDAP
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Ondřej Kuzník
OpenLDAP
Commits
e3dd9ac6
Commit
e3dd9ac6
authored
1 month ago
by
Ondřej Kuzník
Committed by
Ondřej Kuzník
4 weeks ago
Browse files
Options
Downloads
Patches
Plain Diff
Update and clarify replication docs
parent
068881ef
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/guide/admin/replication.sdf
+22
-3
22 additions, 3 deletions
doc/guide/admin/replication.sdf
with
22 additions
and
3 deletions
doc/guide/admin/replication.sdf
+
22
−
3
View file @
e3dd9ac6
...
...
@@ -347,6 +347,10 @@ is too far out of sync (or completely empty), conventional syncrepl is used to
bring it up to date and replication then switches back to the delta-syncrepl
mode.
Note: partial replication is incompatible with deltasync. For deltasync to
work, the replication user needs unrestricted read access to both the main
database and accesslog database.
Note: since the database state is stored in both the changelog DB and the
main DB on the provider, it is important to backup/restore both the changelog
DB and the main DB using slapcat/slapadd when restoring a DB or copying
...
...
@@ -481,9 +485,18 @@ The provider is implemented as an overlay, so the overlay itself
must first be configured in {{slapd.conf}}(5) before it can be
used. The provider has two primary configuration directives and
two secondary directives for when delta-syncrepl is being used.
Because the LDAP Sync search is subject to access control, proper
access control privileges should be set up for the replicated
content.
content. In many environments the replicas are meant to carry the
same data as provider so the replication user needs unrestricted
read access to the database and as such this tends to be the first
access rule for that database:
> access to * by "$REPLICATOR" read by * break
However if partial replication is desired, the access rules can be
tightened appropriately.
The two primary options to configure are the checkpoint and
sessionlog behaviors.
...
...
@@ -497,7 +510,13 @@ operations. If {{<ops>}} operations or more than {{<minutes>}}
time has passed since the last checkpoint, a new checkpoint is
performed. Checkpointing is disabled by default.
The session log is configured by the
If an accesslog is maintained for this database and contains all the
successful writes, it is the preferred way to provide the resync
information:
> syncprov-sessionlog-source <accesslog db suffix>
Otherwise an in memory session session log is configured by the
> syncprov-sessionlog <ops>
...
...
@@ -535,7 +554,7 @@ A more complete example of the {{slapd.conf}}(5) content is thus:
>
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog
100
> syncprov-sessionlog
-source cn=accesslog
H4: Set up the consumer slapd
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment