爲什麼啓動mongos時配置服務器字符串順序敏感？

Question

並提前感謝您的時間。

對於給定的分片設置，在指定要與之通話的配置服務器時啓動mongos。假設我們從以下mongos選項開始：

--configdb=cf1,cf2,cf3 

一切都很好，並且很棒。如果你要重新啓動mongos（或啓動不同的mongos）有：

-- configdb=cf3,cf2,cf1 

這將導致以下錯誤：

Tue Jul 9 23:32:41 uncaught exception: error: { "$err" : "could not initialize sharding on connection rs1/db1.me.net:27017,db2.me.net:27017,db3.me.net:27017, :: caused by :: mongos specified a different config database string : stored :cfg1:27017,cfg2:27017,cfg3:27017 vs given :cfg3:27017,cfg2:27017,cfg1:27017","code" : 15907} 

我的問題是，什麼是推理蒙戈到的順序敏感配置服務器字符串？我想在某個時候它會解析不同的服務器主機名/端口，爲什麼不直接比較一下呢？我知道你可以從source code看到它只是一個字符串比較，但我的問題是這個的根本原因。

這個問題的一些上下文：我使用廚師爲我的mongo部署。我們最近經歷了migrating the config server with the same hostname的練習。然而，這仍然是一個破壞性的過程，因爲廚師拿起配置服務器的命令已經改變，從而改變了命令mongos開始它的過程。我明白這個問題直接是因爲廚師的功能，但我很好奇爲什麼Mongo不是這樣靈活。

再次感謝您的時間。

Answer 1

mongos當mongos進程更改分片羣集的元數據時，它必須「同時」在所有三個配置服務器中更改它（即所有三個配置服務器必須同意才能進行有效的元數據更改）。

如果系統在這樣的元數據更改過程中停下來，如果配置數據庫的順序不固定，那麼將會有更多的不正確的狀態進行排列。要求固定的配置數據序列允許（a）更簡單地檢查羣集的所有成員是否正在查看相同的元數據（b）當系統崩潰或以其他方式意外停止時可能的狀態的顯着減少。

此外，如果不同的mongos'可以在不同的配置服務器上啓動相同的操作，它可以減少「競爭條件」種類的錯誤的機會。即使像mongos這個簡單的變化過程採用「虛擬」分佈式鎖來查看是否有必要 - 您如何處理不同的mongos'以不同順序檢查配置服務器以檢查（並取出）鎖的情況？

作爲總結，這三個配置服務器不副本集，但其中一人仍然必須總是接受改變「第一次」的一個 - 想configdbs的順序來mongos作爲指定這種「第一」狀態。