[JAVA-2501] fsyncunlock does not work on secondaries with 3.2.x Created: 22/Apr/17 Updated: 29/Oct/23 Resolved: 25/Apr/17 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Command Operations |
| Affects Version/s: | 3.4.2 |
| Fix Version/s: | 3.5.0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Dharshan Rangegowda | Assignee: | Ross Lawley |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
I am using java driver version 3.4.2 Fsyncunlock does not work on the secondary with 3.2.3 & 3.2.12. It works fine on the primary.
|
| Comments |
| Comment by Dharshan Rangegowda [ 20/Jul/17 ] | |||
|
I am able to repro this fairly consistently on one setup - let me file a new bug given that this is a different issue. | |||
| Comment by Dharshan Rangegowda [ 19/Jul/17 ] | |||
|
Hi folks, A quick update on this bug. Running the (fsyncUnlock,1) command explicitly to unlock is also failing intermittently. The server I tested against was 3.2.x The command returns successfully in the client but in the server traces it doesn't confirm the unlock like it usually does (it just says received request). Ended up having to restart the server to move forward. fsyncUnlock is a synchronous command right? Traces below 2017-07-19T00:12:17.309+0000 I ACCESS [conn3540] Successfully authenticated as principal admin on admin keyUpdates:0 writeConflicts:0 numYields:0 reslen:162 locks:{} protocol:op_ | |||
| Comment by Jeffrey Yemin [ 25/Apr/17 ] | |||
|
Nothing firm yet, but likely in the next couple of months. Note also that, as Ross indicated above, MongoDB 3.2 added an fsyncUnlock command that can be called directly from your application, so there is a straightforward workaround:
| |||
| Comment by Dharshan Rangegowda [ 25/Apr/17 ] | |||
|
Thanks for the quick turnaround. Any estimate on when 3.5.0 will be generally released? | |||
| Comment by Githook User [ 25/Apr/17 ] | |||
|
Author: {u'username': u'rozza', u'name': u'Ross Lawley', u'email': u'ross.lawley@gmail.com'}Message: Updated FsyncUnlockOperation to be a ReadOperation The command does not require a primary to run. | |||
| Comment by Ross Lawley [ 25/Apr/17 ] | |||
| Comment by Ross Lawley [ 25/Apr/17 ] | |||
|
A direct connection is the correct way forward. Currently, mongo#unlock uses an operation underneath that requires a Primary node. This is a bug as fsync lock and unlock can be called on Secondaries. To work around you can issue the command by creating it manually and calling: DB#command or MongoDatabase#runCommand. See the fsync command documentation for more information. Running a fsync lock and unlock on anything other than a direct connection may not work as expected. This is because the driver will select a server based on the read preference and if there are multiple matching mongod's then it can easily select different machines. All the best, Ross | |||
| Comment by Dharshan Rangegowda [ 24/Apr/17 ] | |||
|
Hi Ross, 1) The db.fsyncLock and unlock are being sent on the same connection. | |||
| Comment by Ross Lawley [ 24/Apr/17 ] | |||
|
It looks like the FsyncUnlockOperation requires a writable server and isn't able to find one. Can you confirm there is no Primary node at the time of calling mongo#unlock? Please note from the documentation
Given, you have a connection to a replica set, where was the original fsync lock command sent to? You will need to send the unlock to the same server. As replica set topologies can change, it may be prudent to make a direct connection to a replica set member rather than connecting to the set as a whole. Finally, you can issue an fsync unlock command with a secondary read preferenc by calling DB#command or MongoDatabase#runCommand and passing the relevant read preference. I hope that helps, Ross |