Bug 669205 - db2bak: backed up changelog should include RUVs
Summary: db2bak: backed up changelog should include RUVs
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Command Line Utilities
Version: 1.2.7
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
: 158661 (view as bug list)
Depends On:
Blocks: 639035 389_1.2.8
TreeView+ depends on / blocked
 
Reported: 2011-01-12 21:16 UTC by Noriko Hosoi
Modified: 2015-12-07 16:39 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-12-07 16:39:54 UTC


Attachments (Terms of Use)
git patch file (master) (36.14 KB, patch)
2011-01-18 02:29 UTC, Noriko Hosoi
nkinder: review+
Details | Diff

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@redhat.com 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@redhat.com 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.


Note You need to log in before you can comment on or make changes to this bug.