한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Sách trắng lag game › L12 Cơ sở dữ liệu

Failover DB Database failover

ID nguyên nhân db-failover · Phụ trách chính Hạ tầng DB (Đội hạ tầng) · Phối hợp Phát triển server (Đội phát triển game)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Trong lúc DB chính chết và chuyển sang DB dự phòng, không ghi được dữ liệu, và phần dữ liệu cuối cùng chưa kịp replicate có thể bị mất.

Vì sao DB chính gặp sự cố, DB dự phòng được nâng lên làm DB chính → Dẫn đến Trong lúc chuyển, không ghi được từ vài giây đến vài phút; nếu replication bất đồng bộ thì dữ liệu chưa replicate có thể mất → Trên màn hình Mọi thao tác lưu thất bại trong chốc lát, vật phẩm và điểm kinh nghiệm bị rollback

Triệu chứng
Nuốt thao tác·rollback, Đứng hình, Mất kết nối, Không vào được·kẹt loading
Yếu tố
Ngưng trệ, Mất gói
Ai gặp phải
Cả server
Khi nào
Thỉnh thoảng bất chợt
Phụ trách
Phụ trách chính Hạ tầng DB (Đội hạ tầng) · Phối hợp Phát triển server (Đội phát triển game)
Việc cần làm (Đội phát triển game)
Thao tác lưu có thể thử lại, cấu hình để nhanh chóng bỏ kết nối đã đứt và kết nối lại tới địa chỉ mới (connection pool, cache DNS), kiểm tra việc kết nối lại khi diễn tập failover.
Việc cần làm (Đội hạ tầng)
Replication đồng bộ hoặc bán đồng bộ (đánh đổi bằng độ trễ ghi), diễn tập failover, giám sát thời gian failover và replication lag.
Con số tham khảo
Failover tự động của DB managed thường mất từ vài chục giây đến 2 phút. Nếu replication bất đồng bộ, các lần lưu gần nhất có thể mất, tương ứng với replication lag (dưới 1 giây đến vài giây).
Trên đồ thị
Rớt kết nối hàng loạt · Số kết nối DB, số lỗi ghi
Chỗ cần xem
Đặt lên cùng một đồ thị bản ghi failover phía DB (RDS: sự kiện RDS-EVENT-0013 bắt đầu failover, RDS-EVENT-0049 failover hoàn tất; DB tự vận hành: log promote) cùng số kết nối DB và số lỗi kết nối của server game. Nếu là replication bất đồng bộ, xem cả replication lag ngay trước sự cố (RDS ReplicaLag, replay_lag trong pg_stat_replication của PostgreSQL)
Đúng nếu
các lần lưu thất bại dồn vào một khoảng, trùng với khoảng giữa lúc failover bắt đầu và hoàn tất. Khoảng thời gian bị quay lại xấp xỉ replication lag ngay trước sự cố. Server game nào vẫn lỗi sau khi failover xong là do vẫn dùng kết nối tạo tới địa chỉ cũ
Loại trừ nếu
mất kết nối vào lúc không có bản ghi failover → mạng hoặc DB quá tải
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Sự cố thực tế
Riot Games 2021: Sự cố 5 giờ ở League of Legends EUW: một DB phụ làm tê liệt toàn bộ server

Nguồn

  1. Failing over a Multi-AZ DB instance for Amazon RDS AWS
    Failover Multi-AZ thường mất 60–120 giây, sau failover phải tạo lại kết nối, khuyến nghị TTL cache DNS của JVM không quá 60 giây
  2. High availability for Amazon Aurora AWS
    Trong lúc sự cố, đọc và ghi đều thất bại, thường phục hồi trong vòng 60 giây (thường gặp là trong 30 giây)
  3. Semisynchronous Replication MySQL
    Với replication bất đồng bộ, khi DB chính chết, transaction đã commit có thể chưa có trên bản sao; bán đồng bộ chờ một bản sao xác nhận đã nhận để giảm rủi ro này, đổi lại độ trễ tăng
  4. Log-Shipping Standby Servers (PostgreSQL Documentation) PostgreSQL
    Log shipping là bất đồng bộ nên khi server chính chết thì mất các transaction chưa kịp gửi, độ trễ streaming replication thường dưới 1 giây
  5. Amazon RDS event categories and event messages AWS
    RDS-EVENT-0013: bắt đầu failover Multi-AZ, RDS-EVENT-0049: failover Multi-AZ hoàn tất
  6. Amazon CloudWatch metrics for Amazon RDS AWS
    ReplicaLag: thời gian (giây) read replica bị tụt lại so với bản gốc
  7. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    replay_lag trong pg_stat_replication: thời gian từ khi server chính ghi WAL đến khi bản sao báo đã áp dụng

Nguyên nhân nên xem cùng

Cùng tầng: L12 Cơ sở dữ liệu

Nguyên nhân ở tầng khác gây cùng triệu chứng (Nuốt thao tác·rollback)

Xem thẻ gốc có hình minh họa và thí nghiệm