Unit 4.1: Datenbank- und Caching-Integration

Einführung

Sie bauen die TaskBoard API, und die Datenebene muss auf IONOS CLOUD Managed Databases laufen. Das ändert einige Annahmen, die Sie aus anderen Clouds mitbringen. Managed Databases werden hier über ein privates LAN erreicht, nicht über einen öffentlichen Endpunkt, jede Client-Verbindung ist TLS-verschlüsselt, und die relationalen Datenbank-Cluster stellen keine Read Replicas bereit, auf die Sie Lesetraffic lenken könnten (nur MongoDB Enterprise kann lesbare Secondaries hinzufügen). Ihr Hebel für Read-Scaling ist kein Replica-Endpunkt, sondern der In-Memory DB Cache.

Diese Unit ist Verbindungscode. Sie verbinden 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. Sie behandeln außerdem die zwei operativen Realitäten, die Entwickler treffen: Verbindungslimits sind durch den Cluster-RAM festgelegt und lassen sich nicht per Client-Flag erhöhen, und der Backup Service sichert Managed Databases nicht, die Wiederherstellung ist also das datenbankeigene PITR plus Ihre eigenen logischen Dumps.

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 die relationalen Engines keine Read Replicas bereitstellen, ist der In-Memory DB Cluster der IONOS CLOUD native Weg, relationale Lesezugriffe zu skalieren. Er ist Redis OSS 7.2-kompatibel und lauscht auf Port 6379, und TLS nutzt eine Let's Encrypt Certificate Authority, sobald Sie die Instanz entsprechend konfigurieren (TLS ist nicht standardmäßig aktiviert, aktivieren Sie es also explizit, wie im redis-py-Beispiel unten mit ssl=True). Ein Cluster hat bis zu 5 Knoten. Die zugrunde liegende Valkey-Engine erlaubt standardmäßig maximal 10.000 Client-Verbindungen (maxclients).

Die Standard-Eviction-Policy ist allkeys-lru, und die Persistenz steht standardmäßig auf None, was die richtige Haltung für einen reinen Cache ist: Behandeln Sie ihn als flüchtig und stellen Sie sicher, dass er jederzeit aus der Quelldatenbank wiederaufgebaut werden kann.

4.1 Connecting with 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 Pattern

Cache-aside is the default read path: check the cache, fall back to the database on a miss, then populate the cache. Set a TTL so stale entries expire even if no write invalidates them.

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 Pattern

Write-through updates the database and the cache in the same operation so reads never serve a stale value after a write. Write the database first, and only update the cache once the commit succeeds.

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 fits TaskBoard in two more places: session storage and caching the task-list query results that would otherwise hammer the single primary on every page load.

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 Produktions-Anwendungscode mit jeder IONOS CLOUD Managed-Database-Engine verbinden, mit erzwungenem TLS und gepoolten Verbindungen, und Daten über den richtigen Mechanismus wiederherstellen. Das Verbindungsmodell ist über alle Engines konsistent: privates LAN, verschlüsselter Transport und ein festes Verbindungslimit, das Sie mit Pooling respektieren, statt es mit einem Server-Flag zu bekämpfen. Der In-Memory DB Cache ist Ihr Read-Scaling-Werkzeug, weil die relationalen Engines keine Read Replicas bereitstellen.

Für TaskBoard konkret: PostgreSQL hält die Tasks, Redis cached Lesezugriffe und Sessions, und die Wiederherstellung ist Datenbank-PITR plus Ihre eigenen geplanten Dumps. Bauen Sie diese Verbindungs-Helfer einmal, mit Pooling und TLS eingebaut, und verwenden Sie sie in jedem Service der Anwendung wieder.

Wichtige Punkte:

• Managed Databases werden über das private LAN mit erzwungenem TLS erreicht, nie über einen öffentlichen Endpunkt
• max_connections ist durch den Cluster-RAM festgelegt und nicht benutzerkonfigurierbar, Pooling ist daher Pflicht
• Die relationalen Engines haben keine Read Replicas; der In-Memory DB Cache ist die IONOS CLOUD native Read-Scaling-Lösung
• PgBouncer im transaction-Modus auf Port 6432 vervielfacht die Clients, die ein festes Limit bedienen kann
• Der Backup Service sichert DBaaS nicht, die Wiederherstellung ist Datenbank-PITR (7 Tage Standard, konfigurierbar 1-365 Tage über die v2 API) plus eigene Dumps

Wichtige Begriffe:

• PITR: Point-in-time Recovery, die Wiederherstellung eines Clusters auf einen ISO-8601-Zeitstempel innerhalb des Aufbewahrungsfensters (7 Tage Standard; 1-365 Tage über die v2 API konfigurierbar) über die REST API
• PgBouncer: Der Managed PostgreSQL Connection Pooler auf Port 6432, unterstützt die Pool-Modi transaction und session
• Cache-aside: Ein Lesemuster, das den Cache prüft, bei einem Miss auf die Datenbank zurückfällt und den Cache dann mit einer TTL befüllt
• Write-through: Ein Schreibmuster, das die Datenbank und den Cache in derselben Operation aktualisiert, um veraltete Lesezugriffe zu vermeiden
• primaryInstanceAddress: The private-LAN address of a database cluster's primary instance that the application connects to

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