Bug 669205

Summary: db2bak: backed up changelog should include RUVs
Product: [Retired] 389 Reporter: Noriko Hosoi <nhosoi>
Component: Command Line UtilitiesAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: high    
Version: 1.2.7CC: amsharma, andrey.ivanov, ohegarty, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:39:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 639035, 656390    
Attachments:
Description Flags
git patch file (master) nkinder: review+

Description Noriko Hosoi 2011-01-12 21:16:26 UTC 
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.
Comment 1 Noriko Hosoi 2011-01-18 02:29:10 UTC 
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
Comment 2 Noriko Hosoi 2011-01-18 18:51:44 UTC 
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
Comment 4 Noriko Hosoi 2011-03-23 20:18:01 UTC 
*** Bug 158661 has been marked as a duplicate of this bug. ***
Comment 5 Amita Sharma 2011-05-11 11:45:01 UTC 
This bug is already covered under ChangeLog test suit and verified successfully.