Ubuntu'ya MongoDB Nasıl Kurulur

Giriş

MongoDB, esnek veri yapıları, yüksek ölçeklenebilirlik ve hızlı performans gerektiren uygulamalar için yaygın olarak kullanılan en popüler açık kaynaklı NoSQL veritabanlarından biridir. Verileri, JSON benzeri nesneler kullanarak belge odaklı bir formatta saklar, bu da onu modern web, mobil ve analitik iş yükleri için ideal hâle getirir. Geliştiriciler, dinamik şeması, otomatik parçalama (sharding) ve yatay ölçeklenmeyi ve yüksek kullanılabilirliği destekleyen yerleşik çoğaltma (replication) özellikleri nedeniyle MongoDB'yi tercih eder. Ubuntu'nun sunduğu kararlılık ve güvenlikle birleştirildiğinde, MongoDB güvenilir ve verimli veritabanı tabanlı uygulamaları çalıştırmak için güçlü bir temel sağlar.

Bu makalede, MongoDB 8.2'yi Ubuntu 24.04 LTS üzerinde nasıl kuracağımızı, yapılandıracağımızı ve bakımını yapacağımızı açıklıyoruz. Sunucuyu hazırlamaktan güvenlik özelliklerini etkinleştirmeye, performansı optimize etmeye, çoğaltma ve yedekleme ayarlarını yapmaya ve yaygın sorunları gidermeye kadar her temel adımı ele alıyoruz. Makalenin sonunda, uzun vadeli kullanım için düzgün bir şekilde güvence altına alınmış, izlenen ve optimize edilmiş üretime hazır bir MongoDB dağıtımına sahip olacaksınız. MongoDB'yi geliştirme, test veya tam üretim ortamı için kuruyor olun, bu kılavuz etkin bir şekilde çalıştırmak için gereken ayrıntılı talimatlar ve operasyonel en iyi uygulamaları sunar.

Önkoşullar

Bu eğitimi takip etmek için ihtiyacınız olacak:

• Ubuntu 24.04 LTS çalıştıran bir sunucu. Bu sunucuda yönetici ayrıcalıklarına sahip kök olmayan bir kullanıcı ve UFW (Basit Güvenlik Duvarı) kurulu ve yapılandırılmış olmalıdır. Bunu kurmak için Ubuntu ile Başlangıç Sunucu Kurulum Rehberimize başvurun.

MongoDB'yi Resmi Depodan Yükleme

Ubuntu 24.04, varsayılan paket depolarında bir MongoDB sürümü içerir, ancak genellikle güncel değildir. Üretim sistemleri için MongoDB'yi her zaman resmi MongoDB deposundan doğrudan yüklemelisiniz. Bu, en güncel kararlı sürümü (yazının yazıldığı sırada 8.2) ve zamanında güvenlik ile bakım güncellemelerini almanızı sağlar.

MongoDB deposunu sisteminizin APT kaynaklarına ekleyelim, paketleri doğrulamak için kullanılan GPG anahtarını içe aktaralım ve ardından veritabanını kuralım.

1. MongoDB GPG Anahtarını İçe Aktarın

APT, paketlerin doğruluğunu doğrulamak için GPG anahtarlarını kullanır. Bunu yapmadan, sisteminiz MongoDB deposuna güvenmez.

MongoDB 8.0 için açık anahtarı içe aktarmak üzere aşağıdaki komutu çalıştırın:

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

Bunun yaptığı şey şöyle:

• curl -fsSL MongoDB’nin resmi sunucularından GPG anahtarını sessizce alır.
• --dearmor, anahtarı ASCII-armored formatından APT ile uyumlu ikili anahtar halkası formatına dönüştürür.
• Çıktı, güvenilen anahtarlar için standart bir konum olan /usr/share/keyrings/mongodb-server-8.0.gpg dosyasına kaydedildi.

Komut hatasız tamamlanırsa, anahtar başarıyla eklenmiş demektir.

2. MongoDB Deposu Ekle

Sonraki adım olarak, Ubuntu 24.04 (“Noble”) için MongoDB’nin resmi paket kaynağına işaret eden yeni bir depo listesi dosyası oluşturun.

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.2.list

Bu komutun her bir parçası belirli bir amaca hizmet eder:

• deb, APT’ye bunun ikili paket deposu olduğunu söyler (kaynak kodu için deb-src’e karşılık).
• arch=amd64,arm64 bu, MongoDB tarafından desteklenen 64-bit Intel/AMD ve ARM mimarileri ile sınırlıdır.
• signed-by=..., APT’nin indirmeleri doğrulamak için belirtilen MongoDB anahtarını (yukarıda eklenen) kullanmasını sağlar.
• https://repo.mongodb.org/apt/ubuntu, MongoDB’nin resmi APT deposunun temel URL’sidir.
• noble/mongodb-org/8.2, hem Ubuntu sürüm kod adını (noble=Ubuntu 24.04) hem de MongoDB sürümünü (8.2) belirtir.
• multiverse, üçüncü taraf yazılımlar için Ubuntu bileşen bölümüdür.

3. Paket Dizininizi Güncelleyin

Yeni bir depo ekledikten sonra, APT’nin yeni kaynağı tanıyabilmesi için sisteminizin yerel kullanılabilir paket listesini yenilemeniz gerekir:

sudo apt update

APT en son paket listelerini indirecek ve bunları GPG anahtarı ile doğrulayacaktır. Depolar arasında MongoDB'yi görüyorsanız, yapılandırmanız doğru demektir.

4. MongoDB'yi Kur

Şimdi MongoDB ve ilgili araçlarını yükleyin:

sudo apt install -y mongodb-org

-y bayrağı, kurulum istemlerini otomatik olarak onaylar.

Bu, şunları içeren bir dizi ilişkili paketi kuracaktır:

• mongodb-org-server: Veritabanı depolama ve işlemlerinden sorumlu MongoDB sunucu servisi (mongod).
• mongodb-org-mongos: Dağıtık kurulumlarda kullanılan sharding yönlendiricisi.
• mongodb-org-shell: MongoDB'ye bağlanmak için kullanılan etkileşimli komut satırı istemcisi (mongosh).
• mongodb-org-tools: Yedekleme ve geri yükleme araçları (mongodump, mongorestore, bsondump, vb.).

Kurulduktan sonra, ikili dosyalar /usr/bin/ altında, yapılandırma dosyaları ise /etc/mongod.conf konumunda bulunur.

5. Kurulumu Doğrulayın

MongoDB 8.2'nin başarıyla yüklendiğini sürümünü kontrol ederek doğrulayabilirsiniz:

mongod --version

Aşağıdakine benzer bir çıktı görmelisiniz:

db version v8.2.3
Build Info: {
    "version": "8.2.3",
    "gitVersion": "36f41c9c30a2f13f834d033ba03c3463c891fb01",
    "openSSLVersion": "OpenSSL 3.0.13 30 Jan 2024",
    "modules": [],
    "allocator": "tcmalloc-google",
    "environment": {
        "distmod": "ubuntu2404",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

Bunu görüyorsanız, MongoDB doğru şekilde kurulmuş demektir ve bir hizmet olarak başlatılmaya hazırdır.

MongoDB Servisini Başlatma ve Yönetme

Ubuntu'ya MongoDB kurduğunuzda, paket otomatik olarak systemd servis birimi adı verilen mongod.servicei içerir. Bu entegrasyon, MongoDB’nin Ubuntu’nun standart servis yönetim komutlarını kullanarak Nginx, PostgreSQL veya diğer büyük daemon’lar gibi temiz bir şekilde başlatılmasını, durdurulmasını ve yeniden başlatılmasını sağlar.

MongoDB Servisini Başlat

Varsayılan olarak, MongoDB kurulumdan sonra otomatik olarak başlamaz. Manuel olarak başlatmak için aşağıdaki komutu kullanın:

sudo systemctl start mongod

Komut hata vermeden çalışırsa, servis şimdi aktif olmalıdır. Şunu kullanarak doğrulayabilirsiniz:

sudo systemctl status mongod

Örnek çıktı:

● mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: active (running) since Tue 2026-01-06 07:08:28 UTC; 5s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 12462 (mongod)
     Memory: 195.4M (peak: 277.1M)
        CPU: 739ms
     CGroup: /system.slice/mongod.service
             └─12462 /usr/bin/mongod --config /etc/mongod.conf

Satır “Active: active (running)” veritabanının çalışır durumda olduğunu ve işlevsel olduğunu doğrular.

Bunun yerine "başarısız" veya "etkin değil" görüyorsanız, sorun gidermek için MongoDB Günlüklerini Kontrol Etme bölümüne geçin.

MongoDB'nin Başlangıçta Çalışmasını Etkinleştir

Çoğu üretim sistemi, veritabanının yeniden başlatmadan sonra otomatik olarak başlamasını gerektirir. MongoDB'nin açılışta başlatılmasını sağlamak için şu komutu çalıştırın:

sudo systemctl enable mongod

Bu, /etc/systemd/system/multi-user.target.wants/ dizininde bir sembolik bağlantı oluşturur ve systemd'ye sistem çok kullanıcılı moda girdiğinde hizmeti otomatik olarak başlatmasını söyler (sunucular için standart işletim modu).

Değişikliği şu şekilde onaylayabilirsiniz:

systemctl is-enabled mongod

Beklenen çıktı:

enabled

Otomatik başlatmayı devre dışı bırakmak isterseniz (bakım veya test için), şunu kullanın:

sudo systemctl disable mongod

MongoDB İşlemini Doğrula

MongoDB çalışmaya başladıktan sonra, düzgün yanıt verip vermediğini doğrulamak iyi bir fikirdir.

Veritabanına bağlanmak ve bağlantı durumunu kontrol etmek için aşağıdaki komutu çalıştırın:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Bu komut:

• Geçici bir kabuk oturumu açar (mongosh, eski mongo istemcisinin yerini alan yeni MongoDB kabuğudur).
• connectionStatus komutunu doğrudan yerel örneğe karşı çalıştırır.
• Bağlantı sonucunu, kabukta kalmanızı gerektirmeden gösterir.

Örnek çıktı:

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('be686f2a-9cb3-41c1-aad2-8849367de4e5'),
  ok: 1
}

"ok": 1 değeri, sunucunun düzgün çalıştığını ve 27017 portundan bağlantıları kabul ettiğini doğrular.

MongoDB Servis Yaşam Döngüsünü Yönetin

MongoDB'nin çalıştığını doğruladıktan sonra, günlük işlemlerde onu güvenli bir şekilde nasıl yöneteceğinizi bilmek faydalıdır.

İşte temel komutlar:

sudo systemctl stop mongod

sudo systemctl start mongod

sudo systemctl restart mongod

sudo systemctl reload mongod

sudo systemctl disable mongod

sudo systemctl status mongod

Servisi yeniden başlatmak (restart), /etc/mongod.conf'i düzenledikten sonra özellikle önemlidir. Bu, yapılandırma değişikliklerinizin yüklenmesini sağlar.

MongoDB Kayıtlarını Kontrol Etme

MongoDB başlatılamazsa veya beklenmedik şekilde davranırsa, ilk hata gidermeye yönelik adımınız logları kontrol etmek olmalıdır.

MongoDB günlükleri şurada bulunur:

/var/log/mongodb/mongod.log

Son 20 satırı şu şekilde görüntüleyebilirsiniz:

sudo tail -n 20 /var/log/mongodb/mongod.log

Yaygın günlük mesajları şunları içerir:

• "27017 numaralı portta bağlantılar bekleniyor": MongoDB başarıyla başlatıldı ve hazır.
• "Veri dizini /var/lib/mongodb bulunamadı": Veri yolunun mevcut olduğunu ve doğru izinlere sahip olduğunu kontrol edin.
• "Adres zaten kullanımda": Başka bir işlem zaten 27017 numaralı portu kullanıyor.
• "İzin reddedildi": MongoDB kullanıcısının (mongodb) veri ve günlük dizinlerinin sahibi olduğundan emin olun.

Ayrıca journalctl komutunu kullanarak systemd tarafından yönetilen hizmete özel kayıtları görebilirsiniz:

sudo journalctl -u mongod --since "5 minutes ago"

Sistem Başlangıcında MongoDB'yi Test Etme

MongoDB'nin yeniden başlatmadan sonra otomatik olarak başladığını doğrulamak iyi bir uygulamadır, özellikle uygulamaları dağıtmadan önce.

Yeniden başlatmak için şunu çalıştırın:

sudo reboot

Sunucunuz yeniden başladıktan sonra tekrar giriş yapın ve servisi kontrol edin:

sudo systemctl status mongod

Eğer “active (running)” gösteriyorsa, yapılandırmanız doğru ve kalıcıdır.

MongoDB Yapılandırma Ayarlarını Anlamak

MongoDB'yi kurduğunuzda, davranışı /etc/mongod.conf konumunda bulunan tek bir yapılandırma dosyası tarafından kontrol edilir.

Bu dosya MongoDB'nin nasıl çalıştığını tanımlar: verileri nerede depoladığından, etkinlikleri nasıl kaydettiğine, hangi IP adreslerini dinlediğine ve hangi güvenlik mekanizmalarının aktif olduğuna kadar her şeyi. Bu dosyayı anlamak çok önemlidir, özellikle MongoDB'yi prodüksiyonda çalıştırmayı planlıyorsanız. Bu dosyadaki ayarlar, karşılık gelen komut satırı seçeneklerine eşdeğerdir, ancak bir yapılandırma dosyası kullanmak, özellikle daha büyük veya otomatikleştirilmiş dağıtımlar için sunucu yönetimini daha basit hale getirir.

Yapılandırma Dosyasının Genel Görünümü

MongoDB’nin yapılandırma dosyası, girintiye duyarlı olan YAML sözdizimini kullanır. Bu, düzenlerken sekme tuşu yerine boşluk kullanmanız gerektiği anlamına gelir; yanlış yerleştirilmiş bir boşluk bile yapılandırmayı bozabilir.

Dosyanın mevcut içeriğini şu şekilde görüntüleyebilirsiniz:

sudo cat /etc/mongod.conf

Varsayılan dosya şöyle görünür:

# mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Bunu bölüm bölüm inceleyelim.

storage Bölümü

Bu bölüm, MongoDB'nin verilerini nerede depoladığını ve veri kalıcılığını sağlayan günlüğe kaydetmeyi nasıl yönettiğini tanımlar.

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

• dbPath: Bu, MongoDB'nin veritabanlarını, koleksiyonlarını ve indekslerini depoladığı dizindir. Varsayılan olarak /var/lib/mongodb konumunu gösterir. Bu yolu değiştirirseniz, dizinin mevcut olduğundan ve mongodb kullanıcısına ait olduğundan emin olun:

  sudo mkdir -p /data/mongodb
  
  sudo chown -R mongodb:mongodb /data/mongodb

• journal.enabled: true olarak ayarlandığında, MongoDB çökme veya beklenmedik kapanmalardan sonra kurtarmaya yardımcı olan bir günlük dosyası tutar. Günlükleme, verileri veri dosyalarına işlemden önce ayrı bir günlükte yazarak bozulmaları önler. Üretim sistemlerinde her zaman bu özelliği etkin tutun.

systemLog Bölümü

Bu, MongoDB'nin günlüklerini nasıl ve nereye yazacağını kontrol eder.

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

• destination: Günlüklerin nereye yazılacağını belirtir. Varsayılan değer file, günlükleri bir dosyaya yazar; MongoDB günlüklerini sistem günlüklerinizle entegre etmek isterseniz bunu syslog olarak değiştirebilirsiniz.
• logAppend: true olduğunda, MongoDB yeniden başlatıldığında mevcut dosyanın üzerine yazmak yerine yeni günlük girişlerini mevcut dosyaya ekler.
• path: Günlük dosyasının mutlak yolu.

Günlükleri doğrudan şunlarla görüntüleyebilirsiniz:

sudo tail -f /var/log/mongodb/mongod.log

Eğer kayıtlarınız çok büyük hale gelirse, logrotate gibi bir araçla günlük döndürmeyi etkinleştirmeyi veya sistem günlüklerinizin otomatik olarak döndürülmesini yapılandırmayı düşünebilirsiniz.

net Bölümü

Bu bölüm, MongoDB'nin gelen ağ bağlantılarını nasıl dinlediğini tanımlar.

net:
  port: 27017
  bindIp: 127.0.0.1

• port: Varsayılan MongoDB portu 27017'dir. Aynı sunucuda birden fazla veritabanı servisi çalıştırıyorsanız bunu değiştirebilirsiniz.
• bindIp: Bu, MongoDB'nin hangi ağ arayüzlerini dinleyeceğini kontrol eder.

Varsayılan olarak, yalnızca 127.0.0.1 (yerel döngü adresi) ile sınırlıdır, yani yalnızca yerel bağlantılara izin verilir. Bu, uzaktan erişimi açıkça izin verene kadar engelleyen kritik bir güvenlik varsayılanıdır.

Başka bir makineden (örneğin bir web sunucusu veya uzak bir uygulama) bağlanmayı planlıyorsanız, bunu şu şekilde değiştirebilirsiniz:

bindIp: 127.0.0.1,192.168.1.100

Veya tüm arayüzlerde dinlemek için (canlı ortamda dikkatli kullanın):

bindIp: 0.0.0.0

security Bölümü

MongoDB varsayılan olarak kimlik doğrulama devre dışı bırakılarak kurulur. Veritabanına bağlanabilen herkes verileri okuyabilir veya değiştirebilir. Bu test için sorun olmaz, ancak gerçek bir sistem için bir güvenlik tehditidir. Kullanıcı tabanlı kimlik doğrulamayı etkinleştirmek için aşağıdaki bölümü ekleyin:

security:
  authorization: enabled

Bunu etkinleştirdiğinizde, MongoDB kullanıcıların işlemleri gerçekleştirmeden önce bir kullanıcı adı ve şifre ile kimlik doğrulaması yapmasını gerektirecektir.

Bu bölümdeki diğer isteğe bağlı ayarlar şunları içerir:

• keyFile: Küme düğümleri arasında kimlik doğrulaması yapmak için replikasetlerde kullanılır.
• javascriptEnabled: Sunucu tarafı JavaScript yürütmesini etkinleştirir veya devre dışı bırakır (gerekmiyorsa devre dışı bırakılması önerilir).

processManagement Bölümü

Bu bölüm, MongoDB'nin işlem yönetimi ve çalışma zamanı bilgilerini nasıl ele aldığını kontrol eder.

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Bu çoğunlukla bilgilendirme amaçlıdır; MongoDB'nin zaman damgası dönüşümleri için zaman dilimi verilerine erişimini sağlar. Gelişmiş kurulumlarda, MongoDB manuel olarak systemd olmadan başlatılırsa, burada forking'i (arka planda çalışma için) etkinleştirebilirsiniz.

Yinelenme ve Parçalama Bölümleri (İsteğe Bağlı)

Bu bölümleri temiz bir kurulumda görmezsiniz, ancak çok düğümlü veya dağıtık kurulumlarda kullanılırlar.

Bir replika setini etkinleştirmek için örnek:

replication:
  replSetName: "rs0"

Bu, MongoDB'ye rs0 adlı bir replikasetikin parçası olarak başlamasını söyler. Daha sonra MongoDB kabuğu içinden başlatıp üyeleri ekleyebilirsiniz.

Sharding için:

sharding:
  clusterRole: "shardsvr"

Bu, düğümün parçalanmış bir kümedeki rolünü tanımlar.

setParameter Bölümü

Bu isteğe bağlı bölüm, MongoDB’nin davranışını ince ayarlamak için çalışma zamanı parametrelerini geçersiz kılmanıza olanak tanır.

Örnek :

setParameter:
  enableLocalhostAuthBypass: false

Bunu false olarak ayarlamak, localhost bağlantıları da dahil olmak üzere tüm bağlantıların kimlik doğrulaması gerektirmesini sağlar. Diğer parametreler ise sorgu zaman aşımlarını, imleç davranışını veya tanılama kayıtlarını kontrol edebilir.

Değişiklik Yapma ve Uygulama

/etc/mongod.conf dosyasını her değiştirdiğinizde, değişikliklerin uygulanabilmesi için MongoDB'yi yeniden başlatmanız gerekir:

sudo systemctl restart mongod

Sonra servisin çalıştığını doğrulayın:

sudo systemctl status mongod

MongoDB yeniden başlatılamazsa, sözdizimi hatalarını kontrol edin (YAML girintisi hataları yaygındır) veya günlükleri inceleyin:

sudo tail -n 20 /var/log/mongodb/mongod.log

Örnek: Güvenli ve Üretime Hazır Bir Yapılandırma

İşte Ubuntu 24.04 için temiz ve üretim odaklı bir mongod.conf örneği:

# mongod.conf — Example production configuration

storage:
  dbPath: /data/mongodb
  journal:
    enabled: true
  engine: wiredTiger

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.10

security:
  authorization: enabled
  javascriptEnabled: false

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

replication:
  replSetName: "rs0"

setParameter:
  enableLocalhostAuthBypass: false

Bu yapılandırma:

• Kimlik doğrulamayı etkinleştirir
• WiredTiger'ı (varsayılan depolama motoru) kullanır
• Sadece belirli güvenilir arayüzlere bağlanır
• Örneği replica set başlatımı için hazırlar
• Tüm işlemleri özel bir günlük dosyasına kaydeder

MongoDB'yi Güvenli Hale Getirme

MongoDB’nin esnekliği onu güçlü kılar, ancak bu durum aynı zamanda güvensiz bir kurulumun veri sızıntısına kolayca yol açabileceği anlamına gelir. MongoDB’nin ilk dönemlerinde, birçok sunucu doğrulama olmadan internete açık bırakılmıştı ve bu da saldırganların sadece 27017 portuna bağlanarak veritabanlarını listelemesine, değiştirmesine veya hatta silmesine olanak tanıyordu.

Bugün, MongoDB daha güvenli varsayılanlarla geliyor, ancak kimlik doğrulama, ağ kısıtlamaları ve şifrelemeyi uygulamak hâlâ sizin sorumluluğunuzda.

Kimlik Doğrulamayı Etkinleştirme

Varsayılan olarak, MongoDB kimlik doğrulama devre dışı olarak başlar. Bu, veritabanına bağlanabilen herhangi bir kişinin yönetici komutlarını çalıştırabileceği, koleksiyonları silebileceği veya verileri sınırlama olmaksızın değiştirebileceği anlamına gelir. Bunu önlemek için, MongoDB açıkça etkinleştirdiğiniz bir Rol Tabanlı Erişim Kontrolü (RBAC) sistemi kullanır.

1. MongoDB yapılandırma dosyasını açın:

   sudo nano /etc/mongod.conf

2. security bölümünü bulun veya mevcut değilse bir tane oluşturun:

   security:
     authorization: enabled

3. Kaydet ve çık (Ctrl+O, ardından Ctrl+X).

4. Değişikliğin geçerli olması için MongoDB'yi yeniden başlatın:

   sudo systemctl restart mongod

MongoDB, yeni bir kurulumda ilk yönetici kullanıcı oluşturulabilmesi için geçici bir localhost kimlik doğrulama atlaması sağlar. Bu atlama, bir yönetici kullanıcı var olduğunda veya belirli güvenlik ayarları (örneğin keyFile veya clusterAuthMode) etkinleştirildiğinde otomatik olarak devre dışı bırakılır.

Bu, tam uygulanma başlamadan önce ilk yönetici kullanıcıyı güvenle oluşturabileceğiniz anlamına geliyor.

İlk Yönetici Kullanıcısını Oluşturma

Admin kullanıcısı, MongoDB’nin kimlik doğrulama sisteminin temelidir. Diğer kullanıcıları oluşturma, roller tanımlama ve belirli veritabanlarına erişim verme iznine sahiptir.

Bu hesabı oluşturmak için:

1. Yerel bir MongoDB kabuğu başlatın:

   mongosh

2. admin veritabanına geçin; bu veritabanı kullanıcı kimlik bilgilerini ve rol tanımlarını saklar:

   use admin

3. Kullanıcıyı aşağıdaki komutla oluşturun:

   db.createUser({
     user: "admin",
     pwd: "StrongPasswordHere",
     roles: [
       { role: "userAdminAnyDatabase", db: "admin" },
       "readWriteAnyDatabase"
     ]
   })

   Bunu parçalayalım:

   • userAdminAnyDatabase, bu kullanıcının tüm veritabanlarında kullanıcı oluşturmasına, değiştirmesine ve kaldırmasına izin verir.
   • readWriteAnyDatabase, genel olarak okuma ve yazma izinleri verir. (İsterseniz, yalnızca yönetici için daha katı bir kullanıcı oluşturmak üzere bunu atlayabilirsiniz.)

   Bu komut, MongoDB’nin admin veritabanı içindeki system.users koleksiyonuna yeni bir belge yazar. Bunu, kullanıcıları listeleyerek doğrulayabilirsiniz:

   show users

4. Shell'den çık:

   exit

5. Kimlik doğrulamanın artık zorunlu olduğunu doğrulamak için yönetici kullanıcısı olarak tekrar bağlanın:

   mongosh -u admin -p --authenticationDatabase admin

Kimlik doğrulaması yapıldıktan sonra, şu gibi yönetici komutlarını çalıştırabilirsiniz:

show dbs

MongoDB parola sorarsa ve sadece kimlik doğrulamasından sonra erişim sağlarsa, RBAC doğru şekilde çalışıyor demektir.

Uygulamalar için Rol Tabanlı Kullanıcılar Oluşturma

Prodüksiyon ortamında, uygulamanız asla yönetici hesabını kullanmamalıdır. Bunun yerine, her uygulama için yalnızca ihtiyaç duyduğu izinlere sahip özel kullanıcılar oluşturun.

Örneğin, belirli bir veritabanındaki verileri yöneten bir web uygulaması için kullanıcı oluşturmak:

use myappdb
db.createUser({
  user: "appuser",
  pwd: "AppPassword123",
  roles: [ { role: "readWrite", db: "myappdb" } ]
})

• readWrite, uygulamanın yalnızca bu veritabanında tüm standart CRUD işlemlerini (ekleme, sorgulama, güncelleme, silme) gerçekleştirmesine olanak tanır.
• Diğer kullanıcıları oluşturamaz, sistem koleksiyonlarını değiştiremez veya diğer verilere erişemez.

Bir veritabanındaki tüm kullanıcıları şu şekilde listeleyebilirsiniz:

show users

Ağ Erişimini Kısıtlama

Kimlik doğrulama etkinleştirilmiş olsa bile, MongoDB'yi açık internete maruz bırakmak tehlikelidir. Otomatik tarayıcılar düzenli olarak açık portları (özellikle 27017, varsayılan MongoDB portu) arar ve zorla giriş saldırıları yapmaya veya yanlış yapılandırılmış örneklerden faydalanmaya çalışır.

Varsayılan olarak, MongoDB yalnızca yerel arayüz olan 127.0.0.1 üzerinde dinler. Uygulamalarınız ve MongoDB sunucunuz aynı sunucuda ise, herhangi bir şeyi değiştirmenize gerek yoktur. Ancak, uygulamanız uzaktan bağlanıyorsa, belirli IP adreslerini açıkça beyaz listeye almanız gerekir.

1. Yapılandırma dosyasını düzenleyin:

   sudo nano /etc/mongod.conf

2. net bölümünü bulun ve güncelleyin:

   net:
     port: 27017
     bindIp: 127.0.0.1,192.168.10.50

   192.168.10.50 adresini güvenilir uygulama sunucunuzun IP adresi ile değiştirin. Bu, MongoDB’nin yalnızca localhost ve o belirli uzak sunucudan gelen bağlantıları kabul etmesini sağlar.

3. Değişikliklerin uygulanması için servisi yeniden başlatın:

   sudo systemctl restart mongod

4. Aktif bağlantıları onaylayın:

   sudo ss -tulpn | grep mongod

MongoDB'nin hem 127.0.0.1:27017 hem de belirttiğiniz IP adresinde dinlediğini görmelisiniz.

Ubuntu Güvenlik Duvarını (UFW) Yapılandırma

MongoDB sadece belirli arayüzlerde dinlese bile, ağ güvenliğini işletim sistemi düzeyinde güçlendirmek en iyi uygulamadır.

Ubuntu’nun UFW’si, gelen ve giden bağlantıları kontrol etmenin kolay bir yolunu sunar.

1. UFW'nin yüklü ve aktif olduğunu doğrulayın:

   sudo ufw status

   Eğer devre dışı olarak görünüyorsa, etkinleştirin:

   sudo ufw enable

2. MongoDB bağlantılarına yalnızca güvenilen IP’lerden izin verin. Örneğin, uygulama sunucunuzun IP’si 192.168.10.50 ise:

   sudo ufw allow from 192.168.10.50 to any port 27017

3. Kuralın eklendiğini kontrol edin:

   sudo ufw status numbered

   Belirtilen kaynaktan gelen 27017 numaralı portu izin veren bir kayıt görmelisiniz.

4. İsteğe bağlı olarak, MongoDB’ye giden tüm diğer trafiği açıkça engelleyin:

   sudo ufw deny 27017/tcp

MongoDB yapılandırmasındaki bindIp ile seçici UFW kurallarının bu kombinasyonu, diğer işlemler veritabanınızı açığa çıkarmaya çalışsa bile yalnızca tanınan sistemlerin veritabanınıza erişmesini sağlar.

TLS/SSL Şifrelemesini Etkinleştirme

Şimdiye kadar, yalnızca güvenilen kullanıcıların ve IP'lerin MongoDB'ye erişmesini sağladınız. Bir sonraki adım, verilerin taşınırken güvenliğini sağlamaktır.

Bir istemci MongoDB'ye bağlandığında, tüm veriler (kimlik doğrulama bilgileri ve sorgular dahil) varsayılan olarak düz metin olarak iletilir. TLS, bu verileri şifreleyerek dinlemeyi veya değiştirmeyi önler.

Sertifika Oluşturun veya Edinin

Prodüksiyonda, güvenilir bir Sertifika Otoritesi (CA) tarafından verilen bir sertifika kullanın. Test veya dahili dağıtımlar için kendi imzanızı taşıyan bir sertifika oluşturabilirsiniz:

sudo mkdir -p /etc/ssl/mongodb

sudo openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out /etc/ssl/mongodb/mongodb.crt -keyout /etc/ssl/mongodb/mongodb.key -subj "/CN=$(hostname)"

Bu yaratır:

• mongodb.crt: genel sertifika
• mongodb.key: özel anahtar

Bunları tek bir PEM dosyasında birleştirin (MongoDB tarafından gereklidir):

sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem

sudo chmod 600 /etc/ssl/mongodb/mongodb.pem

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongodb.pem

Bu izinler, yalnızca mongodb kullanıcısının anahtar dosyasına erişebilmesini sağlar.

Yapılandırma Dosyasını Güncelle

/etc/mongod.conf dosyasını düzenleyin ve net bölümünü bulun. Altına yeni bir tls bloğu ekleyin:

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.50
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/mongodb.pem

• mode: requireTLS MongoDB'nin şifrelenmemiş bağlantıları reddedeceği anlamına gelir.
• certificateKeyFile, birleşik PEM dosyasının yolunu belirtir.

Değişikliği uygulamak için MongoDB'yi yeniden başlatın:

sudo systemctl restart mongod

TLS Kullanarak Bağlan

mongosh ile bağlanırken artık --tls seçeneğini belirtmeniz gerekir:

mongosh --tls --host 192.168.10.50 -u admin -p --authenticationDatabase admin

Bağlantı başarılı olursa ve istem görünüyor ise, TLS yapılandırmanız doğru şekilde çalışıyor demektir.

Şifrelemeyi, bağlantıyı OpenSSL kullanarak inceleyerek doğrulayabilirsiniz:

openssl s_client -connect 192.168.10.50:27017

Çıktı, örneğin sertifika zincirini ve şifreleme detaylarını göstermelidir:

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Bu, MongoDB sunucunuzun artık trafiği uçtan uca şifrelediğini doğrular.

Güvenlik Durumunuzu Doğrulama

Her şey yapılandırıldıktan sonra, kurulumunuzu yeniden kontrol etmeye değer.

1. MongoDB'nin yalnızca izin verilen IP'lere bağlı olduğunu kontrol edin:

   sudo ss -tulpn | grep mongod

   Bağlantıların yalnızca 127.0.0.1 ve güvenilir IP’lerinizle sınırlı olduğunu görmelisiniz.

2. Kimlik doğrulamanın zorunlu olduğundan emin olun. Kimlik bilgisi kullanmadan bağlanmayı deneyin:

   mongosh

   Bir kimlik doğrulama hatası almanız gerekir.

3. TLS'in gerekli olduğunu doğrulayın. --tls olmadan bağlanmayı deneyin:

   mongosh --host 192.168.10.50 -u admin -p --authenticationDatabase admin

   Bağlantı TLS gereksinimleri hakkında bir mesaj ile başarısız olursa, şifrelemeniz doğru şekilde uygulanmış demektir.

4. MongoDB’nin dahili güvenlik parametrelerini gözden geçirin:

   mongosh -u admin -p --authenticationDatabase admin --eval "db.runCommand({ getParameter: 1, tlsMode: 1 })"

   Eğer tlsMode "requireTLS" değerini döndürürse, şifrelemenin aktif olduğu doğrulanmış olur.

Kimlik doğrulama, erişim kontrolü, ağ kısıtlamaları ve TLS hepsi yapılandırıldığında, MongoDB örneğiniz artık en yaygın saldırı vektörlerine karşı güvence altına alınmıştır.

Operasyonel En İyi Uygulamalar

MongoDB kurulduktan ve güvenliği sağlandıktan sonra, bir sonraki önemli öncelik onu etkili bir şekilde sürdürmektir. En dikkatlice yapılandırılmış veritabanı bile düzenli bakım yapılmadığında güvenilmez hale gelebilir. Yedekleme, izleme ve sistem güncellemeleri gibi rutin işlemler, MongoDB'nin zaman içinde performanslı, kararlı ve kurtarılabilir kalmasını sağlar.

MongoDB Verilerini Yedeklemek

İyi planlanmış bir yedekleme stratejisi, herhangi bir üretim veritabanı için temel bir gerekliliktir. Yedeklemeler, donanım arızalarından, yazılım hatalarından veya yanlışlıkla yapılan silmelerden hızla kurtulmanıza olanak tanır. MongoDB, her biri farklı senaryolara uygun olan mantıksal ve fiziksel yedeklemeleri destekler.

mongodump Kullanarak Mantıksal Yedeklemeler

Mantıksal yedekleme, mongodump aracı kullanılarak veritabanı içeriğini BSON formatında yakalar. Bu yöntem taşınabilir, insan tarafından okunabilir ve otomatikleştirmesi kolaydır.

Tüm veritabanlarının tam yedeğini oluşturmak için şu komutu çalıştırın:

mongodump --out /backups/mongodb/$(date +%F)

Bu komut, /backups/mongodb/ altında mevcut tarih ile adlandırılmış bir dizin oluşturur ve tüm BSON yedeklerini burada saklar.

Kimlik doğrulama etkinse, kimlik bilgilerini içeren bir URI bağlantı dizesi kullanın:

mongodump --uri="mongodb://admin:YourPassword@localhost:27017/admin" --out /backups/mongodb/$(date +%F)

Belirli bir veritabanını da yedekleyebilirsiniz:

mongodump --db=myappdb --out /backups/mongodb/$(date +%F)

Mantıksal bir yedekten geri yüklemek için mongorestore komutunu kullanın:

mongorestore /backups/mongodb/2026-01-05/

Ya da tek bir veritabanını geri yükleyin:

mongorestore --db=myappdb /backups/mongodb/2026-01-05/myappdb

Mantıksal yedeklemeler esnektir ve kolayca senaryolaştırılabilir, ancak çok büyük veri setleri için tamamlanması daha uzun sürebilir.

Fiziksel Yedeklemeler (Dosya Sistemi Anlık Görüntüleri)

Fiziksel yedeklemeler, veritabanı dosyalarını doğrudan depolama biriminden alır. Bu yöntem, büyük veritabanları için daha hızlı ve daha az yer kaplayıcıdır, ancak bozulmayı önlemek için tutarlı anlık görüntüler gerektirir.

Journaling kullanıyorsanız (varsayılan olarak etkinleştirilmiştir), MongoDB çalışırken hacim anlık görüntüleri alabilirsiniz. WiredTiger, journaling etkin olduğu sürece MongoDB çalışırken çökme tutarlı anlık görüntüleri destekler. Tam uygulama-tutarlı anlık görüntüler için MongoDB'yi durdurmanız önerilir, ancak zorunlu değildir:

sudo systemctl stop mongod

Bulut sağlayıcınızı veya depolama sisteminizi kullanarak anlık görüntü alın ve servisi yeniden başlatın:

sudo systemctl start mongod

Mümkün olduğunda anlık görüntüleri uzak bir yerde veya ayrı bir bölgede saklayın. Bu, veri merkezi kesintilerine veya kazara yerel silmelere karşı koruma sağlar.

MongoDB Sağlığını İzleme

Kullanıcıları etkilemeden önce sorunları önlemek için izleme kritik öneme sahiptir. MongoDB, dahili komut satırı araçlarının yanı sıra harici izleme sistemlerini destekler.

Yerleşik Araçları Kullanmak

mongostat aracı, saniye başına işlem sayısı, bellek kullanımı ve aktif bağlantılar gibi canlı veritabanı metriklerini gösterir. Şöyle çalıştırın:

mongostat --uri "mongodb://admin@localhost:27017/?authSource=admin"

Bu, eklemeleri, sorguları, güncellemeleri ve silmeleri gösteren gerçek zamanlı bir tablo üretir. Her sütun, kirli bellek sayfalarının oranı veya aktif bağlantı sayısı gibi bir anahtar performans göstergesini temsil eder.

mongotop aracı, MongoDB'nin her koleksiyon için okuma ve yazma işlemlerine ne kadar süre harcadığına odaklanır. Bunu her iki saniyede bir çalıştırmak için şunu kullanın:

mongotop 2

Bu, yoğun G/Ç yaşayan koleksiyonları belirlemek için faydalıdır.

Harici İzleme Araçlarını Kullanmak

Sürekli görünürlük ve uyarı için MongoDB'yi şu gibi harici sistemlerle entegre edebilirsiniz:

• MongoDB Atlas İzleme, kendi sunucularınızda barındırılan kümeler için bile.
• Prometheus ve Grafana, zaman serisi panoları için MongoDB İhracatçısını kullanıyor.
• Percona İzleme ve Yönetim (PMM), eksiksiz bir açık kaynak izleme paketidir.
• Netdata, Zabbix veya Datadog gibi genel sistem araçları.

İzlenmesi gereken önemli ölçütler şunlardır:

• Bellek kullanımı ve önbellek isabet oranı
• Disk G/Ç gecikmesi ve veri aktarım hızı
• Bağlantı sayıları ve kuyruk uzunluğu
• İşlem gecikmesi (ekleme, güncelleme, sorgulama süreleri)
• Replika gecikmesi (eğer bir replika seti çalıştırılıyorsa)

Disk Alanı ve Depolama Büyümesini Yönetme

MongoDB veritabanları, belgeler ve dizinler büyüdükçe dinamik olarak genişler. Disk kullanımı kontrol edilmezse, veritabanı alan tükenebilir ve bu da kilitlenmesine veya çökmesine neden olabilir.

Disk Kullanımını Kontrol Etme

Mevcut dosya sistemi kullanımını şununla kontrol edin:

df -h /var/lib/mongodb

Bu, MongoDB’nin veri dizini için mevcut ve kullanılan alanı gösterir.

Bellek ve önbellek kullanımını MongoDB üzerinden de kontrol edebilirsiniz:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Önbellekteki baytlar değeri, WiredTiger depolama motorunun ne kadar RAM kullandığını gösterir.

Disk Kullanım Uyarılarını Ayarlama

Proaktif kalmak için, disk kullanımı %85'i aştığında sizi bilgilendiren uyarılar veya izleme kontrolleri ayarlayın. Örneğin, basit bir betik periyodik olarak çalışacak şekilde planlanabilir:

df -h | awk '$5 > 85 {print $0}'

Bunu otomasyon için systemd zamanlayıcılarına veya izleme araçlarına entegre edebilirsiniz.

Eski Verilerin ve Kayıtların Yönetimi

Büyük veya kullanılmayan koleksiyonlar ve günlük dosyaları zamanla önemli miktarda alan tüketebilir. Günlükleri yönetmek için, /etc/logrotate.d/mongodb dosyasında rotasyonu yapılandırın (bu bölümde daha sonra gösterildiği gibi) veya manuel olarak temizleyin:

sudo journalctl --vacuum-time=7d

sudo rm -f /var/log/mongodb/*.gz

Uygulama verileri için, geçici veya zamana duyarlı verileri depolayan koleksiyonlar için TTL (yaşam süresi) indekslerini kullanmayı düşünün:

db.sessionLogs.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 604800 })

Bu, yedi günden eski belgeleri otomatik olarak siler.

Güvenli Yükseltmeler Yapmak

MongoDB'yi yükseltmek, özellikle ana sürümler arasında geçiş yaparken dikkatli bir planlama gerektirir. Aşağıdaki süreç, kesinti süresini en aza indirir ve uyumluluğu sağlar.

Mevcut Sürümü Kontrol Et

Yüklü sürümü doğrulayın:

mongod --version

Yükseltmeden Önce Yedekleyin

Yükseltmeden önce her zaman tam bir yedek oluşturun:

mongodump --out /backups/mongodb/pre-upgrade-$(date +%F)

Paket Depolarını Güncelle ve Yükselt

Daha önce otomatik güncellemeleri önlemek için MongoDB paketlerini sabitlediyseniz, sabitlemeleri kaldırın:

echo "mongodb-org install" | sudo dpkg --set-selections

Sonra paket listenizi güncelleyin ve MongoDB'yi yükseltin:

sudo apt update

sudo apt install -y mongodb-org

MongoDB, yükseltmeler sırasında yapılandırma ve veri dosyalarınızı korur, ancak bir yedekleme bir şeyler ters gittiğinde geri dönebileceğinizi garanti eder.

Yükseltmeyi Doğrula

Yükseltmeden sonra:

1. Hizmet durumunu doğrulayın:

   sudo systemctl status mongod

2. Uyarılar veya taşıma notları için son kayıtları kontrol edin:

   sudo tail -n 30 /var/log/mongodb/mongod.log

3. Yeni sürümü onaylayın:

   mongosh --eval "db.version()"

Rutin Bakımın Otomatikleştirilmesi

Küçük ortamlar için elle bakım çalışmaları yapılabilir, ancak otomasyon tutarlılığı sağlar. Tekrarlayan yedeklemeleri, günlük döndürmelerini veya izleme kontrollerini cron veya systemd zamanlayıcıları kullanarak planlayabilirsiniz.

Otomatik Yedeklemeleri Planla

Root crontab dosyasını düzenleyin:

sudo crontab -e

MongoDB örneğinizi her gece saat 2'de yedeklemek için aşağıdaki satırı ekleyin:

0 2 * * * mongodump --out /backups/mongodb/$(date +\%F)

Bu, her gün tarihli bir yedek klasör oluşturur.

Günlük Döndürmeyi Yapılandır

Kayıt dosyalarının disk alanını tüketmesini önlemek için bir kayıt döngüsü yapılandırma dosyası oluşturun:

sudo nano /etc/logrotate.d/mongodb

Aşağıdaki içeriği ekleyin:

/var/log/mongodb/mongod.log {
    weekly
    rotate 5
    compress
    delaycompress
    missingok
    notifempty
    create 640 mongodb adm
    postrotate
        systemctl reload mongod > /dev/null 2>&1 || true
    endscript
}

Bu yapılandırma, beş haftalık günlükleri saklar, eski dosyaları sıkıştırır ve döndürme işleminden sonra MongoDB'yi yeniden yükler.

Sistem Zamanını Doğru Tutmak

MongoDB’nin günlükleme ve çoğaltma özellikleri doğru zaman damgalarına dayanır. Sistem saati saparsa, bir çökmeden sonra çoğaltma gecikmesi veya günlük bozulması meydana gelebilir.

Ubuntu 24.04 varsayılan olarak systemd-timesyncd kullanır, ancak daha hassas zaman senkronizasyonu için chrony de kullanabilirsiniz:

sudo apt install chrony -y

sudo systemctl enable --now chrony

Eşzamanlamayı şu şekilde doğrulayabilirsiniz:

timedatectl status

Eğer NTP synchronized yes olarak görünüyorsa, sistem saatiniz senkronizedir.

MongoDB Sağlığını Gerçek Zamanlı Kontrol Etme

MongoDB, kapsamlı çalışma zamanı tanılama için serverStatus komutunu sağlar. Bunu doğrudan shell üzerinden sorgulayabilirsiniz:

mongosh --eval "db.serverStatus()"

Bu, aşağıdaki gibi metrikleri içeren detaylı bir JSON nesnesi döndürür:

• Bellek kullanımı
• Önbellek kullanımı
• Bağlantı sayısı
• İşlem verimliliği
• Çoğaltma durumu

Hedefe yönelik kontroller için belirli alanları çıkarabilirsiniz. Örneğin, bağlantı istatistiklerini görüntülemek için:

mongosh --eval "db.serverStatus().connections"

Bu, sistemin bağlantı doygunluğu veya kaynak kısıtlamaları yaşayıp yaşamadığı konusunda hızlı bir şekilde fikir sahibi olunmasını sağlar.

Yüksek Erişilebilirliğe Hazırlık

Tek düğümlü MongoDB dağıtımları, geliştirme veya düşük öncelikli uygulamalar için iyi çalışır. Üretim ortamları için replika setleri uygulamalısınız. Replika setleri, bir düğüm arızalansa bile kullanılabilirliği sağlayarak yedeklilik ve otomatik hata geçişi sunar.

Tipik bir kuruluma göre:

• Bir düğüm, tüm yazmaları ve çoğu okumayı yöneten birincil olarak görev yapar.
• Bir veya daha fazla ikincil düğüm verileri gerçek zamanlı olarak çoğaltır.
• Eğer birincil düğüm çevrimdışına geçerse, ikincil düğümlerden biri otomatik olarak yeni birincil olur.

Replika setleri, yedekleme ve ölçeklendirme gibi bakım görevlerini de basitleştirir. Birincil performansı etkilemeden yedeklemeleri veya analiz sorgularını ikincil düğümlere aktarabilirsiniz.

MongoDB örneğiniz artık tamamen çalışır durumda ve düzgün bir şekilde bakımı yapılmaktadır.

Ölçekleme ve Performans Optimizasyonu

MongoDB yatay olarak ölçeklenmek üzere tasarlanmıştır; bu, kapasiteyi ve performansı artırmak için sadece daha güçlü bir makineye güvenmek yerine daha fazla sunucu ekleyebileceğiniz anlamına gelir. Veri setiniz büyüdükçe veya uygulamanız daha fazla eşzamanlı sorgu işlemeye başladıkça, ölçeklendirme MongoDB'nin güvenilir ve verimli bir şekilde çalışmaya devam etmesini sağlar.

MongoDB'yi ölçeklendirmenin iki temel yolu vardır:

1. Replica setleri, yedeklilik yoluyla güvenilirliği ve okuma performansını artırır.
2. Sharding, daha büyük veri kümelerini ve yazma yüklerini yönetmek için verileri birden fazla sunucuya dağıtır.

Replica Set'leri Anlamak

Replika seti, verilerinizin aynı kopyalarını tutan MongoDB sunucularından oluşan bir gruptur. Replika setleri yüksek kullanılabilirlik sağlar ve donanım veya ağ arızalarına karşı koruma sunar. Eğer birincil düğüm arızalanırsa, ikincil düğümlerden biri otomatik olarak devreye girer ve minimum kesinti süresi sağlanır.

Standart bir çoğaltma seti şunlardan oluşur:

• Tüm yazma işlemlerini yöneten bir ana düğüm.
• Birincilden veri kopyalayan iki veya daha fazla ikincil düğüm.
• İsteğe bağlı hakem düğümleri, seçimlere katılır ancak veri saklamazlar.

Üretim sistemleri için MongoDB, bir replika setinde en az üç üye bulunmasını önerir.

Bir Replika Seti Yapılandırma

Bir replika seti oluşturmak için en az iki veya üç sunucuya (fiziksel veya sanal) ihtiyacınız vardır. Her düğüme MongoDB'nin kurulmuş ve yapılandırılmış olması gerekir.

1. Her düğümde, yapılandırma dosyasını /etc/mongod.conf açın ve çoğaltma bölümünü ekleyin:

   replication:
     replSetName: "rs0"

2. Her sunucuda MongoDB'yi yeniden başlatın:

   sudo systemctl restart mongod

3. Birincil düğümde, MongoDB'ye bağlanın ve çoğaltma setini başlatın:

   mongosh

   Sonra çalıştırın:

   rs.initiate({
     _id: "rs0",
     members: [
       { _id: 0, host: "mongodb1.example.com:27017" },
       { _id: 1, host: "mongodb2.example.com:27017" },
       { _id: 2, host: "mongodb3.example.com:27017" }
     ]
   })

4. Durumu doğrula:

   rs.status()

   Çıktı, durumu “PRIMARY” ve “SECONDARY” olarak etiketlenmiş bir birincil ve iki ikinciliyi göstermelidir.

Replica Setlerin Faydaları

Replika setleri birkaç önemli avantaj sunar:

• Yüksek kullanılabilirlik: Otomatik devreye geçme, birincil düğüm çevrimdışına geçtiğinde sürekli çalışmayı sağlar.
• Veri fazlalılığı: Her düğüm verilerin tam bir kopyasını saklar.
• Okuma ölçeklenebilirliği: İkincil düğümler okuma işlemlerini yönetebilir, bu da birincil düğümdeki yükü azaltır.
• Bakım esnekliği: Kullanılabilirliği etkilemeden ikincil düğümlerde yedekleme veya sistem güncellemeleri yapabilirsiniz.

Sharding'i Anlamak

Sharding, MongoDB’nin yatay ölçeklendirme stratejisidir. Bir veri seti tek bir sunucunun verimli bir şekilde depolayamayacağı veya işleyemeyeceği kadar büyük hale geldiğinde, MongoDB onu shard adı verilen birden fazla sunucuya dağıtılmış daha küçük parçalar halinde bölebilir.

Her bir parça verinin bir alt kümesini tutar ve küme topluca tek bir mantıksal veritabanı gibi davranır.

Shard'li Bir Kümenin Bileşenleri

Tipik bir MongoDB parçalara ayrılmış kümesi şunları içerir:

• Shardlar: Veri taşıyan düğümler, genellikle yedeklilik için replikasyon setleri olarak konuşlandırılır.
• Yapılandırma sunucuları: Parça dağılımı dahil olmak üzere meta verileri ve küme yapılandırmasını depolar.
• Mongos yönlendiricileri: İstemci sorgularını, parçalama anahtarına göre doğru parçaya yönlendirir.

Bir Parça Anahtarı Seçmek

Shard anahtarı, MongoDB'nin verileri shardlar arasında nasıl dağıtacağını belirler. Kötü seçilmiş bir shard anahtarı, düzensiz veri dağılımına (veri eğriliği olarak bilinir) veya hotspotlara yol açabilir.

İyi shard anahtarları genellikle şunlara sahiptir:

• Yüksek kardinalite (çok sayıda benzersiz değer).
• Hatta veri erişim desenleri.
• Çoğu sorguda parça anahtarını içeren tahmin edilebilir bir sorgu deseni.

Bir veritabanı için sharding etkinleştirme örneği:

sh.enableSharding("salesdb")
sh.shardCollection("salesdb.orders", { "customer_id": 1 })

Bu komut, salesdb veritabanında sharding'i etkinleştirir ve orders koleksiyonunu customer_id alanını kullanarak shard eder.

Sharding Ne Zaman Kullanılır

Aşağıdaki durumlarda sharding yapmayı düşünmelisiniz:

• Veritabanı, tek bir sunucunun depolama kapasitesine yaklaşıyor veya onu aşıyor.
• Yazma hızı sürekli olarak CPU veya disk G/Ç'sini maksimuma çıkarıyor.
• Çalışma seti artık RAM'e sığmıyor, bu da sık sık sayfa değişimlerine yol açıyor.
• Veri setinizde üstel bir büyüme öngörüyorsunuz.

Sharding, mimari karmaşıklık ekler, bu yüzden yalnızca gerekli olduğunda uygulanması en iyisidir.

WiredTiger'ı Performans İçin Ayarlama

MongoDB, varsayılan olarak WiredTiger depolama motorunu kullanır. Modern donanım için optimize edilmiştir ve sıkıştırma, önbellekleme ve çok iş parçacıklı G/Ç kullanır. WiredTiger'ın belleği ve disk G/Ç'sini nasıl yönettiğini anlamak, performansı artırmaya yardımcı olur.

Bellek Kullanımı

WiredTiger genellikle mevcut RAM'in yaklaşık %50'sini önbelleği için kullanır ve MongoDB bu değeri sistem belleğine göre dinamik olarak ayarlar.

Bunu yapılandırma dosyasında ayarlayabilirsiniz:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

Bu, sisteminiz MongoDB'nin yanında diğer hafıza yoğun hizmetleri çalıştırıyorsa faydalıdır. Yalnızca MongoDB sunucuları için, varsayılan önbellek ayarını bırakmak genellikle en iyisidir.

Mevcut önbellek kullanımını görüntülemek için şunu çalıştırabilirsiniz:

mongosh --eval "db.serverStatus().wiredTiger.cache"

Sıkıştırma

WiredTiger, disk kullanımını azaltmak için veri ve indeks sıkıştırmayı destekler. Varsayılan olarak performans ve alan verimliliğini dengeleyen Snappy sıkıştırması kullanır. Hız yerine disk tasarrufunu önceliklendiriyorsanız, daha iyi sıkıştırma için zlib veya daha yeni kurulumlar için zstd kullanabilirsiniz.

Örnek yapılandırma:

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

Günlük Tutma ve Dayanıklılık

Günlük tutma, yazma işlemlerinin güç kaybı durumunda bile kalıcı olmasını sağlar. Günlük yazımlarının ne sıklıkta gerçekleşeceğini kontrol etmek için commitIntervalMs parametresini ayarlayabilirsiniz:

storage:
  journal:
    commitIntervalMs: 100

Daha düşük aralıklar dayanıklılığı artırır ancak yazma performansını biraz düşürebilir.

İzleme ve Ölçekleme Tetikleyicileri

MongoDB dağıtımınızı ne zaman ölçeklendirmeniz gerektiğini fark etmek önemlidir. CPU yükü, bellek kullanımı ve G/Ç bekleme süreleri gibi izleme metrikleri, ne zaman daha fazla kapasite eklemeniz gerektiğini belirlemenize yardımcı olacaktır.

Büyüme İçin Yaygın Tetikleyiciler

• CPU kullanım oranı sürekli olarak %80'in üzerinde.
• Disk giriş/çıkış gecikmesi kabul edilebilir eşiklerin üzerinde (örneğin, 10 ms'den fazla).
• RAM kullanımı uzun süreler boyunca maksimuma yakın.
• Çalışma seti boyutundaki hızlı artış.
• Düğümler arasındaki çoğaltma gecikmesinde artış.

Bu göstergeler ortaya çıktığında, daha fazla ikincil eklemeyi (okumalar için) veya parça eklemeyi (yazma ağırlıklı yükler için) düşünün.

Dikey ve Yatay Ölçeklendirme

Dikey ölçekleme, mevcut sunuculara daha fazla kaynak (CPU, RAM, daha hızlı diskler) eklemeyi içerir. Yönetimi daha basittir ancak donanım kapasitesi ile sınırlıdır.

Yatay ölçeklendirme, iş yükünü dağıtmak için yeni sunucular eklemeyi içerir. Bu, MongoDB’nin güçlü yönüdür; doğru şekilde tasarlandığında neredeyse lineer olarak ölçeklenir.

Yönetilen MongoDB'ye Geçiş

Sisteminiz büyüdükçe, kendi kendine barındırılan bir kümeyi yönetmek karmaşık hale gelebilir. Bu aşamada, MongoDB Atlas gibi yönetilen bir MongoDB hizmetine geçmek, operasyonel yükü önemli ölçüde azaltabilir.

Yönetilen platformlar otomatik yedeklemeler, yamalama, izleme, ölçeklendirme ve şifreleme işlemlerini yönetir. Ancak, kendi kendine yönetilen kurulumlara kıyasla ek maliyet ve biraz daha az esneklik getirebilirler.

<$> Öneri: Takımınız performans darboğazları, küme yönetimi karmaşıklığı veya yönetilen platformların daha verimli bir şekilde ele aldığı uyumluluk gereksinimleri gibi sürekli operasyonel zorluklarla karşılaşana kadar kendi sunucularınızda kalın. <$>

Karşılaştırma: Kendi Sunucusunda Barındırılan vs Yönetilen MongoDB

MongoDB iki ana şekilde dağıtılabilir:

1. Kendi sunucunuzda barındırma, veritabanını kendiniz kurup yapılandırdığınız ve bakımını yaptığınız anlamına gelir (bu kılavuzda ele alındığı gibi).
2. Yönetilen, bir üçüncü taraf sağlayıcının MongoDB'yi sizin için bir hizmet olarak barındırıp işletmesi durumudur.

Her yaklaşımın kendine özgü avantajları ve dezavantajları vardır. Doğru tercih, teknik uzmanlığınıza, iş yükü özelliklerinize, uyumluluk gereksinimlerinize ve operasyonel önceliklerinize bağlıdır.

Bu iki seçeneği derinlemesine inceleyelim.

Kendi Sunucusunda Barındırılan MongoDB

MongoDB’yi kendi sunucunuzda barındırdığınızda, onu doğrudan kendi altyapınıza kurarsınız; bu fiziksel bir sunucu, sanal bir makine veya Linux-Console.net Droplet gibi bir bulut örneği olabilir. Kurulumdan yükseltmelere ve izlemeye kadar ortamın her yönünü siz kontrol edersiniz.

Kendi Sunucunda Barındırmanın Avantajları

1. Tam Kontrol ve Esneklik: Yapılandırma ayarları, dosya sistemleri, ağ ve performans ayarlamaları üzerinde tam yetkiye sahipsiniz. mongod.conf dosyasını değiştirebilir, depolama yollarınızı seçebilir ve kuruluşunuzun standartlarına uygun özel güvenlik veya yedekleme politikaları uygulayabilirsiniz.
2. Küçük Dağıtımlar İçin Maliyet Verimliliği: Küçük veya orta ölçekli iş yükleri için, kendi sunucunuzu barındırmak yönetilen bir hizmeti kullanmaktan daha ucuz olabilir. Ek bir yönetim katmanı yerine yalnızca temel hesaplama ve depolama kaynakları için ödeme yaparsınız.
3. Özel Güvenlik Politikaları: MongoDB'yi dahili VPN'ler, güvenlik duvarları veya özel ağlarla entegre edebilirsiniz ve böylece yerel veya sektöre özgü güvenlik gereksinimlerine tam uyum sağlayabilirsiniz. Bazı kuruluşlar, veri yerleşimi veya yasal düzenlemeler nedeniyle yerinde dağıtım gerektirebilir; bu da kendi sunucularında barındırmayı tek geçerli seçenek haline getirir.
4. Performans Optimizasyonu: Donanımı kontrol ettiğiniz için I/O zamanlayıcıları, önbellek boyutları ve sıkıştırma algoritmaları gibi sistem parametrelerini ince ayar yapabilirsiniz. Ayrıca, ağ gecikmesini en aza indirmek için MongoDB'yi ilgili hizmetlerle birlikte konumlandırabilirsiniz.

Kendi Sunucunu Yönetmenin Zorlukları

• Operasyonel Yük: Her şeyin yönetiminden siz sorumlusunuz; güncellemeleri ve yamaları yüklemekten kesintilerle ve performans ayarlamalarıyla ilgilenmeye kadar. Bu, veritabanı yönetimi ve Linux sistem yönetimi konusunda uzmanlaşmış özel personel gerektirir.
• Ölçeklenebilirlik Kompleksliği: Kendi kendine barındırılan bir MongoDB kümesini ölçeklendirmek, yeni sunucular sağlamak, verileri yeniden dengelemek, yapılandırmaları güncellemek ve replika veya shard topolojilerini manuel olarak sürdürmek anlamına gelir. Bu görevler otomasyon olmadan hata yapmaya açık olabilir.
• Yedekleme ve Felaket Kurtarma: Kendi yedekleme, geri yükleme ve uzaktan depolama süreçlerinizi tasarlamanız, test etmeniz ve sürdürmeniz gerekir. MongoDB'nin araçları (mongodump, mongorestore ve hacim anlık görüntüleri) bunu mümkün kılarken, disiplinli bir operasyonel planlama gerektirir.
• İzleme ve Uyarı: Kendi sunucunuzda barındırdığınız MongoDB, Prometheus, Grafana veya Percona PMM gibi araçları kullanarak izleme ve uyarı sistemleri kurmanızı gerektirir. Sürekli görünürlük sağlanmazsa, arızalar veya performans darboğazları, kesinti yaşanana kadar fark edilmeyebilir.

Özetle, kendi sunucusunda barındırılan MongoDB küçük ölçeklerde esneklik, bağımsızlık ve daha düşük maliyet sunar ancak önemli bir sürekli bakım çabası gerektirir.

Yönetilen MongoDB Hizmetleri

Yönetilen bir MongoDB servisi, veritabanını sizin adınıza barındırır ve tüm altyapı, güncellemeler, ölçeklendirme ve güvenlik yamalarını otomatik olarak yönetir. Bu hizmetler, yüksek kullanılabilirlik ve küresel ölçeklenebilirlik sunarken çoğu yönetimsel yükü ortadan kaldırır.

Yönetilen MongoDB'nin Avantajları

1. Minimum İşletim Çabası: Hizmet sağlayıcı, veritabanı sağlama, yedekleme, yükseltmeler ve devreye alma işlemlerini otomatik olarak yönetir. Yeni kümeleri sadece birkaç tıklama veya API çağrısıyla dağıtabilir, böylece yönetim yükünü önemli ölçüde azaltabilirsiniz.
2. Otomatik Ölçeklendirme: Yönetilen hizmetler, veri setiniz büyüdükçe işlem ve depolama kaynaklarını dinamik olarak ayarlayabilir. Örneğin, MongoDB Atlas otomatik bölümlendirme ve dikey ölçeklendirmeyi kesinti olmadan destekler.
3. Yerleşik İzleme ve Uyarılar: Yönetilen platformlar, CPU kullanımı, disk performansı, bağlantı istatistikleri ve sorgu gecikmesi için panolar içerir. Kritik metrikler için ayrı bir izleme aracı kurmadan uyarı eşiklerini belirleyebilirsiniz.
4. Varsayılan olarak Yüksek Erişilebilirlik: Çoğu yönetilen hizmet, farklı kullanılabilirlik bölgelerinde üç veya daha fazla replika set düğümü ile kümeler dağıtır. Bu, minimum yapılandırma ile otomatik geçiş ve yüksek çalışma süresi sağlar.
5. Güvenlik ve Uyumluluk: Yönetilen MongoDB platformları, yerleşik şifreleme, rol tabanlı erişim, ağ izolasyonu (VPC eşlemesi) ve kimlik sağlayıcıları ile entegrasyon sunar. Ayrıca SOC 2, GDPR, HIPAA ve ISO 27001 gibi standartlar için sertifikalıdırlar, bu da uyumluluk denetimlerini kolaylaştırır.
6. Küresel Dağıtım: MongoDB Atlas ve benzeri hizmetler çok bölgeli kümeleri destekler. Veriler, kullanıcılarınıza coğrafi olarak yakın bir şekilde çoğaltılabilir ve dağıtık uygulamaların gecikme süresini iyileştirir.

Yönetilen Hizmetlerin Sınırlamaları

1. Ölçeklendikçe Daha Yüksek Maliyet: Yönetilen hizmetler, otomasyon ve kullanım kolaylığı için ekstra ücret alır. Veri hacmi ve trafik arttıkça, aylık maliyetler kendi kendine barındırılan sistemleri çalıştırmanın maliyetini aşabilir, özellikle SSD'lerde saklanan büyük veri setleri için.
2. Sınırlı Özelleştirme: Yönetilen ortamlar, düşük seviyeli yapılandırma seçeneklerine erişimi kısıtlar. Dosya sistemi seviyesindeki ayarları, önbellek optimizasyonunu veya temel işletim sistemi parametrelerini değiştiremezsiniz.
3. Tedarikçi Bağımlılığı: Her sağlayıcının benzersiz API'leri ve dağıtım yapılandırmaları vardır, bu da hizmetler arasında geçiş yapmayı zorlaştırır.
4. Ağ Bağımlılığı: Yönetilen veritabanları harici ağ bağlantısına bağımlıdır. Uygulamanız bir kurum içi ortamda çalışıyorsa, yönetilen bir hizmete güvenli şekilde bağlanmak gecikmeye veya VPN tünellerine bağımlılığa yol açabilir.

Özetle, Yönetilen MongoDB hizmetleri idari yükü önemli ölçüde azaltır ve güvenilirliği artırır, ancak esneklikten ve daha yüksek tekrar eden maliyetlerden taviz verir.

Özellik Karşılaştırma Tablosu

Doğru Dağıtım Modelini Seçmek

Kendi sunucunuzda barındırılan ve yönetilen MongoDB arasındaki karar, öncelikle kuruluşunuzun önceliklerine, kaynaklarına ve kısıtlamalarına bağlıdır. Aşağıdaki senaryoları göz önünde bulundurun:

• Aşağıdaki durumlarda Kendi Sunucunuzda Barındırılan MongoDB'yi seçin:

  • Altyapı ve veri üzerinde tam kontrole ihtiyacınız var.
  • İş yükünüz orta düzeyde ve tahmin edilebilir.
  • Linux ve MongoDB yönetimi konusunda şirket içinde uzmanlığınız var.
  • Uyumluluk veya veri ikamet yasaları, yerinde depolamayı gerektirir.

• Şu durumlarda Yönetilen MongoDB’yi seçin:

  • Altyapı yerine uygulama geliştirmeye odaklanmayı tercih ediyorsunuz.
  • Minimum kurulumla otomatik ölçeklendirme ve yüksek kullanılabilirliğe ihtiyacınız var.
  • Ekibinizde özel veritabanı yöneticileri eksik.
  • Küresel olarak dağıtılmış kümelere veya uyumluluk sertifikalarına (SOC 2, HIPAA, GDPR) ihtiyacınız var.

Sorun Giderme ve Bakım

En dikkatli yapılandırma ve izlemeye rağmen, bir MongoDB dağıtımında sorunlar ortaya çıkabilir. Bunlar arasında yavaş performans, başlatma hataları, çoğaltma gecikmesi veya disk alanı tükenmesi gibi durumlar olabilir. Kararlı bir MongoDB ortamını sürdürmenin anahtarı, sorunları teşhis etmek ve önleyici bakım rutinlerini uygulamak için yapılandırılmış bir yaklaşıma sahip olmaktır.

MongoDB Servis Durumunu Kontrol Etme

MongoDB sorun giderilirken atılması gereken ilk adım, veritabanı servisinin düzgün çalışıp çalışmadığını doğrulamaktır.

Mevcut durumu aşağıdaki komut ile kontrol edebilirsiniz:

sudo systemctl status mongod

MongoDB çalışıyorsa, şunları içeren bir çıktı görmelisiniz:

Active: active (running)

Main PID: 3564 (mongod)

Eğer servis aktif değilse, başarısız olduysa veya çalışmıyorsa, yeniden başlatın:

sudo systemctl restart mongod

Yeniden başlattıktan sonra durumunu tekrar kontrol edin. Eğer hemen başarısız olursa, belirli hatalar için günlük dosyasını kontrol etmeye devam edin.

MongoDB Günlüklerini İncelemek

Loglar, tanısal bilgilerin en doğrudan kaynağıdır. MongoDB, tüm önemli olayları, uyarıları ve hataları şu konumda bulunan ana log dosyasında kaydeder:

/var/log/mongodb/mongod.log

En son kayıtları görüntülemek için şunu çalıştırın:

sudo tail -n 30 /var/log/mongodb/mongod.log

MongoDB başlatılamazsa, genellikle aşağıdaki hatalardan birini görürsünüz:

• İzin reddedildi: /var/lib/mongodb veya /var/log/mongodb üzerinde yanlış sahiplik veya izinler. İzinleri kontrol edin ve düzeltin:

  sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb

• Veri dizini bulunamadı: /var/lib/mongodb dizininin var olduğundan ve /etc/mongod.conf dosyasında tanımlanan yol ile eşleştiğinden emin olun.

• Adres zaten kullanılıyor: Başka bir işlem 27017 numaralı portu kullanıyor. Bunu şu şekilde tespit edebilirsiniz:

  sudo lsof -i :27017

  ve çakışan hizmeti durdurun veya yeniden yapılandırın.

• Bozulmuş veri dosyaları: Bu durum MongoDB aniden kapatıldığında meydana gelebilir. Bu gibi durumlarda, günlük dosyası yeniden başlatıldığında veriyi otomatik olarak kurtarmalıdır. Eğer başarısız olursa, yedekten geri yüklemeniz gerekebilir.

sudo tail -f /var/log/mongodb/mongod.log

Bağlantı Sorunlarını Teşhis Etme

Bağlantı problemleri başka yaygın bir sorundur. İstemciler MongoDB'ye ulaşamadığında, genellikle bunun nedeni bir ağ, kimlik doğrulama veya yapılandırma sorunudur.

MongoDB'nin Doğru Arabirimlerde Dinlediğini Doğrulayın

Çalıştır :

sudo ss -tulpn | grep mongod

Çıktı, MongoDB'nin 127.0.0.1 adresine (yerel bağlantılar için) ve yapılandırılmış varsa herhangi bir harici IP'ye bağlı olduğunu göstermelidir. MongoDB beklenen IP'de dinlemiyorsa, /etc/mongod.conf dosyasındaki bindIp alanını doğrulayın:

net:
  bindIp: 127.0.0.1,192.168.10.50

Düzenledikten sonra MongoDB'yi yeniden başlatın:

sudo systemctl restart mongod

Güvenlik Duvarı Kurallarını Kontrol Et

Uzak bağlantılar başarısız olursa, güvenlik duvarınızın 27017 numaralı port üzerinden trafiğe izin verdiğini doğrulayın:

sudo ufw status

Eğer değilse, belirli IP'lerden bağlantılara izin verin:

sudo ufw allow from 192.168.10.50 to any port 27017

Telnet veya Ping ile Bağlantıyı Test Et

Bir istemci sisteminden, portun erişilebilir olup olmadığını test edin:

telnet mongodb-server-ip 27017

veya

nc -vz mongodb-server-ip 27017

Bağlantı başarılı olursa, sorun muhtemelen kimlik doğrulama veya kullanıcı ayrıcalıklarıyla ilgilidir.

Kimlik Doğrulama Hatalarını Giderme

Kimlik doğrulama sorunları, genellikle erişim denetimi etkinleştirildikten veya kullanıcı kimlik bilgileri değiştirildikten sonra meydana gelir.

Kimlik Doğrulamanın Etkin Olduğunu Onaylayın

Yerel olarak bağlanın ve doğrulayın:

mongosh --eval "db.runCommand({ getParameter: 1, authenticationMechanisms: 1 })"

Çıktıda "SCRAM-SHA-256" yer alıyorsa, kimlik doğrulama aktif demektir.

Giriş Bilgilerini Doğrula

Yönetici hesabını kullanarak bağlanmayı deneyin:

mongosh -u admin -p --authenticationDatabase admin

Eğer bu başarısız olursa, yerel olarak kimlik doğrulaması yapmadan bağlanın (kullanıcı olmadığında yalnızca localhost'tan mümkündür) ve yönetici hesabını yeniden oluşturun:

use admin

db.createUser({
  user: "admin",
  pwd: "NewStrongPassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

Veritabanı Bağlamını Kontrol Et

Her MongoDB kullanıcısı belirli bir veritabanı içinde tanımlanır. Yanlış veritabanına karşı kimlik doğrulaması yaparsanız, kimlik doğrulama başarısız olur. Örneğin, kullanıcı admin veritabanında oluşturulduysa, ona karşı açıkça kimlik doğrulaması yapmanız gerekir:

mongosh -u admin -p --authenticationDatabase admin

Performans Sorunlarını Çözme

Performans düşüşü, yüksek bellek kullanımı, yavaş disk girişi/çıkışı, optimize edilmemiş sorgular veya aşırı eşzamanlı bağlantılardan kaynaklanabilir. MongoDB, bu sorunları tespit etmek için çeşitli tanılama araçları içerir.

Kaynak Kullanımını Kontrol Et

Sistem düzeyindeki ölçümleri kontrol etmek için Linux komutlarını kullanın:

top

vmstat 2

iostat -x 2

mongod tarafından yüksek CPU kullanımı veya disk gecikmesinin 10 milisaniyeyi aşması durumuna bakın.

Veritabanı İşlemlerini İzle

Çalıştır :

mongostat 2

Bu, saniye başına ekleme, sorgulama, güncelleme ve silme işlemleri dahil olmak üzere gerçek zamanlı metrikleri gösterir.

Belirli işlemler yavaş görünüyorsa, uzun süren sorguları tespit etmek için MongoDB profiler kullanın.

Sorgu Profillemeyi Etkinleştir

Yavaş sorguları kaydetmek için profili geçici olarak etkinleştirebilirsiniz:

use myappdb

db.setProfilingLevel(1, { slowms: 100 })

Bu, 100 milisaniyeden uzun süren herhangi bir sorguyu kaydeder.

Sonuçları gözden geçirin:

db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

Dizin Verimliliğini Analiz Et

Verimsiz sorgular genellikle eksik indekslerden kaynaklanır. MongoDB’nin indeksleri doğru kullanıp kullanmadığını görmek için sorgunuzun başına explain() ekleyin:

db.orders.find({ customer_id: 12345 }).explain("executionStats")

Eğer executionStages.stage "COLLSCAN" gösteriyorsa, MongoDB tüm koleksiyonu tarıyor demektir. Performansı artırmak için bir indeks oluşturabilirsiniz:

db.orders.createIndex({ customer_id: 1 })

Bozulmuş Veritabanlarını Onarma

Veri bozulması nadirdir, ancak güç kaybı veya disk hataları nedeniyle meydana gelebilir. MongoDB başlatılmayı reddediyor ve günlüklerde WiredTiger dosyalarında bozulma gösteriliyorsa, şu adımları izleyin:

1. MongoDB'yi durdur:

   sudo systemctl stop mongod

2. Mevcut veri dizinini yedekleyin:

   sudo cp -r /var/lib/mongodb /var/lib/mongodb-corrupt-backup

3. Bir onarım işlemi yapmayı deneyin:

   sudo -u mongodb mongod --repair --config /etc/mongod.conf

4. MongoDB'yi yeniden başlat:

   sudo systemctl start mongod

Onarım başarısız olursa, verileri en son yedekten geri yükleyin.

Rutin Bakım Görevleri

Önleyici bakım, beklenmedik arızaların olasılığını büyük ölçüde azaltır.

Logları Düzenli Olarak Döndürün

Günlük döndürme politikanızın etkin olduğundan emin olun. MongoDB, logAppend etkinleştirildiğinde hem dahili günlük döndürmeyi (logRotate komutu) hem de logrotate aracılığıyla harici döndürmeyi destekler. Günlükler hızla büyüyorsa bunu manuel olarak da tetikleyebilirsiniz:

sudo logrotate -f /etc/logrotate.d/mongodb

Kompakt Koleksiyonlar

Bir koleksiyon, birçok ekleme ve silmeden sonra parçalanabilir. compact alanı geri kazanabilir, ancak bloklayıcı bir işlemdir ve üretim ortamında nadiren kullanılmalıdır. WiredTiger parçalanmanın çoğunu otomatik olarak yönetir, bu nedenle genellikle sıkıştırma yapmak gerekli değildir.

Bu işlemin veritabanını kilitlediğini unutmayın, bu yüzden bunu düşük trafikli dönemlerde gerçekleştirin.

Koleksiyonları Doğrula

Periyodik veri bütünlüğü kontrolleri yapın:

db.runCommand({ validate: "collection_name" })

Bu, dizinlerin ve belgelerin tutarlı olduğunu doğrular.

Disk ve Bellek Kullanımını İzle

Disk kullanımı %85'i aştığında veya bellek kullanımı kritik seviyeye ulaştığında uyarı vermek için otomatik bildirimler kullanın. Prometheus, Percona PMM veya MongoDB Atlas Monitor gibi izleme araçları bu metrikleri zaman içinde takip edebilir.

Sistem Güncellemelerini Güvenli Bir Şekilde Uygulamak

MongoDB'yi veya altında yatan Ubuntu sistemini güncellerken her zaman yapılandırılmış bir süreç izleyin:

1. Öncelikle verilerinizi yedekleyin.

2. Çekirdek veya kütüphane güncellemelerinden önce MongoDB servisini durdurun:

   sudo systemctl stop mongod

3. Güncellemeleri uygula:

   sudo apt update && sudo apt upgrade -y

4. Servisi yeniden başlatın ve düzgün çalıştığını doğrulayın:

   sudo systemctl start mongod
   
   sudo systemctl status mongod

Proaktif Bakım Araçları

Bazı araçlar, devam eden bakım ve sağlık kontrollerini kolaylaştırır:

• MongoDB Compass: Verileri ve performans metriklerini görsel olarak incelemek için bir grafik arayüz.
• Atlas CLI: MongoDB Atlas üzerinde kümeleri, kullanıcıları ve yedeklemeleri yönetmek için.
• Mongosh Komut Dosyaları: Özel komut dosyaları, sağlık kontrollerini otomatikleştirebilir veya bağlantı sayıları ve disk kullanımıyla ilgili günlük raporlar oluşturabilir.
• Ansible Playbook'ları: Kurulumları otomatikleştirin, yapılandırma doğrulamasını yapın ve yedekleme zamanlamasını yönetin.

Felaket Kurtarma Testi

Bakım planlamasındaki son adım kurtarma prosedürlerini test etmektir. Bir yedek, yalnızca doğru şekilde geri yüklenirse faydalıdır.

En azından her çeyrekte bir kez:

1. En son yedeğinizi bir test sunucusuna geri yükleyin.
2. İndekslerin, kullanıcıların ve izinlerin doğru şekilde yüklendiğini doğrulayın.
3. Kurtarma süresi hedeflerinize (RTO) uyduğundan emin olmak için geri yükleme süresini ölçün.
4. Süreci belgelendirin, böylece herhangi bir yönetici acil durumda bunu uygulayabilir.

Uzun Vadeli Bakım Kontrol Listesi

Bu sorun giderme ve bakım uygulamalarını takip ederek, zaman içinde performanslı, güvenli ve dayanıklı kalan sağlıklı bir Ubuntu üzerinde MongoDB dağıtımı sürdürebilirsiniz. Tutarlı izleme ve bakım, bir kesinti veya veri kaybı olayından kurtulmaktan çok daha az maliyetlidir.

SSS

1. MongoDB neden varsayılan Ubuntu depolarında bulunmuyor?

MongoDB, lisans değişiklikleri nedeniyle Ubuntu'nun varsayılan depolarından 18.04 sürümünden sonra kaldırıldı. MongoDB Sunucu Tarafı Kamu Lisansı (SSPL), Debian ve Ubuntu projeleri tarafından açık kaynak olarak tanınmamaktadır. Sonuç olarak, Canonical artık MongoDB'yi resmi depolarında dağıtmamakta ve kullanıcıların MongoDB'yi kendi APT deposundan kurmaları gerekmektedir.

2. MongoDB'yi tamamen nasıl kaldırırım?

MongoDB'yi kaldırmak ve tüm ilişkili dosyaları silmek için aşağıdaki komutları çalıştırın:

sudo systemctl stop mongod

sudo apt purge -y mongodb-org*

sudo rm -rf /var/lib/mongodb

sudo rm -rf /var/log/mongodb

sudo rm -f /etc/apt/sources.list.d/mongodb-org-*.list

sudo apt autoremove -y

Bu işlem MongoDB servisini durdurur, ilgili tüm paketleri kaldırır, veri ve günlük dizinlerini siler ve depo kaydını temizler.

3. MongoDB'nin çalışıp çalışmadığını nasıl kontrol edebilirim?

MongoDB servisinin durumunu şu şekilde kontrol edebilirsiniz:

sudo systemctl status mongod

MongoDB çalışıyorsa, “Active: active (running)” ifadesini göreceksiniz. Alternatif olarak, bağlantıyı doğrulamak için şunu çalıştırabilirsiniz:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

Eğer komut "ok": 1 değerini döndürüyorsa, MongoDB aktif ve bağlantıları kabul ediyor demektir.

4. MongoDB küçük bir VPS üzerinde çalıştırılabilir mi?

Evet, MongoDB küçük bir VPS üzerinde çalışabilir, ancak bazı sınırlamalarla. Temel geliştirme veya test iş yükleri için, 2 CPU çekirdeği, 2 GB RAM ve 10–20 GB SSD depolamaya sahip bir sunucu yeterlidir.

Bununla birlikte, üretimde kullanım için MongoDB, en az 4 CPU çekirdeği, 8 GB RAM ve yüksek hızlı SSD veya NVMe depolamaya sahip sistemlerde en iyi performansı gösterir. Düşük bellekli ortamlarda aşırı takaslamayı önlemek için WiredTiger önbellek boyutunu ayarlamak gerekebilir.

5. MongoDB, bir onarım işlemi çalıştırdıktan sonra neden başlatılamıyor?

MongoDB, onarım işlemi root olarak çalıştırıldıysa başlatılamayabilir; çünkü bu, /var/lib/mongodb içindeki veri dosyalarının sahipliğini root:root olarak değiştirir. mongod servisi mongodb kullanıcısı olarak çalıştığı için bu dosyaları okuma veya yazma iznine sahip olmayacaktır. Bunu düzeltmek için, onarım komutunu mongodb kullanıcısı olarak çalıştırdığınızdan emin olun veya ardından doğru sahipliği geri yükleyin:

sudo chown -R mongodb:mongodb /var/lib/mongodb

6. MongoDB'nin doğru ağ arayüzlerinde dinleyip dinlemediğini nasıl anlayabilirim?

MongoDB’nin aktif dinleyicilerini şunu kullanarak doğrulayabilirsiniz:

sudo ss -tulpn | grep mongod

Bu, MongoDB'nin bağlı olduğu IP adreslerini ve portları gösterir. Beklenen IP'yi görmüyorsanız (örneğin, uygulama sunucunuzun IP'si), /etc/mongod.conf dosyasındaki bindIp değerini kontrol edin ve servisi yeniden başlatın.

7. MongoDB’nin varsayılan WiredTiger önbellek boyutunu değiştirmeli miyim?

Çoğu durumda hayır. WiredTiger otomatik olarak sistem RAM'inin yaklaşık %50'sini kullanır ve kullanılabilir belleğe göre önbellek kullanımını dinamik olarak ayarlar. MongoDB, sunucuyu diğer bellek yoğun uygulamalarla paylaşıyorsa yalnızca cacheSizeGB ayarını değiştirin. Özel MongoDB sunucuları genellikle varsayılan davranışı korumalıdır.

8. MongoDB kayıtlarım neden bu kadar büyüyor?

MongoDB, işletim verilerini /var/log/mongodb/mongod.log dosyasına sürekli olarak yazar. Log rotasyonu yapılmazsa, bu dosya çok büyük hale gelebilir. Rehberin bakım bölümünde açıklandığı gibi, eski logların otomatik olarak sıkıştırılması veya silinmesi için logrotate kullanarak log rotasyonunu yapılandırdığınızdan emin olun.

9. Replika setime daha fazla düğüm eklemeyi ne zaman düşünmeliyim?

Okuma trafiğinde sürekli artışlar, sık düğüm seçimleri, çoğaltma gecikmesi fark ettiğinizde veya birden fazla bölge veya bölgede daha yüksek kullanılabilirliğe ihtiyaç duyduğunuzda replika setinizi genişletmelisiniz. İkincil düğümler eklemek, okuma yükünü dağıtır ve özellikle üretim ortamlarında hata toleransını artırır.

10. MongoDB sunucumda TLS'nin doğru şekilde etkinleştirildiğini nasıl doğrulayabilirim?

/etc/mongod.conf dosyasında TLS yapılandırıldıktan sonra, şu şekilde bağlanın:

mongosh --tls --host <server-ip> -u admin -p --authenticationDatabase admin

Bağlantı başarılı olursa, şunu çalıştırın:

openssl s_client -connect <server-ip>:27017

Geçerli bir TLS el sıkışması ve Protocol: TLSv1.3 gibi detaylar, şifrelemenin aktif olduğunu doğrular.

Sonuç

MongoDB'yi etkili bir şekilde çalıştırmak sadece kurulum ve yapılandırmayla ilgili değildir; aynı zamanda zaman içinde performans, güvenlik ve güvenilirlik arasında bir dengeyi sürdürmekle ilgilidir. Artık üretim iş yüklerini destekleyebilen, taleple birlikte ölçeklenebilen ve beklenmedik arızalardan toparlanabilen tam donanımlı bir MongoDB sistemine sahipsiniz.

Bu kılavuzda belirtilen ilkeleri ve en iyi uygulamaları, günlük izlemeden uzun vadeli kapasite planlamasına kadar uygulayarak, MongoDB’yi herhangi bir ortamda güvenle çalıştırabilirsiniz. Bunu kendiniz yönetmeye devam edin ya da MongoDB Atlas gibi yönetilen bir hizmete geçin, MongoDB’nin iç işleyişini anlamanız her zaman verilerinizin kontrolünü elinizde tutmanızı sağlar.

Veritabanları hakkında daha fazla bilgi edinmek için, aşağıdaki eğitimleri inceleyin:

• Farklı Veri Tabanı Türleri Nelerdir? Kullanım Durumları ve Mimari Örnekleri ile Açıklandı
• SQLite vs MySQL vs PostgreSQL: İlişkisel Veri Tabanı Yönetim Sistemlerinin Karşılaştırması
• Ubuntu'ya Node.js Nasıl Kurulur
• MERN Stack ile Nasıl Başlanır

Linux-Console.net Topluluğu ile öğrenme sürecine katıldığınız için teşekkürler.