Databasemigratie naar STACKIT: architectuur en compatibiliteit

Een Multi-AZ PostgreSQL-instance, omgezet

Een kleine omgeving voor deze pagina, op 4 november 2026 beoordeeld door StackToIT. Links: de RDS-instance uit de invoer. Rechts: de PostgreSQL Flex-instance die de engine schreef (de reviewopmerkingen boven het blok in het bestand zijn weggelaten).

resource "aws_db_instance" "ledger" {
  identifier              = "ledger-pg"
  engine                  = "postgres"
  engine_version          = "16.4"
  instance_class          = "db.m6g.xlarge"
  allocated_storage       = 300
  multi_az                = true
  username                = "ledger"
  password                = var.db_password
  db_subnet_group_name    = aws_db_subnet_group.data.name
  backup_retention_period = 14
}

resource "stackit_postgresflex_instance" "ledger" {
  project_id = var.project_id
  name       = "ledger-pg"
  version    = "16"
  flavor_id  = "4.32-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 323
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.ledger_allowed_cidrs
    access_scope = var.ledger_access_scope == "SNA" ? "SNA" : null
  }
  retention_days = 32
}

• Multi-AZ wordt een replica-flavor

  De klasse met 4 vCPU en 16 GiB met een standby wordt 4.32-replica, 4 vCPU en 32 GiB: de kleinste flavor met hoge beschikbaarheid die dit afdekt in de eu01-catalogus die de run las. Het concept zegt niets over het gedrag bij een failover; geen enkele STACKIT-pagina die de run las, zegt dat.

• Opslag wordt naar boven afgerond

  300 GiB wordt 323. STACKIT geeft de grootte alleen in gigabytes, dus het concept rekent om met 10^9 bytes per GB en rondt naar boven af, nooit naar minder dan de bron.

• Retentie en toegang veranderen

  14 dagen back-ups worden retention_days 32, gemarkeerd als TRANSFORMED. De toegangslijst is een variabele zonder standaardwaarde, omdat niet is bewezen dat de bron openbaar is en het STACKIT-endpoint via een toegangslijst wordt bereikt.

Een key-value-tabel, opnieuw ontworpen

Uit dezelfde run. DynamoDB heeft geen tegenhanger, dus de run classificeert de tabel als REDESIGN en stelt één alternatief op: een MongoDB Flex-instance voor de tabellen van de omgeving.

resource "aws_dynamodb_table" "carts" {
  name         = "carts"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "cart_id"

  attribute {
    name = "cart_id"
    type = "S"
  }

  ttl {
    attribute_name = "expires_at"
    enabled        = true
  }
}

resource "stackit_mongodbflex_instance" "dynamodb_tables" {
  project_id = var.project_id
  name       = "dynamodb-tables"
  acl        = var.dynamodb_tables_allowed_cidrs
  version    = var.dynamodb_tables_version
  flavor = {
    cpu = var.dynamodb_tables_cpu
    ram = var.dynamodb_tables_ram
  }
  replicas = 3
  storage = {
    class = var.mongodbflex_storage_class
    size  = var.dynamodb_tables_storage_gb
  }
  backup_schedule = "0 2 * * *"
  options = {
    type                       = "Replica"
    point_in_time_window_hours = var.dynamodb_tables_pitr_hours
  }
}

• Een alternatief, geen equivalent

  De run geeft dat aan in de motivering: sleutelontwerp, capaciteitsmodi en voorwaardelijke schrijfacties worden niet overgenomen. PostgreSQL Flex met JSONB-kolommen is de andere optie.

• Applicatiewerk, geen datawerk

  De reviewregels vereisen dat de datatoegangslaag wordt herschreven voor de MongoDB API en dat de instance wordt gedimensioneerd op datavolume en belasting, omdat capaciteitseenheden niet vertaalbaar zijn.

Engine voor engine: doel en klasse

Eén rij per datastore van de run, allemaal zekerheidsniveau MEDIUM, plus het Oracle Database-systeem uit de Oracle Cloud-run van onze vergelijking van bronclouds.

Klassen en tests zijn die van de run zelf, overgenomen uit assessment.json. Per november 2026 meldt de MariaDB-pagina van STACKIT dat versie 10.6 is verouderd (deprecated) en op 1 juli 2027 wordt ontmanteld, en verzoekt om uiterlijk op die datum 10.11 of nieuwer te gebruiken.

Wat het concept op elke instance wijzigt

De rijen komen uit de commentaren over niet overgenomen eigenschappen, herstel en het register in terraform/data.tf, waarbij het back-upritme van MariaDB en het clone-gedrag van PostgreSQL Flex zijn gecontroleerd aan de hand van de hieronder genoemde STACKIT-documentatie.

Hoe de data verhuist

De run noemt zes stateful eenheden in migration/data-movement.md. Voor elk vermeldt hij dat er geen methode is gekozen, omdat omvang, toegestane downtime en consistentie niet in de bron staan.

1. 01

   Per eenheid een methode kiezen

   Voor PostgreSQL bevat het plan getypeerde stappen voor dump en restore, logische replicatie of een eigen tool. Voor SQL Server beschrijft de overdracht een native back-up van elke database op RDS, een kopie van de .bak-bestanden naar een STACKIT-bucket en een import in SQLServer Flex; de functiepagina van SQLServer Flex zegt dat een herstel alleen naar een nieuwe database gaat.

2. 02

   Oefenen en de tijd meten

   Een preflightstap sluit open controles af (versies, extensies, rollen, netwerk); een proefrun verplaatst een kopie naar een scratchdatabase en legt de tijden vast. Het venster voor de schrijfstop volgt uit die tijden.

3. 03

   Schrijfstop, synchroniseren, reconcile

   Schrijvers worden gestopt, een laatste sync draait, en aantallen, checksums en één applicatiequery worden vergeleken. Het resultaat is een vastgelegd GO of NO-GO. Bij NO-GO wijzen de clients nog naar de onaangeroerde bron.

4. 04

   De verbinding omschakelen

   Clients wijzigen host, poort, databasenaam en inloggegevens. Waar geen enkele resource van de bron naar een database verwijst, noteert het plan dat de applicaties buiten de bron liggen en hun eigenaren ze opsommen.

5. 05

   De weg terug bewaren

   Opruimstappen wachten op de rollbackbeslissing. Daarna is de weg terug de laatste snapshot van de bron, en het plan markeert de ontmanteling van de database als niet omkeerbaar.

Beslissingen van de architect

• Engine voor MySQL- en Redis-omgevingen

  MariaDB voor MySQL, Valkey voor Redis: een compatibiliteitstest beslist, niet de klasse.

• Document of relationeel voor DynamoDB

  MongoDB Flex of PostgreSQL Flex met JSONB; beide vergen een herschreven toegangslaag.

• Bereikbaarheid van elk endpoint

  CIDR's in de toegangslijst, of een Network Area-scope waar uw account die heeft.

• Niveau van hoge beschikbaarheid

  Enkele node of replica-flavor, afgeleid van de herstelobjectieven, niet alleen van de bronklasse.

• Oracle Database

  Een nieuwe engine met conversie, of zelf beheerde Oracle onder uw eigen licentie.

• Methode en venster voor dataverplaatsing

  Eén open beslissing in decisions.json dekt alle zes stateful eenheden, met één lid per eenheid; beantwoord die eenheid voor eenheid.

• SQL Server-licentie

  De run legt vast dat de STACKIT-pagina's die hij las geen licentievoorwaarden voor SQLServer Flex noemen; leg in het contract vast of de licentie is inbegrepen of u uw eigen licentie gebruikt.

Vragen van databaseteams

Bronnen

• STACKIT SQLServer Flex: ondersteunde en niet-ondersteunde functies
• Overzicht van STACKIT PostgreSQL Flex
• Overzicht van STACKIT MariaDB
• Back-up en clone van STACKIT PostgreSQL Flex
• Back-up en herstel van STACKIT MariaDB