Ticket #369 (closed defect: fixed)

Opened 2 years ago

Last modified 23 months ago

restore of replica ldif file on second master after deleting two records shows only 1 deletion

Reported by: rmeggins Owned by: mreynolds
Priority: major Milestone: 1.2.11
Component: Replication - General Version:
Keywords: Cc:
Blocked By: Blocking:
Review: ack Ticket origin:
Red Hat Bugzilla: 830335

Description

steps:

1) on IPA replica, lets create 4 IPA users: A,B,C and D. Now make a backup with 'db2ldif.pl -r ...'

2) on IPA replica, delete the user D. 'ipa user-del D'.

3) on IPA master, delete the user C. 'ipa user-del C'.

4) now check on other IPA master and IPA replica, both shows only two users 'A' and 'B'. this is expected.

5) now on IPA replica, restore the backup with 'ldif2db.pl'

6) check on IPA replica immediately, 'ipa user-find' shows 4 users 'A, B, C, D' at the beginning.

7) check IPA Master, 'ipa user-find' shows still only two users 'A, B'.

8) wait 3 minutes or so, check on IPA replica, and found that there are only THREE users 'A, B, D'. The users 'C' is deleted now -- change propagated from IPA Master.

9) check on IPA Master again and again, there are still only two users 'A, B'.

10) check on IPA Replica again and again, there are still three users 'A, B,D'. --- this status is different from IPA Master's 'A,B', or backup's 'A, B, C, D'.

If backup was created without '-r' option, then the step 8 above will always show 'A,B,C,D', the same as backup. with '-r' option make the final result between.

I think the delete of C that first occurred on the replica should have been propagated to the master, and then back to the replica after the restore from ldif.

Attachments

0001-Ticket-369-restore-of-replica-ldif-file-on-second-ma.patch (2.1 KB) - added by mreynolds 2 years ago.

Change History

comment:1 Changed 2 years ago by nkinder

  • Milestone changed from 0.0 NEEDS_TRIAGE to 1.2.11

comment:2 Changed 2 years ago by mreynolds

  • Owner changed from rmeggins to mreynolds
  • Status changed from new to assigned

comment:3 Changed 2 years ago by mreynolds

  • Review set to needinfo

I can not reproduce this problem on trunk/master

Here are my steps:

[1] Create two instances: master and dedicated consumer
[2] Setup replication and initialize consumer
[3] Create 4 users on the master: a, b, c, d
[4] do a "db2ldif -r" on the consumer
[5] On master: delete 'c'
[6] On Consumer: delete 'd'
[7] do a ldif2db on consumer -> now the consumer has entries: a,b,c,d
[8] Either wait, or update entry 'a' on master.
[9] Both master and consumer only have entries: a, b

Are there any other steps that were not listed?

comment:4 Changed 2 years ago by rmeggins

comment:5 follow-up: ↓ 6 Changed 2 years ago by mreynolds

There two differences from what I did:

[1] They used some IPA tools
[2] They used the perl script versions of db2ldif/ldif2db

I retested using the perl scripts, and once again it works fine.

comment:6 in reply to: ↑ 5 Changed 2 years ago by rmeggins

Replying to mreynolds:

There two differences from what I did:

[1] They used some IPA tools
[2] They used the perl script versions of db2ldif/ldif2db

I retested using the perl scripts, and once again it works fine.

Since the original reporter is not listed in the CC list of this ticket, you will either need to contact him/her directly, or reply on the freeipa-users thread.

comment:7 Changed 2 years ago by mreynolds

I was able to reproduce the issue by using multi master replication. So instead of a dedicated consumer, it had to be a master as well(two masters).

Continuing investigation...

comment:8 Changed 2 years ago by mreynolds

The problem is that we are intentionally skipping updates from other consumers in clcache_skip_change()

I'm not sure if there is a proper fix, or if there would be a better process? For example, instead of doing a db2ldif/ldif2db on the same replica, do the db2ldif from the Master A, and then do a ldif2db on Master B.

Going to run this by the team...

comment:9 Changed 2 years ago by mreynolds

  • Review changed from needinfo to review?

comment:10 Changed 2 years ago by nkinder

  • Review changed from review? to ack

comment:11 Changed 23 months ago by mreynolds

  • Resolution set to fixed
  • Status changed from assigned to closed

git merge ticket369
Updating 72b7e91..a640ac2
Fast-forward

ldap/servers/plugins/replication/cl5_clcache.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)

git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.13 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git

72b7e91..a640ac2 master -> master

comment:12 Changed 23 months ago by nkinder

  • Red Hat Bugzilla set to [https://bugzilla.redhat.com/show_bug.cgi?id=830335 830335]

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=830335

comment:13 Changed 20 months ago by nkinder

  • screened set to 1

Added initial screened field value.

Note: See TracTickets for help on using tickets.