Datenbankmigration nach STACKIT: Architektur und Kompatibilität

Eine Multi-AZ-PostgreSQL-Instanz, konvertiert

Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die RDS-Instanz der Eingabe. Rechts die PostgreSQL-Flex-Instanz, die die Engine geschrieben hat (die Prüfkommentare über dem Block in der Datei sind ausgelassen).

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 wird zum Replica-Flavor

  Die Klasse mit 4 vCPU und 16 GiB samt Standby wird zu 4.32-replica, 4 vCPU und 32 GiB, dem kleinsten Hochverfügbarkeits-Flavor, der sie im vom Lauf gelesenen eu01-Katalog abdeckt. Der Entwurf behauptet nichts über das Failover-Verhalten; keine vom Lauf gelesene STACKIT-Seite nennt es.

• Speicher wird aufgerundet

  Aus 300 GiB werden 323. STACKIT nennt die Größe nur in Gigabyte; deshalb rechnet der Entwurf mit 10^9 Byte je GB und rundet auf, nie unter die Quelle.

• Aufbewahrung und Zugriff ändern sich

  14 Tage Backups werden zu retention_days 32, markiert als TRANSFORMED. Die Zugriffsliste ist eine Variable ohne Standardwert, weil die Quelle nicht als öffentlich belegt ist und der STACKIT-Endpunkt über eine Zugriffsliste erreicht wird.

Eine Key-Value-Tabelle, neu entworfen

Aus demselben Lauf. DynamoDB hat kein Gegenstück; deshalb stuft der Lauf die Tabelle als REDESIGN ein und entwirft eine Alternative: eine MongoDB-Flex-Instanz für die Tabellen der Umgebung.

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

• Eine Alternative, kein Äquivalent

  Der Lauf sagt das in seiner Begründung: Schlüsseldesign, Kapazitätsmodi und bedingte Schreibvorgänge werden nicht übernommen. PostgreSQL Flex mit JSONB-Spalten ist die andere Option.

• Anwendungsarbeit, keine Datenarbeit

  Die Prüfzeilen verlangen, die Datenzugriffsschicht gegen die MongoDB-API neu zu schreiben und die Instanz nach Datenvolumen und Anfragelast zu dimensionieren, weil sich Kapazitätseinheiten nicht übertragen lassen.

Engine für Engine: Ziel und Klasse

Eine Zeile je Datenspeicher des Laufs, alle mit MEDIUM-Konfidenz, dazu das Oracle-Datenbanksystem aus dem Oracle-Cloud-Lauf unseres Quellenvergleichs.

Klassen und Tests stammen aus dem assessment.json des Laufs. Stand November 2026 nennt die MariaDB-Seite von STACKIT Version 10.6 als veraltet, mit geplanter Abschaltung am 1. Juli 2027, und verlangt bis dahin 10.11 oder neuer.

Was der Entwurf an jeder Instanz ändert

Die Zeilen stammen aus den Kommentaren in terraform/data.tf zu nicht Übernommenem, zur Wiederherstellung und zum Ledger; Backup-Takt von MariaDB und Klonverhalten von PostgreSQL Flex sind gegen die unten genannte STACKIT-Dokumentation geprüft.

So werden die Daten übertragen

Der Lauf listet in migration/data-movement.md sechs zustandsbehaftete Einheiten. Für jede hält er fest, dass keine Methode gewählt ist, weil Größe, tolerierte Ausfallzeit und Konsistenz nicht in der Quelle stehen.

1. 01

   Eine Methode je Einheit wählen

   Für PostgreSQL enthält der Plan typisierte Schritte für Dump und Restore, logische Replikation oder ein eigenes Werkzeug. Für SQL Server beschreibt die Übergabe ein natives Backup jeder Datenbank auf RDS, das Kopieren der .bak-Dateien in einen STACKIT-Bucket und den Import in SQLServer Flex; laut Funktionsseite von SQLServer Flex geht eine Wiederherstellung nur in eine neue Datenbank.

2. 02

   Generalprobe mit Zeitmessung

   Ein Preflight-Schritt schließt offene Prüfungen (Versionen, Erweiterungen, Rollen, Netzwerk); eine Generalprobe überträgt eine Kopie in eine Scratch-Datenbank und hält die Zeiten fest. Aus diesen Zeiten ergibt sich das Schreibstopp-Fenster.

3. 03

   Schreibstopp, Synchronisierung, Abgleich

   Schreibende Clients werden gestoppt, ein letzter Sync läuft, dann werden Zeilenzahlen, Prüfsummen und eine Anwendungsabfrage verglichen. Ergebnis ist ein festgehaltenes GO oder NO-GO. Bei NO-GO zeigen die Clients weiter auf die unberührte Quelle.

4. 04

   Verbindung umstellen

   Clients ändern Host, Port, Datenbankname und Zugangsdaten. Wo keine Ressource der Quelle auf eine Datenbank verweist, vermerkt der Plan, dass die Anwendungen außerhalb der Quelle liegen und ihre Verantwortlichen sie auflisten.

5. 05

   Den Rückweg offen halten

   Aufräumschritte warten auf die Rollback-Entscheidung. Danach ist der Rückweg der letzte Snapshot der Quelle, und der Plan markiert die Stilllegung der Datenbank als nicht umkehrbar.

Entscheidungen, die Ihre Architekten treffen

• Engine für MySQL- und Redis-Umgebungen

  MariaDB für MySQL, Valkey für Redis: Ein Kompatibilitätstest entscheidet, nicht die Klasse.

• Dokument oder relational bei DynamoDB

  MongoDB Flex oder PostgreSQL Flex mit JSONB; in beiden Fällen wird die Zugriffsschicht neu geschrieben.

• Exponierung jedes Endpunkts

  CIDRs der Zugriffsliste oder ein Network-Area-Scope, wo Ihr Konto ihn hat.

• Stufe der Hochverfügbarkeit

  Einzelknoten oder Replica-Flavor, aus den Wiederanlaufzielen, nicht allein aus der Quellklasse.

• Oracle Database

  Neue Engine mit Konvertierung oder selbst betriebenes Oracle unter eigener Lizenz.

• Methode und Fenster des Datenumzugs

  Eine offene Entscheidung in decisions.json umfasst alle sechs zustandsbehafteten Einheiten, mit einem Eintrag je Einheit; beantworten Sie sie Einheit für Einheit.

• SQL-Server-Lizenz

  Der Lauf hält fest, dass die gelesenen STACKIT-Seiten für SQLServer Flex keine Lizenzbedingungen nennen; klären Sie im Vertrag, ob die Lizenz enthalten ist oder eine eigene genutzt wird.

Fragen von Datenbankteams

Quellen

• STACKIT SQLServer Flex: unterstützte und nicht unterstützte Funktionen
• STACKIT PostgreSQL Flex: Überblick
• STACKIT MariaDB: Überblick
• STACKIT PostgreSQL Flex: Backup und Klon
• STACKIT MariaDB: Backup und Wiederherstellung