[KAFKA-86] SourceConnector failing after dropDatabase Created: 14/Feb/20 Updated: 28/Oct/23 Resolved: 28/Feb/20 |
|
| Status: | Closed |
| Project: | Kafka Connector |
| Component/s: | None |
| Affects Version/s: | 1.0 |
| Fix Version/s: | 1.0.1 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Jeffrey Sposetti | Assignee: | Ross Lawley |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Case: | (copied to CRM) | ||||||||
| Description |
|
SourceConnector failing after dropDatabase Using single instance MongoDB Source Connector, running 1 task. Using a few different configurations, I can get the connector to fail after performing dropDatabase...seems like something is up when handling an invalidate? SCENARIO 1: Watching a database with a topic prefix. Here is the configuration:
1. create database "test" 2. create collections testone, testtwo, testthree 3. insert documents into the collections, you'll see insert events show up on topics topicprefix.test.testone|testtwo|testthree 4. dropDatabase. You'll see drop events in topicprefix.test.testone|testtwo|testthree and a dropDatabase in topicprefix.test and an invalidate in "topicprefix." 5. Repeat steps 1-4 above. You will get many duplicate drop events and dropDatabase events in each topic, and duplicate invalidates in the "topicprefix." Pasting that topic output below. 6. Connector goes into degraded state, then fails. Here is stack trace from the connect.log
Topic output:
SCENARIO 2: Watching a database. Here is the configuration:
1. create database "test" 2. create collections testone, testtwo, testthree 3. insert documents into the collections, you'll see insert events show up on topics topicprefix.test.testone|testtwo|testthree 4. dropDatabase. You'll see drop events in test.testone|testtwo|testthree and a dropDatabase in test. 5. Connector goes into degraded state, then fails. Here is stack trace from the connect.log
|
| Comments |
| Comment by Githook User [ 28/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'username': 'rozza', 'name': 'Ross Lawley', 'email': 'ross.lawley@gmail.com'}Message: Fix resumability of change streams
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ross Lawley [ 27/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ross Lawley [ 25/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I have been able to replicate in our local test suite and now working on a fix. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Sposetti [ 17/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I retested w and w/o using topic prefix. The end result is the same: the connector fails although the event processing and exceptions are different. So something seems to be going on when watching a specific database and dropping the database (so the handling of invalidate?).
ross.lawley For sanity, I also checked just watching the whole cluster (i.e. not watching a specific database). No problems and everything works as expected normal (since there are no invalidates sent since our change stream is on the whole deployment, not a specific database).
So the problems are with 2 and 3 above. It seems to makes sense that after you dropDatabase on the database you are watching, you get invalidate & you should not be able to resumeToken...because you are not resuming...that databases change stream is done at that point. I think we just have to handle that? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Sposetti [ 14/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It's a very simple 3-node replicaset, not sharded:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ross Lawley [ 14/Feb/20 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
What MongoDB version are you using jeffrey.sposetti and what is the topology? ReplicaSet / Sharded Replciaset? |