Güncelleme: Nisan 2018
Bu cevap soru sırasında doğruydu, ancak o zamandan beri işler devam ediyor. 3.4 sürümünden beri paralellik tanıtıldı ve başlangıçta referans verdiğim bilet kapatıldı. Daha fazla bilgi için bu daha yeni cevaptaki bazı ayrıntıları ele alacağım . Cevabın geri kalanını olduğu gibi bırakacağım çünkü genel konular / kısıtlamalar için iyi bir referans olmaya devam ediyor ve eski bir sürümdeki herkes için geçerli.
Orijinal Yanıt
Eğer ilgilenirseniz M202 Advanced kursunda yığın göçü ile ilgili neler olduğunu tam olarak açıklarım . Genel olarak, göçlerin aktif bir sistemde çalıştığından emin olmak için yapılan temizlikler nedeniyle, boş parçalar için bile göçlerin çok hızlı olmadığını söyleyelim (dengeleme dışında hiçbir şey olmasa bile bunlar hala gerçekleşir).
Ayrıca, tüm kümede aynı anda yalnızca bir göç gerçekleşir - paralellik yoktur. Yani, iki "dolu" düğümünüz ve iki "boş" düğümünüz olmasına rağmen, herhangi bir zamanda en fazla bir göç gerçekleşir (en çok parça olan kırık ile en az olan parça arasında). Bu nedenle, 2 parça eklediğinizde, dengeleme hızı açısından hiçbir şey kazanmazsınız ve sadece taşınması gereken parça sayısını artırır.
Taşımaların kendileri için, parçalar muhtemelen ~ 30MiB boyutundadır (verileri nasıl doldurduğunuza bağlıdır, ancak genellikle bu, varsayılan maksimum yığın boyutuyla ortalamanız olacaktır). Bu db.collection.getShardDistribution()bilgilerin bir kısmına başvurabilir ve parçalarınız hakkında daha fazla bilgi edinmenin yolları için cevabımı burada görebilirsiniz .
Devam eden başka bir etkinlik olmadığından, geçişin gerçekleşmesi için hedef parça (yeni eklenen parçalardan biri) kaynak parçalarından (orijinal 2'den biri) ~ 30MiB veri okumalı ve yapılandırma sunucularını yapıldıktan sonra yeni yığın konumunu yansıtır. 30MiB veri taşımak, yüksüz normal bir sistem için bir darboğaz olmamalıdır.
Yavaşsa, durumun böyle olmasının birkaç nedeni olabilir, ancak meşgul olmayan bir sistem için en yaygın olanları şunlardır:
- Kaynak Disk G / Ç - veriler okunduğunda etkin bellekte değilse, diskten disk belleği içine yerleştirilmelidir
- Şebeke - gecikme, hız sınırlaması, paket kaybı vb. Varsa, okuma işlemi biraz zaman alabilir
- Hedef Disk G / Ç - veriler ve dizinler diske yazılmalıdır, birçok dizin bunu daha da kötüleştirebilir, ancak genellikle bu hafif yüklü bir sistemde sorun değildir
- Durdurma ve başarısız taşıma işlemlerine neden olan taşıma işlemleriyle ilgili sorunlar (yapılandırma sunucularıyla ilgili sorunlar, ilkelerdeki silme işlemleriyle ilgili sorunlar)
- Çoğaltma gecikmesi - çoğaltma kümelerine geçişler için, endişe yazın
w:2veya w:majorityvarsayılan olarak kullanılır ve bunu karşılamak için güncel ikincil öğeler gerektirir.
Eğer sistem meşgulse bellek çekişmeseydi, kilit çekişmesi burada da şüpheli olurdu.
Taşıma işlemlerinin ne kadar sürdüğü, başarısız olmaları vb. Hakkında daha fazla bilgi edinmek için, aşağıdakilerdeki girişlere göz atın config.changelog:
// connect to mongos
use config
db.changelog.find()
Gördüğünüz gibi ve genellikle eğitim / öğretim yaptığımda insanlara söylediğim gibi, 4 parçaya ihtiyacınız olacağını biliyorsanız, genellikle rampa yerine 4 ile başlamak daha iyidir. Bunu yaparsanız, bir parça eklemenin uzun zaman alabileceğini ve başlangıçta kazançtan ziyade kaynaklar üzerinde net bir negatif olduğunu bilmeniz gerekir ( bunun daha ayrıntılı bir tartışması için parçalanan tuzaklar serimin II. Bölümüne bakın ).
Son olarak, yığın göçlerin paralelliğini artırmak için özellik talebini izlemek / yükseltmek / yorum yapmak için SERVER-4355'e bakın