Description of problem (email discussion):
While I was working on the bug 663752, I noticed this potential backup issue.
Now the back up utility db2bak backs up all the database files including changelog. The utility can be executed while the server is up and running. The issue is the changelog does not have RUVs while the server is running. The RUVs are maintained in memory while the server is running and stored in the changelog when the changelog is closed. When the changelog is opened, the RUVs are read from the changelog db and removed just after that. If RUVs are not found in the changelog db, new ones are generated. If servers in the replication topology are not in sync, this would cause the inconsistency among them.
If the servers are down when the backup is run, there is no problem since the RUVs are stored in the changelogs.
What should we do to prevent this?
1. If the server is in the replication topology, we don't allow db2bak to run against the running server?
2. Doc it -- make sure the servers in the replication topology are in sync before running db2bak?
3. When db2bak is issued, close the changelog and reopen it when it's done? (Not sure how feasible it is since the replication plug-in does not know anything about the backup... Will require another callback?)
Customers need a way to backup their directory while the service is running
preferably without degradation in performance.
So it would be nice if we could solve this without requiring them to
shut down one of their servers.
I think 3 is the only valid option - the user must be able to run db2bak while the servers are running, without requiring the entire topology to be in sync.
Created attachment 473957 [details]
git patch file (master)
Introduced backup plugin hooks: SLAPI_PLUGIN_BE_PRE_BACKUP_FN
and SLAPI_PLUGIN_BE_POST_BACKUP_FN to call back cl5WriteRUV and
cl5DeleteRUV, respectively. cl5WriteRUV adds RUVs to changelog
and cl5DeleteRUV reads and deletes RUVs in changelog. The call-
back functions are avaiable only when the process is initialized
as a server, which must have started with a backend normal mode
flag (DBLAYER_NORMAL_MODE) not with other utility modes such as
DBLAYER_ARCHIVE_MODE. With this restriction, db2bak is not
allowed to use to back up the database including changelog db
when the server is up. If launched, the utility fails with this
[...] - db2archive: pre-backup-plugin failed (1).
[...] - ERROR: Standalone db2bak is not supported \
when a multimaster replication enabled server is coexisting.
Please use db2bak.pl, instead.
As mentioned in the message, db2bak.pl is supposed to be used.
Reviewed by Nathan (Thanks!!!)
Pushed to master.
$ git merge work
Makefile.am | 2 +-
Makefile.in | 64 +++----
ldap/servers/plugins/replication/cl5_api.c | 198 +++++++++++++++++++-
ldap/servers/plugins/replication/cl5_api.h | 13 ++
ldap/servers/plugins/replication/cl5_init.c | 2 +
ldap/servers/plugins/replication/repl5_init.c | 6 +-
.../plugins/replication/repl5_replica_config.c | 11 +-
ldap/servers/slapd/back-ldbm/archive.c | 19 ++
ldap/servers/slapd/pblock.c | 24 +++
ldap/servers/slapd/plugin.c | 6 +-
ldap/servers/slapd/protect_db.h | 2 +-
ldap/servers/slapd/slap.h | 4 +
ldap/servers/slapd/slapi-plugin.h | 2 +
ldap/servers/slapd/slapi-private.h | 2 +
14 files changed, 302 insertions(+), 53 deletions(-)
$ git push
Counting objects: 43, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 5.05 KiB, done.
Total 22 (delta 20), reused 0 (delta 0)
e9fa824..f9a13fd master -> master
*** Bug 158661 has been marked as a duplicate of this bug. ***
This bug is already covered under ChangeLog test suit and verified successfully.