Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Close connections to a TiDB that the health check has marked down, instead of waiting for TCP to time out

Aperta
  • Qualcosa non va?
#1,239 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, networking

Direzione di ricerca

Start by reading TiProxy's health-check handling and backend/client connection lifecycle, especially where a backend is marked down and where processLock governs socket handling. The issue does not name specific files or tests, so locate those entry points and existing failure tests first. Done means an opt-in behavior closes idle connections when a backend goes down and applies the requested failover-timeout behavior to in-flight connections.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

contribution first-time-contributor type/enhancement

Feature Request

Describe your feature request related problem

When a TiDB instance fails without closing its sockets (node/instance failure, network partition, or a pod killed before TiDB can drain), TiProxy detects it (health check marks the backend down) but does nothing to the client connections that are already on that backend.

Measured on TiProxy v1.3.2 + TiDB v8.5.8 on Kubernetes (2 TiDB, 2 TiProxy), client with pool_pre_ping. Test: the EC2 instance hosting tidb-0 was terminated.

  | Time (from failure) | Event |
  |---|---|
  | 0 s | Node hosting tidb-0 terminated; TiDB logs nothing further (no shutdown, no FIN to TiProxy) |
  | +14 s | `update backend ... cur="down, err: connect status port failed: ... context deadline exceeded"` |
  | +16.3–16.5 s | Short statements sent right after the failure: `backend disconnects ... execute_time=15.45–15.51s cmd=Query`, client gets EOF |
  | +46 s | Long query started 17 s before the failure: `backend disconnects ... execute_time=1m3.2s cmd=Query query="select sleep(?)"`, client gets EOF |
Describe the feature you'd like

When the health check marks a TiDB down, we'd like TiProxy to:

  1. Close idle client connections on that TiDB right away, so the application's next ping fails instantly and its pool reconnects to a healthy TiDB.
  2. After failover-timeout, also close connections that still have a command in flight. This should break the wait on the TiDB side too (close the backend socket or put a deadline on it), so the client gets an error in seconds rather than a minute.
  3. Apply the unhealthy keepalive to the backend socket immediately when the TiDB is marked down, without waiting for processLock, so even connections with a stuck command get the shorter timeouts.
Teachability, Documentation, Adoption, Migration Strategy

Keep it off by default so current behaviour doesn't change. It's most useful for OLTP applications behind connection pools, where each pooled connection to a dead TiDB costs one full TCP timeout.

Lingua principale
Go
Stelle
73
Fork
41
Merge medio
10h 52m
PR unite (30g)
20

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingcap/tiproxy

Tutte le issue di pingcap/tiproxy

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.