From cedbc9f77fe8cf4e77010e4fc11dc09ea281e6c5 Mon Sep 17 00:00:00 2001 From: Howard Chu Date: Mon, 16 Jan 2012 10:10:19 -0800 Subject: [PATCH] Clarification/warning about delta-sync backup/restore --- doc/guide/admin/replication.sdf | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 5294804e75..adcf276cd8 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -335,7 +335,7 @@ demonstrate a very real problem that is encountered in some LDAP deployments. Delta-syncrepl, a changelog-based variant of syncrepl, is designed to address situations like the one described above. Delta-syncrepl works by maintaining a -changelog of a selectable depth on the provider. The replication consumer +changelog of a selectable depth in a separate database on the provider. The replication consumer checks the changelog for the changes it needs and, as long as the changelog contains the needed changes, the consumer fetches the changes from the changelog and applies them to its database. If, however, a replica @@ -343,6 +343,11 @@ 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: 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 +it to another machine. + For configuration, please see the {{SECT:Delta-syncrepl}} section. -- 2.39.5