Einheit 4.1: Datenbank- und Caching-Integration

Einführung

Sie bauen das TaskBoard API und die Datenebene muss auf IONOS gemanagten Datenbanken ausgeführt werden. Das ändert einige Annahmen, die Sie möglicherweise aus anderen Clouds mitbringen. Gemanagte Datenbanken werden hier über ein privates LAN erreicht, nicht über einen öffentlichen Endpunkt, und jede Clientverbindung ist TLS-verschlüsselt. Die Datenbank-Cluster stellen keine Lesereplikas bereit, die Sie für den Datenverkehr verwenden können. Ihr Skalierungshebel für Lesevorgänge ist nicht ein Replikendpunkt, sondern der In-Memory DB-Cache.

Diese Einheit ist Verbindungscodes. Sie werden psycopg2 und SQLAlchemy mit PostgreSQL, MySQL-Connector mit MariaDB, pymongo mit MongoDB und Redis-py mit dem In-Memory DB Cluster, alles mit TLS und Pooling, verbinden. Sie werden auch die zwei operativen Realitäten behandeln, die Entwickler beeinträchtigen: Verbindungsobergrenzen sind durch Cluster RAM festgelegt und können nicht durch eine Client-Flag erhöht werden, und der Backup Service sichert keine gemanagten Datenbanken, so dass die Wiederherstellung die eigene PITR der Datenbank und Ihre eigenen logischen Dump ist.

1. Verbindung mit Managed PostgreSQL

PostgreSQL-Cluster hören auf Port 5432 und leben in einem privaten LAN innerhalb Ihres Rechenzentrums. Das Cluster-Objekt enthält eine datacenterId, eine lanId und eine primaryInstanceAddress, und Ihre Anwendung verbindet sich mit dieser primären Instanz-Adresse. Es gibt keinen öffentlichen Hostnamen. Der Standard-SSL-Modus ist prefer und TLS kann nicht durch den Client deaktiviert werden, also planen Sie verschlüsselte Verbindungen von der ersten Codezeile an.

Die unterstützten Hauptversionen sind 14, 15 und 16. Das Serverzertifikat ist mit dem ISRG Root X1-Root verbunden, sodass ein aktueller CA-Bundle auf Ihrem Anwendungshost die Verbindung ohne zusätzliche Einrichtung validiert.

1.1 Verbindung mit psycopg2

Verbinden Sie mit sslmode=require, damit der Treiber geschlossen wird, wenn TLS nicht verhandelt werden kann. Der Host ist die Cluster-Primärinstanz-Adresse, die auf Ihrem privaten LAN erreichbar ist.

import psycopg2

conn = psycopg2.connect(
    host="10.7.222.10",        # primaryInstanceAddress from the cluster object
    port=5432,
    dbname="taskboard",
    user="taskboard_app",
    password="<from-secret-store>",
    sslmode="require",
    connect_timeout=10,
)
conn.autocommit = False

with conn.cursor() as cur:
    cur.execute(
        "INSERT INTO tasks (title, status) VALUES (%s, %s) RETURNING id",
        ("Ship unit 4.1", "open"),
    )
    task_id = cur.fetchone()[0]
    conn.commit()
print(f"Inserted task {task_id}")

Für asyncpg in einem asynchronen Dienst übergeben Sie ssl="require" und liefern den gleichen Host, Port und Anmeldeinformationen. Bauen Sie nie SQL-Zeichenfolgen mit f-Zeichenfolgen, verwenden Sie stattdessen Platzhalter wie oben gezeigt.

1.2 Verbindungsgrenzen sind durch RAM festgelegt

Der max_connections-Wert wird aus Cluster RAM berechnet und ist nicht benutzerkonfigurierbar. Die folgende Tabelle ist die exakte Zuordnung, die durch die Plattform durchgesetzt wird.

Davon sind 11 Verbindungen reserviert, sodass Ihr Anwendungspool unter der veröffentlichten Zahl minus den reservierten Plätzen bleiben muss. Da diese Obergrenze fest ist, können Sie "zu viele Verbindungen" nicht durch Erhöhen einer Server-Einstellung lösen. Sie lösen es mit Pooling, das im nächsten Schritt behandelt wird.

2. Verbindungspooling

Es gibt keine Lese-Replikate. Jeder Lese- und Schreibvorgang trifft auf die einzelne primäre Instanz, sodass eine unbeschränkte Anwendung, die pro Anfrage eine Verbindung öffnet, die feste max_connections-Obergrenze schnell erschöpfen wird. Pooling ist obligatorisch, nicht optional, und Sie haben zwei Ebenen, die Sie gemeinsam verwenden können: einen Anwendungsseitigen Pool und den gemanagten PgBouncer-Pooler.

2.1 Anwendungsseitiger Pool mit SQLAlchemy

Begrenzen Sie den SQLAlchemy-Pool deutlich unter der Cluster-Obergrenze und aktivieren Sie pool_pre_ping, damit veraltete Verbindungen recycelt und nicht während eines Fehlerfalls an eine Anfrage übergeben werden.

from sqlalchemy import create_engine, text

engine = create_engine(
    "postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:5432/taskboard",
    connect_args={"sslmode": "require"},
    pool_size=20,          # steady-state connections
    max_overflow=10,       # burst headroom, keep total well under the ceiling
    pool_pre_ping=True,
    pool_recycle=1800,
)

with engine.connect() as conn:
    rows = conn.execute(text("SELECT id, title FROM tasks WHERE status = :s"),
                        {"s": "open"}).fetchall()

Wenn Sie N Anwendungsreplikate ausführen, sieht die Cluster N * (pool_size + max_overflow) Verbindungen. Dimensionieren Sie den Pool gegen die Cluster-Gesamtsumme geteilt durch Ihre Replikateanzahl, wobei Sie einen Spielraum lassen.

2.2 Gemanagter PgBouncer-Pooler

PostgreSQL-Cluster bieten einen gemanagten PgBouncer-Pooler. Sie können ihn aktivieren und den Poolmodus auswählen. Die unterstützten Modi sind transaction (Standard) und session. Der Pooler hört auf Port 6432, anstatt auf dem Datenbankport 5432.

# Route the app through PgBouncer: same host, pooler port 6432
engine = create_engine(
    "postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:6432/taskboard",
    connect_args={"sslmode": "require"},
    pool_size=10, max_overflow=5, pool_pre_ping=True,
)

Verwenden Sie den transaction-Modus für typische Web-Workloads, damit eine Backend-Verbindung nur für die Dauer einer Transaktion gehalten wird, was die Anzahl der Clients multipliziert, die die feste Verbindungs-Obergrenze bedienen kann. Sitzungsbezogene Funktionen wie vorbereitete Anweisungen und SET, die über eine Sitzung hinweg bestehen bleiben müssen, benötigen den session-Modus.

3. MariaDB und MongoDB Integration

PostgreSQL ist einer von mehreren gemanagten Engines, und das Verbindungsmodell ist konsistent: private LAN, TLS erzwungen, feste Grenzen. Der Treiber und die Verbindungs-Grenzen-Mathematik unterscheiden sich pro Engine.

3.1 MariaDB

MariaDB hört auf Port 3306. Alle Client-Verbindungen sind TLS-verschlüsselt und das Server-Zertifikat wird von Let's Encrypt ausgestellt, sodass ein Standard-CA-Bundle es validiert. Nur Langzeit-Support-Versionen werden angeboten, beginnend mit 10.6 (zum Beispiel 10.6 und 10.11). Replikation ist nur asynchron.

Der Cluster max_connections beträgt 500, und jeder Benutzer ist auf 250 Verbindungen begrenzt. Diese pro-Benutzer-Grenze ist absichtlich: weil ein Benutzer höchstens 250 der 500 Slots belegen kann, ist ein einzelner außer Kontrolle geratener Anwendungsbenutzer weit weniger wahrscheinlich, den gesamten Cluster auszulasten.

import mysql.connector

cnx = mysql.connector.connect(
    host="10.7.222.20",
    port=3306,
    database="taskboard",
    user="taskboard_app",
    password="<pw>",
    ssl_disabled=False,        # TLS is enforced server-side regardless
    pool_name="taskboard_pool",
    pool_size=20,
)
cur = cnx.cursor()
cur.execute("SELECT id, title FROM tasks WHERE status = %s", ("open",))
for task_id, title in cur.fetchall():
    print(task_id, title)
cur.close(); cnx.close()

Der Speicher ist auf 2 TB pro Cluster begrenzt, und eine einzelne Instanz kann nicht mehr als 16 Kerne überschreiten.

3.2 MongoDB

MongoDB-Cluster präsentieren eine Verbindungszeichenfolge in der Form mongodb+srv://m-<id>.mongodb.<region>.ionos.com, die Sie typischerweise aus einer Terraform-Ausgabe lesen, anstatt sie hart zu codieren. Unterstützte Versionen sind 6.0 und 7.0. Serverseitige Verbindungs-Pooling wird nicht bereitgestellt, sodass der Treiberseitige Pool in pymongo Ihr Pool ist.

from pymongo import MongoClient

uri = "mongodb+srv://taskboard_app:<pw>@m-abc123.mongodb.de-txl.ionos.com"
client = MongoClient(
    uri,
    tls=True,
    maxPoolSize=50,
    serverSelectionTimeoutMS=5000,
    retryWrites=True,
)
db = client["taskboard"]
db.task_events.insert_one({"task_id": 42, "event": "created"})
print(db.task_events.count_documents({"task_id": 42}))

Die maximale Verbindungsanzahl skaliert mit RAM. Die folgende Tabelle ist die erzwungene Zuordnung.

Die Rollenzuweisung verwendet die integrierten MongoDB-Rollen wie read, readWrite, dbAdmin und clusterMonitor. Gewähren Sie readWrite, die auf die taskboard-Datenbank für den Anwendungsbenutzer beschränkt ist, anstatt eine Cluster-weite Admin-Rolle.

4. In-Memory DB (Redis) Caching

Da kein gemanagtes Modul Lese-Replikate bereitstellt, ist die In-Memory DB Cluster die IONOS-eigene Methode, um Lesevorgänge zu skalieren. Sie ist mit Redis OSS 7.2 kompatibel und hört auf Port 6379, und TLS verwendet eine Let's Encrypt-Zertifizierungsstelle, sobald Sie die Instanz so konfigurieren, dass sie verwendet wird (TLS ist standardmäßig nicht aktiviert, daher müssen Sie es explizit aktivieren, wie das Redis-py-Beispiel unten mit SSL=True tut). Ein Cluster kann bis zu 5 Knoten haben. Der unterliegende Valkey-Motor standardmäßig auf eine maximale Anzahl von 10.000 Client-Verbindungen (maxclients).

Die Standard-Verdrängungsrichtlinie ist allkeys-lru und die Persistenz standardmäßig None, was die richtige Haltung für einen reinen Cache ist: Behandeln Sie ihn als flüchtig und stellen Sie sicher, dass Sie ihn immer aus der Quelldatenbank wieder aufbauen können.

4.1 Verbindung mit Redis-py

import redis

r = redis.Redis(
    host="10.7.222.30",
    port=6379,
    password="<pw>",
    ssl=True,
    ssl_cert_reqs="required",
    socket_timeout=2,
    decode_responses=True,
)
r.set("health", "ok", ex=30)
print(r.get("health"))

4.2 Cache-Aside-Muster

Cache-Aside ist der Standard-Lese-Pfad: Überprüfen Sie den Cache, fallen Sie auf die Datenbank zurück, wenn ein Treffer fehlt, und füllen Sie dann den Cache. Legen Sie ein TTL fest, damit veraltete Einträge ablaufen, auch wenn kein Schreibvorgang sie ungültig macht.

import json

def get_task(task_id, r, engine):
    key = f"task:{task_id}"
    cached = r.get(key)
    if cached:
        return json.loads(cached)              # cache hit
    with engine.connect() as conn:
        row = conn.execute(
            text("SELECT id, title, status FROM tasks WHERE id = :id"),
            {"id": task_id}).mappings().first()
    if row:
        r.set(key, json.dumps(dict(row)), ex=300)   # populate with 5 min TTL
    return dict(row) if row else None

4.3 Write-Through-Muster

Write-Through aktualisiert die Datenbank und den Cache in derselben Operation, sodass Lesevorgänge nie einen veralteten Wert nach einem Schreibvorgang liefern. Zuerst wird die Datenbank aktualisiert und der Cache wird nur aktualisiert, wenn der Commit erfolgreich war.

def update_task_status(task_id, status, r, engine):
    with engine.begin() as conn:                # commits on context exit
        conn.execute(text("UPDATE tasks SET status = :s WHERE id = :id"),
                     {"s": status, "id": task_id})
    r.set(f"task:{task_id}", json.dumps({"id": task_id, "status": status}),
          ex=300)

Redis passt zu TaskBoard an zwei weiteren Stellen: der Sitzungsspeicherung und dem Zwischenspeichern der Abfrageergebnisse der Aufgabenliste, die ansonsten bei jedem Seitenladen den einzelnen Primärspeicher überlasten würden.

5. Wiederherstellung: PITR und die Backup Service-Lücke

Die Wiederherstellung für gemanagte Datenbanken ist die Punkt-in-der-Zeit-Wiederherstellung der Datenbank selbst, nicht die Backup Service. Die Backup Service sichert keine gemanagten DBaaS, daher dürfen Sie nicht annehmen, dass Ihre Aufgaben-Daten von einer Sicherungseinheit erfasst werden. Für logische Exporte über das PITR-Fenster hinweg planen Sie pg_dump oder das MariaDB-Dump-Tool aus Anwendungscode oder einem Cron-Job und speichern die Ausgabe in Object Storage.

PostgreSQL und MariaDB haben beide standardmäßig ein 7-Tage-Punkt-in-der-Zeit-Wiederherstellungs-Fenster auf v1-Clustern, aber auf ihren v2-APIs kann die Aufbewahrungsfrist von 1 bis 365 Tagen über backup.retentionDays konfiguriert werden, daher überprüfen Sie die Version und die Aufbewahrungsfrist Ihres Cluster-API, bevor Sie ein hartes 7-Tage-Fenster annehmen. PITR läuft durch die REST-API. Der Basispfad für PostgreSQL ist https://api.ionos.com/databases/postgresql, und eine Wiederherstellung ist eine In-Place-Operation, die Datenbank ist während der Ausführung nicht verfügbar.

5.1 Auslösen der PostgreSQL-PITR über API

curl -X POST \
  "https://api.ionos.com/databases/postgresql/clusters/${CLUSTER_ID}/restore" \
  -H "Authorization: Bearer ${IONOS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "recoveryTargetTime": "2026-06-04T09:30:00Z"
  }'

Der recoveryTargetTime ist ein ISO-8601-Timestamp und ist nicht einschließlich. Wiederherstellungsbeschränkungen zum Codieren: nur eine Sicherung kann gleichzeitig wiederhergestellt werden, das Cluster muss AVAILABLE sein, bevor Sie eine Wiederherstellung auslösen, Sie können nur von der gleichen oder einer älteren Hauptversion wiederherstellen, und eine Wiederherstellung kann die Datenbank in eine andere Region verschieben. Die Plattform empfiehlt mindestens 4 GB RAM während der Wiederherstellung, die Sie danach wieder herunterskalieren können.

API Referenz-Quick-Card

Wichtige API-Endpunkte für die Integration von gemanagten Datenbanken:

Basis-URL: https://api.ionos.com/databases/postgresql (regionspezifische Hosts gelten für In-Memory DB und MariaDB) Authentifizierung: Authorization: Bearer <token>

Code-Lab

Ziel: Verbinden Sie das TaskBoard API mit PostgreSQL und dem In-Memory DB-Cache, fügen Sie eine Aufgabe hinzu, cachen Sie den Lesevorgang und überprüfen Sie TLS.

Voraussetzungen:

• IONOS Cloud-Konto mit API-Token
• Ein laufender PostgreSQL-Cluster und In-Memory DB-Replikatsatz auf einem gemeinsamen privaten LAN
• Python 3.10+ mit psycopg2-binary, sqlalchemy und redis installiert
• Die Cluster-primaryInstanceAddress und die In-Memory DB-Node-Adresse

Schritt 1: Überprüfen Sie TLS auf PostgreSQL

PGPASSWORD=$PW psql "host=10.7.222.10 port=5432 dbname=taskboard user=taskboard_app sslmode=require" -c "SELECT ssl FROM pg_stat_ssl WHERE pid = pg_backend_pid();"

Erwartete Ausgabe:

 ssl
-----
 t

Schritt 2: Erstellen Sie die Aufgaben-Tabelle

PGPASSWORD=$PW psql "host=10.7.222.10 sslmode=require dbname=taskboard user=taskboard_app" \
  -c "CREATE TABLE IF NOT EXISTS tasks (id SERIAL PRIMARY KEY, title TEXT, status TEXT);"

Erwartete Ausgabe:

CREATE TABLE

Schritt 3: Fügen Sie eine Aufgabe aus Python hinzu

from sqlalchemy import create_engine, text
engine = create_engine("postgresql+psycopg2://taskboard_app:<pw>@10.7.222.10:5432/taskboard",
                       connect_args={"sslmode": "require"}, pool_size=5, pool_pre_ping=True)
with engine.begin() as c:
    tid = c.execute(text("INSERT INTO tasks (title, status) VALUES (:t, 'open') RETURNING id"),
                    {"t": "Lab task"}).scalar()
print("task id:", tid)

Erwartete Ausgabe:

task id: 1

Schritt 4: Verbinden Sie sich mit dem Cache

import redis
r = redis.Redis(host="10.7.222.30", port=6379, password="<pw>", ssl=True,
                ssl_cert_reqs="required", decode_responses=True)
print(r.ping())

Erwartete Ausgabe:

True

Schritt 5: Cachen Sie den Lesevorgang (Cache-Aside)

import json
key = f"task:{tid}"
if not r.get(key):
    with engine.connect() as c:
        row = c.execute(text("SELECT id, title, status FROM tasks WHERE id = :id"),
                        {"id": tid}).mappings().first()
    r.set(key, json.dumps(dict(row)), ex=300)
print(r.get(key))

Erwartete Ausgabe:

{"id": 1, "title": "Lab task", "status": "open"}

Schritt 6: Bestätigen Sie, dass der zweite Lesevorgang ein Cache-Treffer ist

print("cached:", r.ttl(key), "seconds remaining")

Erwartete Ausgabe:

cached: 300 seconds remaining

Überprüfungs-Checkliste:

• [ ] psql meldet ssl = t, was bestätigt, dass TLS aktiv ist
• [ ] Aufgabenzeile eingefügt und eine ID über SQLAlchemy zurückgegeben
• [ ] r.ping() gibt True über TLS zurück
• [ ] Der zweite Lesevorgang gibt den Wert aus Redis zurück, nicht aus PostgreSQL

Aufräumen:

PGPASSWORD=$PW psql "host=10.7.222.10 sslmode=require dbname=taskboard user=taskboard_app" -c "DROP TABLE tasks;"
# Flush the lab cache key
redis-cli -h 10.7.222.30 -p 6379 -a "$PW" --tls DEL task:1

Häufige Fallstricke

Entwicklerfehler, die bei der Integration von gemanagten Datenbanken vermieden werden sollten:

1. Öffnen einer Verbindung pro Anfrage und Erschöpfen der Obergrenze

   • Problem: Unter Last wirft die Anwendung FATAL: too many connections for role oder sorry, too many clients already.
   • Warum es passiert: max_connections ist durch Cluster RAM (zum Beispiel 1000 über 8 GB) festgelegt, 11 Slots sind reserviert und es gibt keine Lesereplikate, um die Last zu verteilen. Eine nicht gepoolte App multipliziert die Verbindungen mit der Replikateanzahl.
   • Lösung: Begrenzen Sie den Pool deutlich unter der Obergrenze und leiten Sie ihn über PgBouncer im transaction-Modus auf Port 6432 um:

   create_engine(url, pool_size=20, max_overflow=10, pool_pre_ping=True)
   

2. Unter der Annahme, dass das Backup Service Ihre Datenbankdaten schützt

   • Problem: Eine schlechte Migration löscht eine Tabelle und es gibt keine Sicherungseinheit, von der aus wiederhergestellt werden kann.
   • Warum es passiert: Das Backup Service sichert keine gemanagten DBaaS-Datenbanken. Entwickler nehmen an, dass ein Sicherungstool alles abdeckt.
   • Lösung: Verwenden Sie die Datenbank-PITR (7-Tage-Standardfenster, konfigurierbar 1-365 Tage auf dem v2 API über backup.retentionDays) für die Wiederherstellung in近er Vergangenheit und planen Sie logische Datenabzüge für ältere Daten:

   pg_dump "host=10.7.222.10 sslmode=require dbname=taskboard" | gzip > taskboard-$(date +%F).sql.gz
   

3. Deaktivierung von TLS, um es "funktionell zu machen"

   • Problem: Die Verbindung schlägt lokal fehl, sodass ein Entwickler auf sslmode=disable zurückgreift.
   • Warum es passiert: Ein fehlendes oder veraltetes CA-Bundle führt zu einem Zertifikatsvalidierungsfehler, und der schnelle Workaround sieht so aus, als würde TLS deaktiviert.
   • Lösung: TLS kann nicht vom Client auf PostgreSQL deaktiviert werden (der Standardmodus ist prefer und kann nicht deaktiviert werden), daher sollte stattdessen die CA-Kette korrigiert werden. PostgreSQL verwendet eine Kette zu ISRG Root X1, MariaDB und In-Memory DB verwenden Let's Encrypt. Aktualisieren Sie das System-CA-Bundle und behalten Sie sslmode=require bei.

Zusammenfassung

Sie können jetzt Produktionsanwendungscode mit jedem IONOS-gemanagten Datenbank-Engine verbinden, wobei TLS erzwungen und Verbindungen gepoolt werden, und Sie können Daten durch den richtigen Mechanismus wiederherstellen. Das Verbindungsmodell ist konsistent über die Motoren hinweg: private LAN, verschlüsselter Transport und eine feste Verbindungsdecke, die Sie mit Pooling respektieren, anstatt mit einer Server-Flag zu kämpfen. Der In-Memory DB-Cache ist Ihr Leseskalierungswerkzeug, da keiner der Datenbank-Engines Lese-Replikate enthüllt.

Für TaskBoard im Speziellen enthält PostgreSQL die Aufgaben, Redis cacht Lese- und Sitzungsvorgänge, und die Wiederherstellung ist Datenbank-PITR plus Ihre eigenen geplanten Sicherungen. Bauen Sie diese Verbindungshilfen einmal mit Pooling und TLS integriert, und verwenden Sie sie wieder in jedem Dienst der Anwendung.

Wichtige Punkte:

• Gemanagte Datenbanken werden über die private LAN mit TLS erzwungen erreicht, nie über einen öffentlichen Endpunkt
• max_connections ist durch Cluster RAM festgelegt und nicht benutzerkonfigurierbar, so dass Pooling obligatorisch ist
• Es gibt keine Lese-Replikate, der In-Memory DB-Cache ist die IONOS-native Leseskalierungslösung
• PgBouncer im transaction-Modus auf Port 6432 multipliziert die Clients, die eine feste Decke bedienen kann
• Die Backup Service sichert DBaaS nicht, die Wiederherstellung ist Datenbank-PITR (7-Tage-Standard, konfigurierbar 1-365 Tage auf der v2 API) plus Ihre eigenen Sicherungen

Wichtige Begriffe:

• PITR: Point-in-time-Wiederherstellung, Wiederherstellung einer Cluster auf einen ISO-8601-Timestamp innerhalb des Aufbewahrungszeitraums (7-Tage-Standard; 1-365 Tage konfigurierbar auf der v2 API) über die REST API
• PgBouncer: Der Managed PostgreSQL-Verbindungspooler auf Port 6432, der transaction- und session-Pool-Modi unterstützt
• Cache-aside: Ein Lese-Muster, das den Cache überprüft, auf einen Fehlschlag in der Datenbank zurückfällt und dann den Cache mit einer TTL befüllt
• Write-through: Ein Schreib-Muster, das die Datenbank und den Cache in derselben Operation aktualisiert, um veraltete Lesevorgänge zu vermeiden
• primaryInstanceAddress: Die private-LAN-Adresse einer Datenbank-Cluster-Primärinstanz, die die Anwendung verbindet

Nächste Schritte

Weiterlernen: Einheit 4.2: Object Storage Integration

Verwandte Themen:

• Einheit 4.3: Ereignis-Streaming-Integration
• Einheit 4.4: AI Model Hub Integration