MongoDB Replication Yapısını Anlayalım

Sistemin ve çalışma mantığının bir özeti

Merhaba, bu yazımda mongoDB’nin Replication yapısından bahsedeceğim. Veritabanı erişimi birçok sistemin yumuşak karnı (single point of failure) olabilir. Sistemin hem veritabanı bağlantılarında darboğaz (bottleneck) yaşamaması hem de veritabanı sunucusunun her an bize cevap dönebilecek durumda olması, bir sistem tasarlarken ilk hedeflerimizden biri olur. Replication yapısı mongo’nun buna sunduğu çözümlerden bir tanesi.

İçerik

• Replication ve Replica Set
• MongoDB Replication sistemini nasıl ele alıyor?
• Mongo Election sistemini nasıl ele alıyor?

Replication ve Replica Set

Adından da anlaşılabileceği üzere Replication, veri tabanınızın birden fazla kopyası ile hizmet verebilmesi. Mongo bu kopyaların bütünü Replica Set olarak adlandırıyor. Set içindeki replica sayısı değişiklik gösterebilse de temel mantık aynı: Gelen istekleri karşılamada öncelikli bir Primary eleman ve onun kopyaları olan Secondary elemanlar. Bir t anında hangi parçanın Primary hangilerinin secondary olabileceğinin değişiklik gösterdiği dinamik bir hiyerarşi söz konusu. Yazının ilerleyen kısımlarında primary ve secondary elemanların detaylarından ve bu dağılımın neye göre yapıldığından da bahsedeceğim.

MongoDB Replication sistemini nasıl ele alıyor?

Bu sistemi aşırı demokratik ve radikal küçük bir grup gibi düşünebiliriz. Grubun yöneticisi en ufak bir hatasında ihtilale kurban gidip yerini kaybediyor ve seçim yapılarak üyelerden biri yeni yönetici seçiliyor. Burada yöneticiyi Primary ve grubun kalanını Secondary elemanlar olarak düşünebiliriz.

Primary, sisteme gelen bütün write işlemlerini karşılama görevini tekelinde bulunduruyor. Replica set içerisinde write işlemlerini karşılayacak yalnızca bir tane primary eleman bulunabiliyor.

Primary kendisine gelen bütün istekleri bir oplog dosyasında tutuyor. Secondary elemanlar da belirli aralıklarla bu dosya sayesinde kendilerini senkronize ediyorlar. Yazma işlemleri tek yerden karşılanırken okuma işlemleri farklı elemanlar tarafından karşılanabiliyor. Bu da sistem üzerinde hem darboğazı azaltabiliyor, hem de bir sunucunun connection limitine ulaşmasını bir hayli geciktiriyor.

Sistemin elemanları her an birbirlerini denetlemekte. Bu denetimin sistemin elemanlarının belirli aralıklarla birbirlerine heartbeat (nabız) göndermesiyle sağlanıyor. Bu isteklere Primary elemanın her an cevap verebiliyor olması bekleniyor. Cevap veremediği anda liderlik için sırasını bekleyen secondary elemanlardan biri seçim başlatıp yeni primary seçilmeye çalışıyor.

Bazı durumlarda (özellikle faturaları azaltmak için), yalnızca bir adet primary ve bir adet secondary elemanla hizmet vermek isteyebiliriz. Ancak bu durumda seçime giren aday ve eski primary dışında oy kullanacak bir eleman kalmıyor. Bu noktada mongo’nun çözümü arbiter (arabulucu) elemanlar. Arbiter elemanlar verinin bir kopyasına sahip değiller, primary olmak gibi bir dertleri de yok. Yalnızca primary seçimlerine katılıp oy kullanıyor ve sonrasında kenarda sessizce oturmaya devam ediyor.

Buradaki arabulucumuz her zaman arabulucu olarak kalmaya devam ederken, primary ve secondary arasında rol değişiklikleri yaşanmaya devam ediyor.

Mongo election sistemini nasıl ele alıyor?

Primary elemanımız belirli bir süre sistemdeki diğer elemanlar ile iletişim kurmaz ise uygun bir secondary bir seçim başlatıp adaylığını koyuyor.

Primary’den alacağımız nabzın (heartbeat) süresini [electionTimeoutMillis] konfigürasyonu ile belirleyebiliyoruz. [electionTimeoutMillis] ayarının varsayılan değeri ise 10 saniye.

Replica set seçimler tamamlanana kadar yazma işlemlerini karşılayamıyor çünkü yazının önceki bölümünde de bahsettiğimiz üzere yazma işlemleri primary elemanın tekelinde. Eğer sisteminiz okuma işlemlerini secondary elemanlarının karşılayabileceği şekilde ayarlandıysa seçimler sırasında sisteme gelen okuma isteklerinde bir aksaklık yaşanmıyor. Mongo dokümantasyonunda belirtildiği üzere primary elemanın erişilmez olduğunu anlama ve seçimleri tamamlama işlemlerinin 12 saniyeden uzun sürmemesi bekleniyor. Yani en kötü senaryoda 12 saniyelik bir kaybımız var. Burada mongo’nun bu duruma getirdiği çözüm ise Retryable Writes.

MongoDB 3.6’dan itibaren mongo primary, elemanın düştüğünü anlayıp seçimler sırasında kaybettiğiniz bazı yazma işlemlerini seçimlerden sonra tekrar deneyerek veri kaybını önleyebilmekte. MongoDB 4.2’den itibaren varsayılan olarak açık olan retryable writes özelliği için önceki versiyonlarda connection string’inize [retryWrites=true] ayarını da eklemeniz gerekiyor. Aşağıdaki resimde desteklenen işlemleri görebilirsiniz.

Replication, Mongo’nun en temel konseptlerinden biri. Haliyle birçok şey ile de bağlantılı. Bu sebeple bir kere içine girdiğinizde çok fazla dallanıp budaklandığını göreceksiniz.

Bu yazıda sistemi ve çalışma mantığını anlayacağımız bir özet sunmaya çalıştım. Daha detaylı bilgi edinmek isterseniz mongo’nun dokümanları üzerinden burada değinemediğim birçok ayrıntıya ulaşabilirsiniz.

Sonraki yazılarda görüşmek üzere ✋