Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Distinguish high load and unavailability of TiDB

Đang mở
  • Có gì không ổn?
#282 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
go
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu bằng cách đọc các triển khai của health-check và router, tập trung vào thời gian chờ 2 giây, ba lần kiểm tra thất bại và việc di chuyển tất cả kết nối cùng lúc được mô tả trong issue. Tái hiện hoặc suy luận về các kịch bản tải cao đối với hai instance TiDB, sau đó xác định và xác thực hành vi phân biệt sự chậm tạm thời với tình trạng không khả dụng mà không vi phạm graceful-wait-before-shutdown.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
73
Fork
41
Merge trung bình
12 giờ 38 phút
Pull request đã merge (30 ngày)
21

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingcap/tiproxy

Tất cả issue của pingcap/tiproxy

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.