MongoDB'deki büyük veri kümelerini yedeklemenin önerilen yolu nedir? Diyelim ki 10 TB'lik bir veri boyutumuz var - bunu nasıl yedeklersiniz?
Gizli, muhtemelen gecikmeli bir çoğaltma kümesi düğümü düşünüyoruz. Gecikme, bizi tüm veritabanının yanlışlıkla düşmesinden koruyacaktır. Bu uygun bir çözüm mü ve başka hangi seçenekleri araştırmanızı önerirsiniz?
Teşekkürler!
Yanıtlar:
10 TB'ın yedeklenmesi ihtiyacı ile bu biraz karmaşıklaşıyor.
Gecikmeli çoğaltma kümesi üyeleri, yanlışlıkla yapılan işlemlerde size yardımcı olmak için nispeten kolay bir yol sunsa da, RAID'in dosya sistemi tabanlı yedeklemelerin yerini almaması gibi, uygun yedeklemelerin yerini almaz.
Bu büyük ölçüde kurulumunuzun nasıl göründüğüne bağlıdır.
10 TB ile, bir çeşit SAN'ınız olduğunu varsayalım. MongoDB'yi bu ortamlarda yedeklemenin en kolay yolu, hem dosya sisteminde hem de MongoDB'de günlük kaydını etkinleştirdiğinizden emin olmak ve ikincil işlemlerden birinin SAN hacminin anlık görüntüsünü almaktır, işlemlerinizin don olduğundan emin olmak için kesintiye uğrama. Bu genellikle yalnızca birkaç saniye sürer, ancak lütfen çoğaltma oplog pencerenizin yeterli olduğundan emin olun. Aksi takdirde, ikincil sayfayı yeniden senkronize etmeniz gerekebilir.
Mongodump kullanımı hakkında RolandoMySQLDBA ile katılmıyorum. Her şeyden önce, sunucuya kilitler uygular. Nispeten hızlı bir şekilde kaldırılsalar da, gizli bir düğümde çalıştırılmadığı veya ikincil yerlere çarpan okuma tercihi olmadığında, çok sayıda kilit, işlemlerinizi toplayabilir ve müdahalelerinizi engelleyebilir. Artı, tam olarak hızlı değil. En azından, yedek pencerenizden daha uzun sürmesi için saatlerce çalışmasını beklerdim. Yan Not: Her zaman çalıştırmak mongodump --oplogseçeneği. Ayrıca mongodump'ın dizinleri değil, dizin oluşturma işlemlerini yedeklediğini unutmayın. Bu endekslerin bir geri yükleme sırasında yeniden oluşturulması gerekir, bu da bunun için ihtiyacınız olan zamanı büyük ölçüde artırabilir. Deneyimlerime göre, bir veritabanını geri yüklemeniz gerekiyorsa, mümkün olduğunca hızlı olmasını istersiniz. Mongodump'ın 10 TB'ı yedeklemek için neden uygun olmadığını bir başka nokta.
Mongod'da günlüğe kaydetmeyi etkinleştirmeniz koşuluyla, çalışan bir mongod örneğinde bir LVM anlık görüntüsü yapabilirsiniz (ve deneyimlerime göre, FS düzeyinde de etkinleştirilmesi zarar görmez). Bununla birlikte, LVM anlık görüntüleri bazı çıkarımlarla birlikte gelir. İlk olarak, yedekleme işlemleri sırasında değişiklikleri alabilecek yeterli disk alanına sahip olmanız gerektiği açıktır. Açıklığa kavuşturayım.
Saatte 500 GB'lık bir değişim oranınız olduğunu varsayalım. Ve yedeklemenin bir depolama alanına yüklenmeden önce blips edilmesini istersiniz. Paralel bzip2 kullanıldığında bile , 10 TB'lık sıkıştırmanın bitmesi için birkaç saat gerekir, çünkü büyük olasılıkla yığın depolama veriminiz sınırlayıcı faktörünüz olacaktır. Verileri 2 TB'a sıkıştırmanın 2 saat alacağını varsayalım. Şimdiye kadar toplam 2 TB + 2 * 500 GB boş disk alanına ihtiyacımız olacak, LVM anlık görüntüsü için 1 TB gerekli. Bu, dosya sisteminizi en azından% 30. Uygun bir güvenlik marjına sahip olmak istiyorsanız, bu kolayca% 60-70'e (orijinal dosya sistemi için 0,8 kullanım faktörü için% 20, anlık görüntü boyutu artı bzip yedeklemenin kendisi için gereken alan için) artabilir. ). Çoğu üretim ortamında, bu aşırı ön hazırlıkların statik olacağı için kabul edilemez (LVM'nizle dinamik olarak geçiş yapmak için bir yedek komut dosyası istemez miydiniz?).
MMS yedekleme bazı harika özelliklere (sürekli yedekleme, kolay zaman kurtarma) sahip olsa da, bazı ciddi dezavantajlar vardır: büyük dağıtımlar için fiyat etiketi binlerce olabilir. Bu 10 TB'lık saatte 500 GB'lık varsayılan değişim oranı ile, bulut yedeklemeleri için orta altı rakamlı bir toplam olur . Aylık.
Benim önerim , yedekleme dahil olmak üzere şirket içi bir MMS örneğine sahip olmak için sunucularınız için kurumsal bir abonelik almak olacaktır .
İşte azalan tercih sırasına göre alacağım seçenekler.
İki seçenek var
Kesinti sorununa dikkat etmezseniz, yapılacak en basit şey
service mongod stopcpMongo veri klasörünün LVM anlık görüntüsünü veya kaba kuvvetini başka bir diske yapın
service mongod startTabii ki, 10 TB veri bağımsız bir makinedeyse kesinti istemezsiniz.
Üç düğümlü bir çoğaltma kümeniz varsa, yedeklemeler için düğümlerden birini kullanın
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Düğümü "_id' : 3tüm fiziksel yedeklemelerinizle kullanın. Bu nedenle, kesinti yok. Bir gece yarısı anlık görüntüsü almak için, gizli düğüm 1 saat geride olduğundan yedeklemeyi 01: 00'da başlatabilirsiniz.
Tabii ki, dezavantajı her biri 10 TB ve sysadmin'in akıl sağlığı risk altında olan iki sunucu daha var.
Mongodump'ı bağımsız makineye karşı kullanabilirsiniz, ancak mongodump diğer bağlantılar gibi bir bağlantı kullanan bir istemci program olduğundan performans düşüşü beklemelisiniz.
Zamanında yedek almak istiyorsanız şunu kullanmalısınız:
mongodump --oplog Mantıksal BSON yedeklemesi fiziksel yedeklemeden daha küçük (özellikle gzip veya bzip) olacaktır.
Kullanımı mongodump --oplogen gizli düğüm karşı yapılırdı. Bu şekilde, Üstat'a performans düşmez.
MongoDB (kazara / arızi MongoDBA) için nispeten yeniyim. Umarım cevabım yardımcı olur.