Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Distinguish high load and unavailability of TiDB

Aberta
  • Algo errado?
#282 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
go
Domínio
backend

Direção de pesquisa

Comece lendo as implementações de health-check e router, concentrando-se no timeout de 2 segundos, nas três verificações com falha e na migração de conexões de uma só vez descritos na issue. Reproduza ou raciocine sobre os cenários de alta carga para duas instâncias TiDB e, em seguida, defina e valide um comportamento que distinga lentidão temporária de indisponibilidade sem violar graceful-wait-before-shutdown.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.
Linguagem predominante
Go
Estrelas
73
Forks
40
Merge médio
14h 18min
PRs com merge (30d)
10

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de pingcap/tiproxy

Todas as issues de pingcap/tiproxy

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.