Managed MongoDB

Managed MongoDB

Credentials, Replica Set/Failover und Backup-Grenzen. Retention-Defaults: Leistungsanhang zu den AGB.

Übergabe und Credentials

Typischer Ablauf nach Bereitstellung:

  1. Connection-String / Hosts (Replica-Set-Mitglieder oder Service-DNS im Cluster)
  2. initiale Admin- oder App-User-Credentials über vereinbarten sicheren Kanal (Secret, Password-Manager — nicht E-Mail im Klartext)
  3. TLS-Anforderungen (CA / tls=true) laut Übergabe

Kunden:

  • App-User mit Least Privilege anlegen (Database-/Collection-Rollen)
  • Initialpasswörter rotieren
  • Connection-Strings in Secrets/External Secrets führen, nicht in Git

Replica Set und Failover

Managed MongoDB läuft üblicherweise als Replica Set (Primary + Secondaries):

  • Schreibzugriff auf den Primary; Reads ggf. Secondary (App-seitig konfigurieren)
  • Failover: automatische Primary-Wahl bei Ausfall eines Members
  • kurzzeitige Schreibunterbrechung während der Election ist normal

Kunden-Apps sollten Driver mit Replica-Set-URI und Retryable Writes nutzen. Manuelles rs.stepDown / Member-Entfernen nur nach Abstimmung mit Support.

Backup-Scope

Scope Verantwortung
Full-Server / Instanz-Backup (plattformüblich) ayedo Managed Backup — Frequenz/Retention siehe Leistungsanhang
Einzel-Datenbank / Collection / Partial Restore Kunde (z. B. CronJob mit mongodump/mongorestore), sofern nicht anders vereinbart
Restore-Test nach Mitteilung Kunde innerhalb der vertraglichen Frist validieren

Technischer Cluster-Kontext: Disaster Recovery. Verbindliche Wiederherstellungsarten: Leistungsanhang.

Operative Checkliste

  • [ ] Connection-String und TLS verifiziert
  • [ ] App-User statt Shared-Admin in Produktiv-Apps
  • [ ] Driver Replica-Set + Timeouts gesetzt
  • [ ] Bedarf Partial Backup geklärt (Kunde vs. Vertrag)
  • [ ] Monitoring: Verbindungsfehler / Replica-Lag in Grafana oder Kundenstack

Weiterführend