Request Mirroring für Shadow Deployments

Einrichtung

Über die UI

Der Toggle sitzt im Route-Wizard in Step 5 — Reliability (zusammen mit Retry und Circuit Breaker).

1. Route erstellen oder bearbeiten
2. In Step 5 Request Mirroring Toggle aktivieren
3. Mirror-Targets hinzufügen:
   • Peer aus Dropdown auswählen
   • Port des Mirror-Services eingeben
4. Bis zu 5 Targets hinzufügen (API lehnt mehr mit routes.mirror_max ab)
5. Speichern

Über die API

# Mirroring aktivieren mit 2 Targets
curl -X PUT https://gatecontrol.example.com/api/v1/routes/1 \
  -H "Authorization: Bearer gc_..." \
  -H "Content-Type: application/json" \
  -d '{
    "mirror_enabled": true,
    "mirror_targets": [
      { "peer_id": 2, "port": 8080 },
      { "peer_id": 3, "port": 9090 }
    ]
  }'

Wichtige Hinweise

• Schreiboperationen werden gespiegelt. POST, PUT, DELETE — alles wird an die Mirror-Targets geschickt. Wenn das Mirror-Target eine Datenbank hat, werden dort echte Schreibvorgänge ausgeführt. Stelle sicher, dass Mirror-Targets für diesen Traffic ausgelegt sind.
• Mirror-Targets müssen aktive, aktivierte Peers sein. Deaktivierte oder gelöschte Peers werden beim Config-Build ignoriert.
• Die Antwort des Mirror-Targets wird komplett verworfen — es gibt kein Logging oder Vergleich der Mirror-Antworten in GateControl.
• Anfragen mit einem Body größer als 10 MB werden ohne Body gespiegelt (nur Header).
• WebSocket-Upgrade-Anfragen werden nicht gespiegelt.
• Mirroring ist nur für HTTP-Routen verfügbar, nicht für L4 (TCP/UDP).
• Bei sehr hohem Traffic kann das Mirror-Target überlastet werden. Die 100-Goroutine-Grenze schützt GateControl/Caddy, aber nicht das Target.

Siehe auch

• concepts/routing.md — Handler-Reihenfolge und Backend-Matrix
• features/request-tracing.md — Request-Trace als Alternative zum Mirror