Watson - GoXDCR should not restart when it receives a NOT_MY_VBUCKET response

Description

GOXDCR does not have an easy way to handle NOT_MY_VBUCKET errors other than restarting. This is because GOXDCR caches vb server map in several components and it is not easy for GOXDCR to handle changes to the vb server map, which is what the NOT_MY_VBUCKET error typically indicates, when replication is still running.

Components

Affects versions

Fix versions

Labels

Environment

None

Link to Log File, atop/blg, CBCollectInfo, Core dump

None

Release Notes Description

None

Attachments

1

blocks

Activity

Andrei Baranouski August 19, 2016 at 8:24 AM

Arunkumar Senthilnathan August 11, 2016 at 9:12 AM

I have verified the functional part in 4.5.1 - please run required perf tests for the same and close this out if there is no issues

Arunkumar Senthilnathan August 10, 2016 at 7:07 AM

Verified in 4.5.1-2809:
1. Setup 2x2 unixdcr
2. pumped in 100k items - waited for replication to catch up
3. killed cb server in one of the nodes in source cluster
4. failed over the node in ui and rebalanced
5. collected logs - noted that replication did not restart right away on receiving not_my_vbucket error - checkpoint was recorded - replication completed without any errors
attaching logs

Arunkumar Senthilnathan August 9, 2016 at 5:55 PM

Waiting on to verify the bug

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Is this a Regression?

Yes

Triage

Triaged

Priority

Instabug

Open Instabug

PagerDuty

Sentry

Zendesk Support

Created July 22, 2016 at 5:48 PM
Updated August 19, 2016 at 8:24 AM
Resolved August 12, 2016 at 8:46 PM
Instabug