MongoDB mongorestore导入遇到waiting for write concern

短命女 2023-06-08 03:16 8阅读 0赞

开发人员告知使用mongorestore导入数据过程中卡着停滞不前，我协助排查。  
使用db.currentOp()发现一些下面的信息：

{
    			"desc" : "conn927252",
    			"threadId" : "47404144039680",
    			"connectionId" : 927252,
    			"client" : "xxx.xxx.xxx.xxx:20338",
    			"active" : true,
    			"opid" : 15695115,
    			"secs_running" : 19335,
    			"microsecs_running" : NumberLong("19335266030"),
    			"op" : "insert",
    			"ns" : "xxxx.xxxx",
    			"query" : {
    				"$msg" : "query not recording (too large)"
    			},
    			"msg" : "waiting for write concern",
    			"numYields" : 0,
    			"locks" : {
    				
    			},
    			"waitingForLock" : false,
    			"lockStats" : {
    				"Global" : {
    					"acquireCount" : {
    						"r" : NumberLong(41),
    						"w" : NumberLong(41)
    					}
    				},
    				"Database" : {
    					"acquireCount" : {
    						"w" : NumberLong(40),
    						"W" : NumberLong(1)
    					}
    				},
    				"Collection" : {
    					"acquireCount" : {
    						"w" : NumberLong(1),
    						"W" : NumberLong(1)
    					}
    				},
    				"Metadata" : {
    					"acquireCount" : {
    						"w" : NumberLong(39)
    					}
    				},
    				"oplog" : {
    					"acquireCount" : {
    						"w" : NumberLong(39)
    					}
    				}
    			}
    		},

可以看到是在insert数据时等待write concern的确认，与开发确认这个操作正是需要导入的数据。  
那么可以从MongoDB的writeconcern入手，由于当前是一个一主一从一arbiter的复制集，那么可以看下是否是从库异常了，导致write concern特性得不到足够数量的响应，  
通过rs.status()发现，从节点果然是异常了：

{
    			"_id" : 1,
    			"name" : "xxx.xxxx.xxx.xxx:27017",
    			"health" : 1,
    			"state" : 3,
    			"stateStr" : "RECOVERING",
    			"uptime" : 2271467,
    			"optime" : {
    				"ts" : Timestamp(1569397927, 22912),
    				"t" : NumberLong(1)
    			},
    			"optimeDate" : ISODate("2019-09-25T07:52:07Z"),
    			"lastHeartbeat" : ISODate("2019-10-15T13:40:44Z"),
    			"lastHeartbeatRecv" : ISODate("2019-10-15T13:40:41.603Z"),
    			"pingMs" : NumberLong(0),
    			"configVersion" : 1
    		},

经排查是因为前段时间主库导入了大量数据，导致主库的oplog更新过快，从库丢失了更新，所以断开了复制。  
至此，从库异常可能是导致`waiting for write concern`的原因，但是我们还要再进一步查看当前复制的write concern设置到底是什么。  
使用rs.status()检查当前复制集的writeconcern设置：

"settings" : {
    		"chainingAllowed" : true,
    		"heartbeatIntervalMillis" : 2000,
    		"heartbeatTimeoutSecs" : 10,
    		"electionTimeoutMillis" : 10000,
    		"getLastErrorModes" : {
    			
    		},
    		"getLastErrorDefaults" : {
    			"w" : 1,
    			"wtimeout" : 0
    		},
    		"replicaSetId" : ObjectId("5d832371eef5c1fea4810057")
    	}

可以发现当前复制集w是1，也就是说写入只需要当前实例确认即可。  
那么这里就有点蒙了，前面发现从节点异常本来以为找到了原因，但是发现write concern根本不需要从节点的参与。而且当前主库是正常的，也就是说回应write concern的节点数是满足的。  
除了全局的write concern设置，语句级别的w设置会覆盖全局设定，会不会是这个原因呢？  
而发生`waiting for write concern`的是mongorestore导入的语句，应该也不会有人为设定w属性的可能。  
那么唯一可能的，就是mongorestore有默认的write concern配置。  
查阅官方文档发现mongorestore的如下参数

--writeConcern=<document>
    Default: majority
    
    Specifies the write concern for each write operation that mongorestore performs.

真想大白，原来mongorestore的–writeConcern默认值是majority，那么对于当前复制集，就需要主库和从库都对写入响应，才能完成语句的执行。而从库这是已经异常，所以语句的执行一直卡在等待从库的响应。  
那么解决导数问题的方法也就一目了然了，只要在使用mongorestore时指定`--writeConcern`为1即可，–writeConcern="\{w:1\}"  
而从库的问题，可以找个空闲时间再慢慢重新初始化。