[SERVER-27597] The migration critical section does not need to stop reads Created: 06/Jan/17 Updated: 24/Jan/19 Resolved: 13/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.0.15, 3.2.13, 3.4.4, 3.5.1 |
| Fix Version/s: | 3.5.9 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Kaloian Manassiev |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding 2017-06-19 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
Currently when a shard is in the migration critical section it will block both read and write operation. The writes certainly need to be blocked to allow the last bits of the migration to be transferred, but there is no real need to block the reads. We could use the mode of the global lock to differentiate reads from writes. With this change the critical section stall would be only as long as the write on the config server is (instead of also including transferring the latest changes from donor to recipient). One thing which this may exacerbate is the length of the critical section if a large number of concurrent reads thrash the cache and cause the final batch of documents to take longer time to transfer. |
| Comments |
| Comment by wangke [ 23/Jan/19 ] |
|
hi, it seems the fix only make donor permit read operation in step 5. It has little improvement to our mongo sharding cluster(v3.4.18 with the patch) since step 5 take 10ms while step 6 may take 200-300 ms to commit and refresh catalogCache. What if read operations are not blocked in step 6? |
| Comment by Githook User [ 14/Jun/17 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: |
| Comment by Githook User [ 13/Jun/17 ] |
|
Author: {u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}Message: |
| Comment by Andy Schwerin [ 05/May/17 ] |
|
renctan, you are correct that it can make the range deleter wait on more queries, but the critical section is going to end eventually, at which point new queries for the old ranges will stop arriving. I think shifting waiting onto the range deleter is a pretty good tradeoff. |
| Comment by Randolph Tan [ 06/Jan/17 ] |
|
However, this can have a side effect of adding more queries the range deleter has to wait on. |