Migrationsstrategien für Azure Cosmos DB

Die Entwurfsfrage

Ein Cosmos-DB-Konto bündelt fünf Dinge, die ein Ziel einzeln abdecken muss.

1. 01

   API und Abfragedialekt

   MongoDB-Wire-Protokoll oder NoSQL-API (Core/SQL). Nur für das erste gibt es auf STACKIT ein direktes Ziel.

2. 02

   Konsistenz

   Cosmos DB bietet fünf Stufen: Strong, Bounded Staleness, Session, Consistent Prefix und Eventual. Die MongoDB-Flex-Ressource hat keine Einstellung für eine Konsistenzrichtlinie; der Entwurf führt die Richtlinie deshalb als nicht übernommen.

3. 03

   Verteilung

   Konten replizieren in mehrere Regionen. Die Engine hält fest, dass STACKIT keine verwaltete Datenbankreplikation über Regionen hinweg bietet.

4. 04

   Durchsatzmodell

   Request Units und Autoscale werden nicht übernommen. Sie dimensionieren stattdessen Flavor und Speicher.

5. 05

   Partitionierung und Change Feed

   Partitionsschlüssel und Change Feed werden bei der NoSQL-API neu durchdacht.

Die Optionen

Nur Abwägungen, keine Benchmarks. Die erste Zeile ist das, was der Lauf für die MongoDB-API erzeugt hat.

Nur Konten mit einer Region: Ein NoSQL-Konto über mehrere Regionen landet bei MANUAL_REVIEW, siehe unten.

Das Konto mit MongoDB-API, umgesetzt

Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Azure-Eingabe, rechts der Ressourcenblock des STACKIT-Terraform, den die Engine geschrieben hat; die Review-Kommentare darüber sind hier weggelassen.

resource "azurerm_cosmosdb_account" "mongo_api" {
  name                = "cosmos-sessions-mongo"
  location            = azurerm_resource_group.catalog.location
  resource_group_name = azurerm_resource_group.catalog.name
  offer_type          = "Standard"
  kind                = "MongoDB"
  mongo_server_version = "7.0"

  capabilities {
    name = "EnableMongo"
  }

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = "germanywestcentral"
    failover_priority = 0
  }
}

resource "stackit_mongodbflex_instance" "mongo_api" {
  project_id = var.project_id
  name       = "cosmos-sessions-mongo"
  acl        = var.mongo_api_allowed_cidrs
  version    = "7.0"
  flavor = {
    cpu = var.mongo_api_cpu
    ram = var.mongo_api_ram
  }
  replicas = 1
  storage = {
    class = var.mongodbflex_storage_class
    size  = var.mongo_api_storage_gb
  }
  backup_schedule = "0 2 * * *"
  options = {
    type                       = "Single"
    point_in_time_window_hours = var.mongo_api_pitr_hours
  }
}

• Ein einzelner Knoten als Startpunkt

  Der Entwurf setzt Typ Single mit einem Replikat, ein tägliches Backup um 02:00 und Variablen für CPU, RAM, Speicher und Zugriffsliste. Die STACKIT-Dokumentation nennt für die meisten Produktivfälle ein Replica Set als bessere Wahl; prüfen Sie das noch einmal.

• Die Version wird übernommen

  Der Entwurf setzt 7.0, die Version des Quellkontos. Cosmos DB implementiert eine Stufe des MongoDB-Wire-Protokolls, nicht MongoDB selbst; eine Person prüft deshalb die Treiberkompatibilität.

• Was nicht übernommen wird

  Konsistenzrichtlinie, Regionen und Failover-Prioritäten, Capabilities und Durchsatz stehen als nicht übernommen direkt am Block.

Das NoSQL-API-Konto, zurückgehalten

Dieses Konto repliziert in zwei Regionen und enthält eine Datenbank und einen Container. Die Bewertung hält ein kritisches Finding fest und überlässt die Klasse einer Person.

resource "azurerm_cosmosdb_account" "sql_api" {
  name                = "cosmos-catalog-sql"
  location            = azurerm_resource_group.catalog.location
  resource_group_name = azurerm_resource_group.catalog.name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = "germanywestcentral"
    failover_priority = 0
  }

  geo_location {
    location          = "northeurope"
    failover_priority = 1
  }
}

resource "azurerm_cosmosdb_sql_database" "catalog" {
  name                = "catalog"
  resource_group_name = azurerm_resource_group.catalog.name
  account_name        = azurerm_cosmosdb_account.sql_api.name
}

resource "azurerm_cosmosdb_sql_container" "products" {
  name                = "products"
  resource_group_name = azurerm_resource_group.catalog.name
  account_name        = azurerm_cosmosdb_account.sql_api.name
  database_name       = azurerm_cosmosdb_sql_database.catalog.name
  partition_key_paths = ["/categoryId"]
  throughput          = 800
}

{
  "id": "azurerm_cosmosdb_account.sql_api",
  "result": {
    "class": "MANUAL_REVIEW",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT MongoDB Flex or PostgreSQL Flex (JSONB) — data-model redesign",
      "resources": [
        "stackit_mongodbflex_instance"
      ]
    },
    "reason": "The NoSQL (Core/SQL) API is Cosmos DB's own protocol and query dialect; nothing else speaks it. The access layer is rewritten for MongoDB Flex or PostgreSQL JSONB, and partition-key design, consistency levels and change feed are re-thought.",
    "findings": [
      {
        "severity": "critical",
        "message": "Replicated to several regions (geo_location); STACKIT has no managed multi-region database replication."
      }
    ]
  }
}

• Zwei Regionen, ein kritisches Finding

  Im Lauf für das Service-Mapping war ein NoSQL-Konto mit einer Region ein REDESIGN. Dieses Konto hat zusätzlich eine zweite Region, eine Datenbank und einen Container; der Lauf meldet ein kritisches Mehrregionen-Finding, und die Klasse lautet MANUAL_REVIEW. Welcher Unterschied die Klasse bestimmt, sagt der Lauf nicht. Beide Klassen bedeuten: Den nächsten Schritt verantwortet ein Architekt.

• Es entsteht kein Terraform

  Das Ziel mongodbflex ist als Kandidat genannt, entworfen wird für das Konto aber nichts, bis Datenmodell und Verfügbarkeitsdesign entschieden sind.

Eine Ressource, die der Build nicht kennt

Die MongoDB-Collection mit Shard Key und Index ist ein eigener Ressourcentyp. Dieser Build hat dafür keinen Katalogeintrag; sie erscheint deshalb als manuelle Einheit mit Konfidenz LOW und als Warnung am Konto. Der Auszug zeigt die Felder so, wie der Lauf sie geschrieben hat.

resource "azurerm_cosmosdb_mongo_collection" "carts" {
  name                = "carts"
  resource_group_name = azurerm_resource_group.catalog.name
  account_name        = azurerm_cosmosdb_account.mongo_api.name
  database_name       = azurerm_cosmosdb_mongo_database.sessions.name
  shard_key           = "userId"
  throughput          = 400

  index {
    keys   = ["_id"]
    unique = true
  }
}

{
  "id": "azurerm_cosmosdb_mongo_collection.carts",
  "result": {
    "class": "MANUAL_REVIEW",
    "confidence": "LOW",
    "reason": "azurerm_cosmosdb_mongo_collection is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type).",
    "coverage": "UNKNOWN_SOURCE_TYPE"
  }
}

• Das Collection-Design übertragen Sie selbst

  Shard Key userId und der eindeutige _id-Index werden nicht bewertet. Auf MongoDB Flex beschreibt STACKIT Sharding als letzten Ausweg nach Replica Sets, Indexierung und vertikaler Skalierung.

So entscheiden Sie

• Mit der API beginnen

  Listen Sie jedes Konto mit seiner API. MongoDB-Konten folgen dem geraden Weg; NoSQL-Konten brauchen eine Designentscheidung.

• Die Regionen-Frage klären

  Erstreckt sich das Konto über Regionen, schreiben Sie auf, warum. Wählen Sie dann eine einzelne Region, einen Ansatz auf Anwendungsebene oder den Verbleib auf Azure für diese Last.

• Konsistenzbedarf prüfen

  Finden Sie heraus, welche Lesezugriffe von Session- oder Bounded-Staleness-Garantien abhängen. Testen Sie die Anwendung gegen eine MongoDB-Flex-Instanz des geplanten Typs, Single oder Replica Set.

• Aus den Daten dimensionieren

  Die STACKIT-Planungshilfe empfiehlt für das Datenwachstum der nächsten zwei Jahre einen Faktor von 2 bis 2,5 und weist darauf hin, dass BSON 10 bis 15 Prozent größer sein kann als JSON. Speicher lässt sich ohne Ausfallzeit vergrößern, aber nicht verkleinern, und der Instanztyp ist später nicht änderbar.

• Verantwortliche Person und Termin benennen

  Für beide Konten lässt die Datei zum Datenumzug den Mechanismus auf UNKNOWN sowie Datenklasse, RPO und tolerierte Ausfallzeit auf NOT_PROVIDED. Füllen Sie diese Werte aus, bevor Sie ein Werkzeug wählen.

Fragen zu Cosmos-DB-Migrationen

Quellen

• Microsoft Learn: Azure Cosmos DB for MongoDB
• Microsoft Learn: Konsistenzstufen in Cosmos DB
• STACKIT-Dokumentation: MongoDB Flex
• STACKIT-Dokumentation: MongoDB-Flex-Instanz planen
• STACKIT-Dokumentation: PostgreSQL Flex