Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Distinguish high load and unavailability of TiDB

Offen
  • Stimmt etwas nicht?
#282 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
go
Bereich
backend

Rechercherichtung

Beginne mit dem Lesen der Implementierungen von health-check und router und konzentriere dich dabei auf das im Issue beschriebene 2-Sekunden-Timeout, drei fehlgeschlagene Checks und die gleichzeitige VerbindungsMigration. Reproduziere die Szenarien unter hoher Last für zwei TiDB-Instanzen oder bilde sie gedanklich nach und definiere und validiere anschließend ein Verhalten, das vorübergehende Verlangsamung von Nichtverfügbarkeit unterscheidet, ohne graceful-wait-before-shutdown zu verletzen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Development Task

When the load of TiDB is very high, it may not respond within 2 seconds, and thus TiProxy treats it as down and migrates ALL connections away from it. The migration is typically very fast and may finish most of them before the next health check.

If there are 2 TiDB instances, A and B. The CPU usage of A is 100% and B is 90%. Theoretically, this may happen:

  • TiProxy can not dial A within 2 seconds and treats A as down and B as alive
  • TiProxy wants to migrate all connections from A to B
  • After 3 seconds, the CPU usage of A becomes 90% and B becomes 100%
  • Again, TiProxy thinks A is alive but B is down
  • TiProxy wants to migrate all connections from B to A

This situation is just theoretically possible but I'm not sure if it will happen in the real world:

  • If the CPU usage of A is 100%, is it possible to migrate many connections within 3 seconds?
  • When the CPU usage of B becomes 100%, it's slow to dial B. Will the connection migration be that fast?

Anyway, the strategies of the health check and router are too aggressive:

  • The health check treats the backend as down when it just fails in 2 seconds for 3 times. However, I also want to make the health check fast enough so that the graceful-wait-before-shutdown can be configured shorter.
  • The router tries to migrate all connections all at once. Exactly, 10ms for 10 connections and thus 3s for 3000 connections for each TiProxy. 3000 connections almost mean all the connections on one TiDB. However, I also want to make the migration ASAP because it needs to finish within graceful-wait-before-shutdown.
Vorherrschende Sprache
Go
Sterne
73
Forks
41
Ø Merge
20 Std. 6 Min.
Gemergte PRs (30 T.)
22

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pingcap/tiproxy

Alle Issues in pingcap/tiproxy

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.