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?) kevinu wrote: 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. rmeggins wrote: 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) Description: 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 error message: [...] - 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. See also: http://directory.fedoraproject.org/wiki/Move_changelog#Backing_up_Changelog
Reviewed by Nathan (Thanks!!!) Pushed to master. $ git merge work Updating e9fa824..f9a13fd Fast-forward 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) To ssh://git.fedorahosted.org/git/389/ds.git 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.