Bug 1310848
Summary: | Supplier can skip a failing update, although it should retry. | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Noriko Hosoi <nhosoi> | |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> | |
Severity: | urgent | Docs Contact: | Petr Bokoc <pbokoc> | |
Priority: | urgent | |||
Version: | 7.3 | CC: | ekeck, gparente, kbanerje, mkolaja, nkinder, pbokoc, rmeggins, tmihinto | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | 389-ds-base-1.3.5.2-1.el7 | Doc Type: | Bug Fix | |
Doc Text: |
Failed replication updates are now retried correctly in the next session
If a replica update failed on the consumer side and was followed by another update that succeeded, the consumer's replication status was updated by the successful update, which caused the consumer to seem as if it was up to date. Consequently, the failed update was never retried, leading to data loss. With this update, a replication failure closes the connection and stops the replication session. This prevents further updates from changing the consumer's replication status, and allows the supplier to retry the failed operation in the next session, avoiding data loss.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1351447 (view as bug list) | Environment: | ||
Last Closed: | 2016-11-03 20:39:41 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: | 1351447 |
Description
Noriko Hosoi
2016-02-22 19:34:12 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions Bug Verified Work fine for me no error occure during the adding and deleteing entry in MMR setup Step1) Set up MMR Step 2) Add 1 million user in instance using ldclt ldclt -D "cn=Directory Manager" -w test1234 -f cn=XXXXXX -b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r1 -R1000000 -I 68 -I 32 -H ldap://localhost:389 Step 3) delete same 1 million user ldclt -D "cn=Directory Manager" -w test1234 -f cn=XXXXXX -b "ou=people,dc=example,dc=com" -e delete,person,incr,noloop,commoncounter -r1 -R1000000 -I 68 -I 32 -H ldap://localhost:389 Step 4) Check access log [root@dhcp210-197 slapd-test1]# pwd /var/log/dirsrv/slapd-test1 [root@dhcp210-197 slapd-test1]# grep -c err=53 access* access:0 access.20160727-183248:0 access.20160728-064940:0 access.20160728-192225:0 access.20160801-090001:0 access.20160801-222119:0 access.rotationinfo:0 [root@dhcp210-197 slapd-test]# pwd /var/log/dirsrv/slapd-test [root@dhcp210-197 slapd-test]# grep -c err=53 access* access:0 access.20160727-183209:0 access.20160728-063057:0 access.20160728-190940:0 access.20160801-093749:0 access.20160801-222320:0 access.rotationinfo:0 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html *** Bug 1339693 has been marked as a duplicate of this bug. *** |