Typesense im Produktivbetrieb: HA, Backups, Monitoring und Skalierung

Der Typesense Produktivbetrieb stellt andere Anforderungen als ein lokales Dev-Setup. Ausfallsicherheit, reproduzierbare Backups, klares Monitoring und ein definierter Update-Pfad entscheiden darüber, ob Ihre Suche im B2B-Shop unter Last verlässlich antwortet oder bei Problemen unkontrollierbar wird.

Diese Anleitung zeigt die wichtigsten Bausteine für einen produktionsreifen Typesense-Cluster — von High Availability über Snapshots und Monitoring bis hin zu Rolling Updates und Disaster Recovery.

Key Takeaways

  • Ein produktiver Typesense-Cluster beginnt bei drei Nodes
  • Raft sorgt für Quorum-basierten Failover
  • Snapshots müssen zusätzlich Off-Site gesichert werden
  • Monitoring basiert auf /health und /stats.json
  • Zuerst vertikal skalieren, erst später horizontal
  • TLS, scoped API Keys und Firewall-Regeln sind Pflicht
  • Disaster Recovery benötigt definierte RTO- und RPO-Ziele

 

Was unterscheidet ein Produktiv-Setup von einem Dev-Setup?

Ein Dev-Setup optimiert auf Geschwindigkeit und lokale Entwicklung. Ein Produktiv-Setup optimiert auf:

  • Verfügbarkeit
  • Datenintegrität
  • Wiederherstellbarkeit
  • Sicherheit
  • Beobachtbarkeit

In Produktion läuft Typesense typischerweise:

  • als 3-Node-Raft-Cluster
  • hinter einem Load Balancer
  • mit TLS
  • mit Snapshots
  • mit zentralem Monitoring
  • mit Rolling Updates

 

SLA-Anforderungen definieren

Vor dem Go-Live sollten mindestens drei Kennzahlen definiert werden:

Kennzahl Beispiel
Verfügbarkeit 99,9 %
p95-Latenz < 100 ms
Indexierungsverzögerung < 30 Sekunden

Ohne diese Zielwerte bleibt Monitoring bedeutungslos.

 

Datenintegrität durch Raft

Typesense nutzt Raft-Replikation. Schreibvorgänge gelten erst dann als bestätigt, wenn die Mehrheit der Nodes sie bestätigt hat.

Das verhindert Datenverlust bei Node-Ausfällen.

 

Wie richten Sie High Availability mit Raft ein?

High Availability basiert in Typesense auf einem Raft-Cluster mit mindestens drei Nodes.

 

Warum drei Nodes?

Raft benötigt eine Mehrheit.

Nodes Fehlertoleranz
1, kein Ausfallschutz
2. kein stabiles Quorum
3. ein Node darf ausfallen
4. zwei Nodes dürfen ausfallen

Deshalb sind drei Nodes das produktive Minimum.

 

Cluster-Konfiguration

Datei /etc/typesense/nodes:

10.0.1.10:8107:8108
10.0.1.11:8107:8108
10.0.1.12:8107:8108

Format:

peering_address:peering_port:api_port

Beispiel-Start eines Nodes

typesense-server \
--data-dir=/var/lib/typesense \
--api-key=$TYPESENSE_API_KEY \
--api-address=0.0.0.0 \
--api-port=8108 \
--peering-address=10.0.1.10 \
--peering-port=8107 \
--nodes=/etc/typesense/nodes

Cluster-Architektur

 +-------------+
| Client |
+------+------+
|
+------v------+
| Load |
| Balancer |
+--+-------+--+
| |
+-------v--+ +--v-------+ +----------+
| Node A | | Node B | | Node C |
| Leader |<>|Follower |<>|Follower |
+----------+ +----------+ +----------+

Häufiger Fehler: Firewall

In der Praxis wird häufig nur Port 8108 geöffnet.

Raft benötigt jedoch zusätzlich den Peering-Port 8107.

Ohne diesen Port kann kein stabiler Leader gewählt werden.

 

Wie sichern Sie Daten mit Snapshots und Backups?

Typesense erstellt Snapshots des Datenbestands.

Diese reichen alleine jedoch nicht aus.

 

Snapshot-Konfiguration

data-dir = /var/lib/typesense
snapshot-path = /var/backups/typesense
snapshot-interval-seconds = 3600

Warum Off-Site-Backups wichtig sind

Ein Snapshot auf derselben Maschine schützt nicht vor:

  • SSD-Ausfällen
  • Serververlust
  • Ransomware
  • Fehlkonfigurationen

Deshalb sollten Snapshots zusätzlich extern repliziert werden.

 

Beispiel mit rsync

rsync -a --delete \
/var/backups/typesense/ \
backup-host:/srv/backups/typesense-prod/

Empfohlene Backup-Strategie

Zeitraum Empfehlung
stündlich lokale Snapshots
täglich Off-Site-Replikation
14–30 Tage Versionierung
quartalsweise Restore-Test

 

Wie überwachen Sie einen Typesense Cluster?

Typesense liefert zwei zentrale Endpoints:

Endpoint Zweck
/health einfacher Health-Check
/stats.json Performance-Metriken

 

Health-Check

curl -s http://node-a:8108/health

Antwort:

{"ok":true}

Monitoring mit /stats.json

curl -s \
-H "X-TYPESENSE-API-KEY: $TYPESENSE_API_KEY" \
http://node-a:8108/stats.json

Wichtige Metriken

Metrik Bedeutung
latency_ms Suchlatenz
requests_per_second Last
pending_write_batches Schreibstau
delete_latency_ms Löschlatenz

 

Alerting-Regeln

Mindestens folgende Alarme definieren:

  • Node nicht erreichbar
  • p95-Latenz über SLA
  • Snapshot veraltet
  • RAM > 80 %
  • Disk > 80 %
  • Write Queue wächst dauerhaft

 

Welche Logs brauchen Sie für Observability?

Logs sollten zentral gesammelt werden.

 

Empfohlene Log-Felder

Feld Zweck
timestamp zeitliche Zuordnung
node_id Cluster-Debugging
collection betroffene Collection
query_hash Wiederholungen erkennen
duration_ms Performance
result_count Relevanzanalyse

 

Typische Logging-Stacks

  • Loki
  • OpenSearch
  • Elasticsearch
  • Datadog

 

Slow Query Logging

Langsame Suchanfragen sind oft die eigentliche Lastursache.

Besonders problematisch:

  • sehr lange Suchbegriffe
  • viele Facetten
  • große Filterkombinationen

 

Wann skalieren Sie vertikal, wann horizontal?

Typesense ist primär RAM-getrieben.

Deshalb zuerst vertikal skalieren.

 

Vertikale Skalierung

  • mehr RAM
  • mehr CPU
  • schnellere NVMe-SSDs

 

Horizontale Skalierung

Erst später:

  • mehrere Collections
  • Read Replicas
  • mehrere Cluster
  • Domain-Sharding

 

Faustregel

Situation Empfehlung
RAM reicht nicht mehr vertikal
CPU dauerhaft > 70 % vertikal
mehrere hundert GB Index horizontal
stark getrennte Domains horizontal

 

Wie sichern Sie Typesense in Produktion ab?

Sicherheit ist kein optionales Feature.

 

TLS aktivieren

ssl-certificate=/etc/typesense/certs/fullchain.pem
ssl-certificate-key=/etc/typesense/certs/privkey.pem

Scoped API Keys verwenden

Frontend-Clients erhalten niemals den Admin-Key.

Nur:

  • Search-Only-Key
  • Scoped Key

 

Netzwerk absichern

Empfohlen:

  • private VPC
  • Firewall-Regeln
  • IP-Whitelisting
  • Secret Management

 

Wie führen Sie Updates ohne Downtime durch?

Updates erfolgen Node für Node.

 

Rolling-Update-Ablauf

  1. Snapshot erzeugen
  2. Follower stoppen
  3. Update installieren
  4. Node wieder joinen
  5. Synchronisation abwarten
  6. nächsten Follower aktualisieren
  7. Leader zuletzt aktualisieren

 

Wichtig bei Major-Versionen

Vorher:

  • Release Notes lesen
  • Staging testen
  • Snapshot validieren

 

Wie sieht ein Disaster-Recovery-Plan aus?

Ein DR-Plan benötigt zwei Kennzahlen.

Begriff Bedeutung
RTO maximale Wiederherstellungszeit
RPO maximal akzeptierter Datenverlust

 

Beispiel-Restore

systemctl stop typesense

rm -rf /var/lib/typesense/*

tar -xzf \
/backup/typesense-snapshot.tgz \
-C /var/lib/typesense/

systemctl start typesense

Restore regelmäßig testen

Ein ungetestetes Backup ist kein belastbarer Recovery-Plan.

Mindestens quartalsweise:

  • vollständigen Restore testen
  • Dokumentenzahl prüfen
  • Queries validieren

FAQ

Reicht ein 2-Node-Cluster für High Availability?

Nein. Raft benötigt eine Mehrheit. Bei zwei Nodes führt bereits ein Ausfall dazu, dass keine Schreibvorgänge mehr möglich sind.

Wie oft sollte ich Snapshots erstellen?

Typisch sind 15 bis 60 Minuten. Kürzere Intervalle reduzieren Datenverlust, erhöhen aber IO-Last.

Welche Metriken sind am wichtigsten?

Die wichtigsten Metriken sind:

  • p95-Latenz
  • Requests pro Sekunde
  • Pending Write Batches
  • RAM-Auslastung

Kann ich Typesense ohne TLS betreiben?

Nur in vollständig isolierten internen Netzwerken. Sobald Browser oder externe Systeme zugreifen, ist TLS Pflicht.

Wann muss ich horizontal skalieren?

Sobald Collections nicht mehr vollständig in den RAM eines Nodes passen oder CPU-Last dauerhaft hoch bleibt.