Баланс осколков Mongodb не работает должным образом, с большой ошибкой moveChunk
У нас есть кластер mongoDb с 3 осколками, каждый осколок представляет собой набор реплик, содержащий 3 узла, версия mongoDb, которую мы используем, - 3.2.6. У нас есть большая база данных размером около 230G, которая содержит около 5500 коллекций. мы обнаружили, что около 2300 коллекций не сбалансированы, тогда как другие 3200 коллекций равномерно распределены по 3 осколкам.
ниже результат sh.status (весь результат слишком велик, я просто публикую часть из них):
mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("57557345fa5a196a00b7c77a")
}
shards:
{ "_id" : "shard1", "host" : "shard1/10.25.8.151:27018,10.25.8.159:27018" }
{ "_id" : "shard2", "host" : "shard2/10.25.2.6:27018,10.25.8.178:27018" }
{ "_id" : "shard3", "host" : "shard3/10.25.2.19:27018,10.47.102.176:27018" }
active mongoses:
"3.2.6" : 1
balancer:
Currently enabled: yes
Currently running: yes
Balancer lock taken at Sat Sep 03 2016 09:58:58 GMT+0800 (CST) by iZ23vbzyrjiZ:27017:1467949335:-2109714153:Balancer
Collections with active migrations:
bdtt.normal_20131017 started at Sun Sep 18 2016 17:03:11 GMT+0800 (CST)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
1490 : Failed with error 'aborted', from shard2 to shard3
1490 : Failed with error 'aborted', from shard2 to shard1
14 : Failed with error 'data transfer error', from shard2 to shard1
databases:
{ "_id" : "bdtt", "primary" : "shard2", "partitioned" : true }
bdtt.normal_20160908
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard2 142
too many chunks to print, use verbose if you want to force print
bdtt.normal_20160909
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard1 36
shard2 42
shard3 46
too many chunks to print, use verbose if you want to force print
bdtt.normal_20160910
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard1 34
shard2 32
shard3 32
too many chunks to print, use verbose if you want to force print
bdtt.normal_20160911
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard1 30
shard2 32
shard3 32
too many chunks to print, use verbose if you want to force print
bdtt.normal_20160912
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard2 126
too many chunks to print, use verbose if you want to force print
bdtt.normal_20160913
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard2 118
too many chunks to print, use verbose if you want to force print
}
Коллекция "normal_20160913" не сбалансирована, я выкладываю результат getShardDistribution() этой коллекции ниже:
mongos> db.normal_20160913.getShardDistribution()
Shard shard2 at shard2/10.25.2.6:27018,10.25.8.178:27018
data : 4.77GiB docs : 203776 chunks : 118
estimated data per chunk : 41.43MiB
estimated docs per chunk : 1726
Totals
data : 4.77GiB docs : 203776 chunks : 118
Shard shard2 contains 100% data, 100% docs in cluster, avg obj size on shard : 24KiB
процесс балансировки находится в рабочем состоянии, а размер фрагмента по умолчанию (64M):
mongos> sh.isBalancerRunning()
true
mongos> use config
switched to db config
mongos> db.settings.find()
{ "_id" : "chunksize", "value" : NumberLong(64) }
{ "_id" : "balancer", "stopped" : false }
И я обнаружил много ошибок moveChunk в журнале mogos, что может быть причиной того, что некоторые коллекции не сбалансированы, вот последняя часть из них:
2016-09-19T14:25:25.427+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:25:59.620+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:25:59.644+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:35:02.701+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:35:02.728+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:42:18.232+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:42:18.256+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:42:27.101+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:42:27.112+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
2016-09-19T14:43:41.889+0800 I SHARDING [conn37136926] moveChunk result: { ok: 0.0, errmsg: "Not starting chunk migration because another migration is already in progress", code: 117 }
Я попытался использовать команду moveChunk вручную, она возвращает ту же ошибку:
mongos> sh.moveChunk("bdtt.normal_20160913", {_id:ObjectId("57d6d107edac9244b6048e65")}, "shard3")
{
"cause" : {
"ok" : 0,
"errmsg" : "Not starting chunk migration because another migration is already in progress",
"code" : 117
},
"code" : 117,
"ok" : 0,
"errmsg" : "move failed"
}
Я не уверен, что слишком много созданных коллекций, которые вызывают миграцию перегружены? каждый день будет создаваться около 60-80 новых коллекций.
Мне нужна помощь здесь, чтобы ответить на вопросы ниже, любые советы будут отличными:
- Почему некоторые коллекции не сбалансированы, связано ли это с большим количеством вновь создаваемых коллекций?
- Есть ли какая-нибудь команда, которая может проверить детали выполнения заданий на миграцию? Я получил много журнала ошибок, который показывает, что работает какой-то миграционный джог, но я не могу найти который работает.
2 ответа
Ответьте на мой собственный вопрос: Наконец, мы нашли основную причину, это та же самая проблема с этим " тайм-аутом балансировщика MongoDB с задержкой реплики", вызванным неправильной настройкой набора реплик. Когда эта проблема возникает, наша реплика задает конфигурацию, как показано ниже:
shard1:PRIMARY> rs.conf()
{
"_id" : "shard1",
"version" : 3,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"host" : "10.25.8.151:27018",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "10.25.8.159:27018",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "10.25.2.6:37018",
"arbiterOnly" : true,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 3,
"host" : "10.47.114.174:27018",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : true,
"priority" : 0,
"tags" : {
},
"slaveDelay" : NumberLong(86400),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("5755464f789c6cd79746ad62")
}
}
Внутри набора реплик имеется 4 узла: один основной, один подчиненный, один арбитр и один задержанный на 24 часа подчиненный. это делает 3 узла большинством, так как у арбитра нет данных, балансировщику нужно дождаться задержанного ведомого, чтобы удовлетворить проблему записи (убедитесь, что осколок получателя получил чанк).
Есть несколько способов решить проблему. Мы только что удалили арбитр, теперь балансировщик работает нормально.
Я собираюсь предположить, но я предполагаю, что ваши коллекции очень несбалансированы и в настоящее время уравновешиваются миграцией фрагментов (это может занять много времени). Следовательно, ваша ручная миграция чанков ставится в очередь, но не выполняется сразу.
Вот несколько моментов, которые могли бы прояснить немного больше:
- Один чанк за раз: миграция чанков MongoDB происходит в механизме очереди, и переносится только один чанк за раз.
- Блокировка балансировки: информация о блокировке балансировки может дать вам более четкое представление о том, что переносится. Вы также должны быть в состоянии видеть записи журнала миграции блоков в ваших файлах журнала mongos.
Один из вариантов, который у вас есть, - предварительно разделить коллекции. Процесс предварительного разделения по существу настроил пустую коллекцию, чтобы начать балансировать и избежать дисбаланса в первую очередь. Потому что, как только они потеряют равновесие, процесс миграции фрагментов может оказаться не вашим другом.
Кроме того, вы можете вернуться к своим ключам шарда. Вы, вероятно, делаете что-то не так с вашими осколками, что вызывает большой дисбаланс.
Кроме того, мне кажется, что размер ваших данных не слишком велик, чтобы оправдать использование скрытой конфигурации. Помните, что никогда не делайте конфигурацию с разделением на сегменты, если вы не навязаны атрибутами размера данных / размера рабочего набора. Потому что шардинг не свободен (вы, вероятно, уже чувствуете боль).