Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
None
-
Fully Compatible
-
ALL
-
v4.4
-
Sharding 2020-06-29
-
11
Description
Using a higher maxTimeMS would make the test take longer but would be more robust to other parts of the moveChunk command taking longer. We could also consider introducing a failpoint to lower the maxTimeMS only before configsvr_client::moveChunk() is called.
diff --git a/src/mongo/s/commands/cluster_move_chunk_cmd.cpp b/src/mongo/s/commands/cluster_move_chunk_cmd.cpp
|
index 398d8fc49c..da899c2550 100644
|
--- a/src/mongo/s/commands/cluster_move_chunk_cmd.cpp
|
+++ b/src/mongo/s/commands/cluster_move_chunk_cmd.cpp
|
@@ -46,11 +46,14 @@
|
#include "mongo/s/config_server_client.h"
|
#include "mongo/s/grid.h"
|
#include "mongo/s/request_types/migration_secondary_throttle_options.h"
|
+#include "mongo/util/fail_point.h"
|
#include "mongo/util/timer.h"
|
|
|
namespace mongo {
|
namespace {
|
|
|
+MONGO_FAIL_POINT_DEFINE(startMoveChunkWithoutWaiting);
|
+
|
class MoveChunkCmd : public ErrmsgCommandDeprecated {
|
public:
|
MoveChunkCmd() : ErrmsgCommandDeprecated("moveChunk", "movechunk") {}
|
@@ -190,6 +193,9 @@ public:
|
chunkType.setShard(chunk->getShardId());
|
chunkType.setVersion(cm->getVersion());
|
|
|
+ if (MONGO_unlikely(startMoveChunkWithoutWaiting.shouldFail())) {
|
+ opCtx->setDeadlineAfterNowBy(Microseconds(1), ErrorCodes::MaxTimeMSExpired);
|
+ }
|
uassertStatusOK(configsvr_client::moveChunk(opCtx,
|
chunkType,
|
to->getId(), |
Attachments
Issue Links
- related to
-
SERVER-48153 Chunk migration can still be running even after the moveChunk command fails with maxTimeMS timeout
-
- Backlog
-