[SERVER-14003] 2.6 mongos does not support overlapped writes at w:0 Created: 20/May/14 Updated: 06/Dec/22 Resolved: 24/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.6.1 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Critical - P2 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 4 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Sharding
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
Shows up as a performance degradation for applications that use w:0 and getLastError in a sharded environment when going from 2.4 to 2.6: To reproduce: create a collection, mongodump, mongorestore via mongos to single-shard cluster (single mongod, single config server). Doesn't seem to matter if collection is sharded or not. Here are some numbers for one data set:
Another data set, showing that sharded or unsharded shows same degradation:
|
| Comments |
| Comment by Gregory McKeon (Inactive) [ 24/Apr/18 ] |
|
Both w:0 writes and gle are soon to be deprecated and 2.6 is no longer supported, so we're closing this as won't fix. |
| Comment by Andy Schwerin [ 25/Sep/15 ] |
|
The purpose of getLastError is to allow a client application to learn about the success or failure of the immediately prior unconfirmed write on the connection, and to wait for a write concern to be satisfied on that write. As such, mongos must track information on all unconfirmed writes to satisfy getLastError requests that may come in the future. There are two ways to do this. One is the way that we do in 2.6 and beyond, which is to implement unconfirmed writes to mongos as confirmed writes to mongod, and store relevant return data. The other way, which we did in 2.4 and before, was to tightly bind client connections with corresponding shard connections in mongos. That is, if a client contacts mongos on mongos connection 1 and does an unconfirmed write, and mongos takes shard1 connection 2 out of the pool to perform that write on the shard, it must not re-use shard 1 connection 2 for any purpose other than to satisfy connection 1's getLastError request until that request arrives or the client closes connection 1. This leads to very high connection counts and very complicated accounting in mongos. That complicated accounting also prevents other necessary enhancements to sharding, so we removed it. |
| Comment by Greg Studer [ 09/Jul/14 ] |
|
gianfranco Keeping this open as the more general issue - at some point we'd like to address. |
| Comment by Gianfranco Palumbo [ 04/Jun/14 ] |
|
I think this should be closed as duplicate of |
| Comment by Greg Studer [ 20/May/14 ] |
|
This is known behavior - it's due to the fact that the mongo tools do not use batch operations, and mongos converts old-style w:0 writes into w:1 writes. |