Migratiestrategieën voor Azure Cosmos DB

De ontwerpvraag

Eén Cosmos DB-account bundelt vijf onderdelen die een doel afzonderlijk moet dekken.

1. 01

   De API en het querydialect

   MongoDB-wireprotocol, of de NoSQL-API (Core/SQL). Alleen de eerste heeft op STACKIT een doel dat als directe vervanger werkt.

2. 02

   Consistentie

   Cosmos DB kent vijf niveaus: strong, bounded staleness, session, consistent prefix en eventual. De MongoDB Flex-resource heeft geen instelling voor een consistentiebeleid, dus het concept vermeldt het beleid als niet overgenomen.

3. 03

   Distributie

   Accounts repliceren naar meerdere regio's. De engine meldt dat STACKIT geen beheerde databasereplicatie over meerdere regio's kent.

4. 04

   Doorvoermodel

   Request units en autoscale worden niet overgenomen. U dimensioneert in plaats daarvan een flavor en opslag.

5. 05

   Partitionering en change feed

   Partitiesleutels en de change feed worden voor de NoSQL-API opnieuw ontworpen.

De opties

Alleen afwegingen, geen benchmarks. De eerste rij is wat de run voor de MongoDB-API opleverde.

Alleen accounts met één regio: een NoSQL-account met meerdere regio's vergt een handmatige beoordeling, zie hieronder.

Het account met MongoDB-API, omgezet

Een kleine omgeving, voor deze pagina opgesteld en op 4 november 2026 door StackToIT beoordeeld. Links: de Azure-invoer. Rechts: het resourceblok van de STACKIT-Terraform die de engine schreef; de beoordelingsopmerkingen erboven zijn hier weggelaten.

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
  }
}

• Eén node, als beginpunt

  Het concept stelt het type Single in met één replica, een dagelijkse back-up om 02:00 en variabelen voor CPU, RAM, opslag en de toegangslijst. De STACKIT-documentatie noemt een replica set de betere keuze voor de meeste productiegevallen, dus herzie dit.

• De versie wordt overgenomen

  Het concept stelt 7.0 in, de versie van het bronaccount. Cosmos DB implementeert een niveau van het MongoDB-wireprotocol, niet MongoDB zelf, dus een medewerker controleert de compatibiliteit van de driver.

• Wat niet wordt overgenomen

  Consistentiebeleid, regio's en failoverprioriteiten, capabilities en doorvoer staan naast het blok vermeld als niet overgenomen.

Het account met NoSQL-API, aangehouden

Dit account repliceert naar twee regio's en bevat een database en een container. Het assessment legt een kritieke bevinding vast en laat de klasse aan een medewerker over.

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."
      }
    ]
  }
}

• Twee regio's, een kritieke bevinding

  In de run voor de service mapping was een NoSQL-account met één regio REDESIGN. Dit account voegt een tweede regio, een database en een container toe; de run legt een kritieke bevinding over meerdere regio's vast en de klasse is MANUAL_REVIEW. De run zegt niet welk verschil de klasse bepaalt. Beide klassen betekenen dat een architect eigenaar is van de volgende stap.

• Er wordt geen Terraform geschreven

  Het doel mongodbflex wordt als kandidaat genoemd, maar er wordt niets opgesteld voor het account zolang het datamodel en het beschikbaarheidsontwerp niet zijn bepaald.

Een resource die de build niet kent

De MongoDB-collectie met de shardsleutel en index is een afzonderlijk resourcetype. Deze build heeft er geen catalogusvermelding voor, dus die verschijnt als handmatige eenheid met zekerheidsniveau LOW en als waarschuwing op het account. Het fragment toont de velden zoals de run ze schreef.

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"
  }
}

• Neem het collectieontwerp zelf over

  De shardsleutel userId en de unieke _id-index worden niet beoordeeld. STACKIT beschrijft sharding op MongoDB Flex als laatste redmiddel na replica sets, indexering en verticaal schalen.

Hoe u beslist

• Begin met de API

  Som elk account en zijn API op. MongoDB-accounts volgen de directe route, NoSQL-accounts vereisen een ontwerpbeslissing.

• Bepaal uw aanpak voor de regio's

  Als het account meerdere regio's beslaat, schrijf dan op waarom. Kies daarna één regio, een aanpak op applicatieniveau of op Azure blijven voor die workload.

• Controleer de consistentiebehoeften

  Zoek uit welke leesbewerkingen afhangen van garanties voor session of bounded staleness. Test de applicatie tegen een MongoDB Flex-instance van het type dat u van plan bent, single of replica set.

• Dimensioneer vanuit de data

  De planningsrichtlijn van STACKIT suggereert een factor 2 tot 2,5 voor datagroei over twee jaar en merkt op dat BSON 10 tot 15 procent groter kan zijn dan JSON. Opslag kan zonder downtime worden vergroot maar niet verkleind, en het type instance kan later niet worden gewijzigd.

• Noem een eigenaar en een datum

  Voor beide accounts staat in het dataverplaatsingsbestand het mechanisme op UNKNOWN en staan de dataclassificatie, RPO en toegestane downtime op NOT_PROVIDED. Vul ze in voordat u een tool kiest.

Vragen over Cosmos DB-migraties

Bronnen

• Microsoft Learn: Azure Cosmos DB for MongoDB
• Microsoft Learn: consistentieniveaus van Cosmos DB
• STACKIT-documentatie: MongoDB Flex
• STACKIT-documentatie: uw MongoDB Flex-instance plannen
• STACKIT-documentatie: PostgreSQL Flex