Mongo neden STARTUP2'de takılı kalıyor?

13

MongoBirkaç ikincil ile bir çoğaltma seti var. İkincil bir örneği barındıran bir kutu, veritabanını kilitledi ve kaybetti.

İkincil Mongoörneği tekrar başlattım ve şimdi 12 saatten fazla STARTUP2'de kaldı. Mantıklı geliyor ? MongoBelge, RECOVERING durumuna girmeden önce kısa bir süre için STARTUP2 içinde olması gerektiğini söylüyor

STARTUP2 tam olarak ne anlama geliyor? Veritabanını birincil kopyadan mı alıyor? Bunu nasıl doğrulayabilirim (Mongo'nun Linux'ta çalıştığını varsayarak)?

mongodb recovery

— Michael
kaynak

12

Eeobrazilin cevabı kısmen yanlıştır. Yeni bir Düğüm uzun süre STARTUP2'de olabilir. Yayınlanan bağlantı şöyle diyor:

Bir çoğaltma kümesinin her üyesi, mongod bu üyenin yapılandırmasını yüklemeyi bitirir bitirmez STARTUP2 durumuna girer ve bu sırada çoğaltma kümesinin etkin bir üyesi olur. Daha sonra üye bir ilk senkronizasyon yapıp yapmayacağına karar verir. Bir üye ilk eşitlemeyi başlatırsa, tüm veriler kopyalanıp tüm dizinler oluşturulana kadar üye STARTUP2'de kalır. Daha sonra üye RECOVERING'e geçer.

700 GB'lık bir koleksiyon yönetiyorum ve yeni bir düğüm eklediğimde STARTUP2 durumu 24 saatin üzerinde. Ancak yine de, veritabanının büyüyüp büyümediğini izleyerek bir şey olup olmadığını görebilirsiniz. İle yeni düğümde veritabanının boyutunu görebilirsiniz.

show databases

veya veri dizini hala büyüyüp büyümediğini görmek için gözlemleyebilirsiniz. (Linux üzerinde ls, df, du, iotop, vb. komutları ile ....)

— Kenyakorn Ketsombut
kaynak

1

show databasesbaşarısıznot master and slaveOk=false

— JDPeckham

Günlüklere bakarak ilerlemeyi görebilirsiniz. Örneğin şöyle bir şey gösterecektir: [rsSync] Dizin Oluşturma: 2538000/22982417% 11

— Daniel Benedykt

4

STARTUP2 durumu, düğümün oy kullanamayacağı anlamına gelir. Bir RS üyesi, MongoD işlemi yapılandırmasını yüklemeyi tamamladığında bu duruma girer. Bu durumda, üye iç çoğaltma işlemlerini gerçekleştirmek için iş parçacıkları oluşturmuştur, ancak henüz durumu Kurtarmaya ve bundan İkincil'e değiştirmemiştir (bkz. [Durum ve dokümanlardaki ayrıntıları]) .

Düğümünüz kısa bir süreden daha uzun bir süredir bu durumda ise, tuhaf bir davranışla karşılaşıyorsunuz. Bunun neden sıkıştığını belirlemek için günlükler olmadan analiz etmek neredeyse imkansızdır. Rs.status () ve db.printSlaveReplicationInfo () çalıştırıldığında, düğümdeki yerel resim hakkında bazı ayrıntılar verilir.

Bunu çözmek için normal yaklaşım düğümü kapatmak, veri dosyalarını (dbpath dosyasındaki) silmek ve yeniden başlatmak olacaktır. Bu, ilk senkronizasyon işlemini yeniden başlatacak ve SECONDARY konumuna taşınmalıdır. Tekrar STARTUP2'de takılı kalırsa, nedeniyle ilgili daha fazla bilgi toplamak için günlüklere bakmanız gerekir - bir dizi neden vardır, ancak olabilecek bir kesintili ağ veya bazı yerel kaynak çekişmesidir.

Dikkat edilmesi gereken bir nokta, bir ilk senkronizasyon devam ederken düğümün STARTUP2'de kalacağıdır, bu nedenle senkronize edilen veri miktarına bağlı olarak bu önemli bir süre (potansiyel günler) olabilir.

— eoinbrazil
kaynak

Teşekkürler. Verileri kaldırdık ve Moğol'u yeniden başlattık. Hâlâ STARTUP2 konumunda. Moğol çalışıyor gibi görünüyor. CPU tüketiyor ve db.statsveritabanında gördüğüm gibi büyüyor. Günlük bazı nesneler söylüyor cloned. Hala bu sorunun olası nedenlerini arıyorum.

— Michael

1

Bu hala bir sorunsa , başka bir düğümden bir kopya yapmak isteyebilirsiniz (bu prosedüre bakın - docs.mongodb.org/manual/tutorial/resync-replica-set-member/… ). Günlükleri vurguladığınız sürümleri ve hangi sürümü kullandığınıza dair ayrıntılar ekleyebiliyorsanız, bunun bir nedeni olabilir, ancak aynı şekilde olağandışı davranıştır. Ağ gecikmesinin nasıl olduğunu görmek için düğümler arasında ping işlemi yapmayı denediniz mi?

— eoinbrazil

pingEv sahipleri arasında Moğol 2.4.6 ok.

— Michael

Kesintili ağ sorunları olabileceğinden ping süreleri nasıl? Bu durumda, standart olmayan bir davranış olduğundan ve tam olarak ne olduğunu belirlemeye çalışırken günlükler asıl hakikat kaynağı olduğundan, günlük çıktılarından bazılarını ekleyebilmeniz çok daha kolaydır.

— eoinbrazil

Korkarım ki günlükleri burada gösteremem. Ancak, başka bir ikincil üyeye bağlanmaya çalıştığını fark ettim. Sorunun nedeni bu olabilir mi?

— Michael

1

Olası nedenlerden biri, ikincinizin burada belirtildiği gibi "bayat" hale gelmesidir .

Bir üyeyi yeniden senkronize ederken, RS'nin ağır yük altında olmadığından emin olun.

— user2829759
kaynak

0

STARTUP2 durumunun yetersiz disk alanı olabilir. Senkronize edilecek yer olmadığından, yalnızca @ STARTUP2 durumunda kalabilir.

— Ezop Lee
kaynak