Bug 1294770
Summary: | Supplier can skip a failing update, although it should retry. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | German Parente <gparente> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | unspecified | Docs Contact: | Petr Bokoc <pbokoc> |
Priority: | unspecified | ||
Version: | 6.8 | CC: | jgalipea, mreynolds, nkinder, pbokoc, rmeggins, spichugi, tbordaz, tmihinto |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 389-ds-base-1.2.11.15-73.el6 | Doc Type: | Bug Fix |
Doc Text: |
Replication failures no longer result in missing changes after additional updates
Previously, if a replicated update failed on the consumer side, it was never retried due to a bug in the replication asynchronous result thread which caused it to miss the failure before another update was replicated successfully. The second update also updated the consumer Replica Update Vector (RUV), and the first (failed) update was lost. In this release, replication failures cause the connection to close, stopping the replication session and preventing any subsequent updates from updating the consumer RUV, which allows the supplier to retry the operation in the next replication session. No updates are therefore lost.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-10 19:22:35 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
German Parente
2015-12-30 08:55:21 UTC
Fixed upstream. Verification steps: [1] Set up MMR [2] Add 1 million entries to each replica(total of 2 million entries) [3] On each replica delete the 1 million entries that were just added(total of 2 million deletes) [4] Check the access log for error 51. If the error is found, see if that CSN from that failed operation is replayed shortly after the failure. Build tested: 389-ds-base-1.2.11.15-74.el6.x86_64 Verification steps: 1) Set up MMR master1 - 389 - dc=example,dc=com master2 - 390 - dc=example,dc=com 2) Add 1 million entries to each replica (total of 2 million entries) ldclt -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -f cn=MrXXXXXX -b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r0 -R999999 ldclt -h localhost -p 390 -D "cn=Directory Manager" -w Secret123 -f cn=MrsXXXXXX -b "ou=people,dc=example,dc=com" -e add,person,incr,noloop,commoncounter -r0 -R999999 3) On each replica delete the 1 million entries that were just added(total of 2 million deletes) ldclt -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=example,dc=com" -e delete -f cn=MrXXXXXX -e incr,noloop,commoncounter -r0 -R999999 -I 32 ldclt -h localhost -p 390 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=example,dc=com" -e delete -f cn=MrsXXXXXX -e incr,noloop,commoncounter -r0 -R999999 -I 32 4) Check the access log for error 51. If the error is found, see if that CSN from that failed operation is replayed shortly after the failure grep "err=51" /var/log/dirsrv/slapd-master1/access echo $? 1 grep "err=51" /var/log/dirsrv/slapd-master2/access echo $? 1 Marking as verified. 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/RHBA-2016-0737.html |