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

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

Khóa do thay đổi schema (DDL) khi đang vận hành Schema change lock (DDL / metadata lock)

ID nguyên nhân db-ddl-lock · 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 →

Nếu thêm cột hay index vào bảng trong lúc đang phục vụ, chỉ vì một khóa cần trong chốc lát mà mọi yêu cầu dùng bảng đó có thể phải chờ.

Vì sao Hotfix thêm cột hoặc index vào bảng đang vận hành → Dẫn đến Thay đổi schema chờ transaction dài đã mở trước đó, còn mọi yêu cầu đến sau lại chờ thay đổi schema đó → Trên màn hình Các tính năng dùng bảng đó (túi đồ, hộp thư, v.v.) ngừng phản hồi hoàn toàn rồi timeout

Triệu chứng
Trễ thao tác, Nuốt thao tác·rollback, Không vào được·kẹt loading
Yếu tố
Ngưng trệ
Ai gặp phải
Chỉ một tính năng, Cả server
Khi nào
Thỉnh thoảng bất chợt, Ngay sau đăng nhập hoặc bảo trì
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)
Hotfix có thay đổi schema thì thống nhất lịch với đội hạ tầng DB, triển khai trước code vẫn chạy được khi chưa có cột mới.
Việc cần làm (Đội hạ tầng)
Đặt giới hạn chờ khóa ngắn và thử lại nếu thất bại, chạy khi không có transaction dài, dùng công cụ thay đổi schema online, với bảng lớn thì làm trong giờ bảo trì.
Trên đồ thị
Tăng như bậc thang từ một thời điểm · Số session chờ khóa, độ trễ query trên bảng đó
Chỗ cần xem
MySQL: đếm các session có State là Waiting for table metadata lock trong SHOW PROCESSLIST, dùng sys.schema_table_lock_waits tìm session đang chặn (blocking_pid). PostgreSQL: xem các yêu cầu có granted là false và AccessExclusiveLock trong pg_locks, dùng pg_blocking_pids() tìm session đang chặn
Đúng nếu
từ lúc bắt đầu thay đổi schema, mọi query dùng bảng đó dồn lại vì chờ khóa, và ở đầu hàng là một transaction chưa kết thúc hoặc câu lệnh thay đổi schema
Loại trừ nếu
chờ chỉ dồn vào một số dòng nhất định, các dòng khác của cùng bảng vẫn xử lý tốt → hot row (db-hot-row)
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Khi thay đổi schema, MySQL giữ metadata lock, còn PostgreSQL giữ khóa bảng mạnh nhất trong chốc lát. Bản thân thay đổi chỉ mất một thoáng, nhưng nếu phía trước còn một transaction chưa kết thúc, mọi yêu cầu phía sau đều phải chờ.

Nguồn

  1. Online DDL Performance and Concurrency MySQL
    Cả online DDL cũng cần metadata lock độc quyền trong chốc lát khi kết thúc; nếu có transaction dài thì phải chờ, và yêu cầu khóa đang chờ đó chặn mọi transaction phía sau
  2. Server System Variables MySQL
    lock_wait_timeout: giới hạn chờ metadata lock, giá trị mặc định 31.536.000 giây (1 năm)
  3. ALTER TABLE (PostgreSQL Documentation) PostgreSQL
    ALTER TABLE nếu không ghi rõ sẽ giữ khóa ACCESS EXCLUSIVE, loại mạnh nhất
  4. Client Connection Defaults (PostgreSQL Documentation) PostgreSQL
    lock_timeout: dừng câu lệnh nếu chờ khóa quá thời gian này
  5. General Thread States MySQL
    Waiting for table metadata lock: trạng thái của thread đang chờ metadata lock
  6. The schema_table_lock_waits and x$schema_table_lock_waits Views MySQL
    Session đang chờ metadata lock (waiting_query) và session đang chặn (blocking_pid)
  7. pg_locks (PostgreSQL Documentation) PostgreSQL
    granted là false nghĩa là đang chờ khóa, mode cho biết loại khóa như AccessExclusiveLock
  8. System Information Functions and Operators (PostgreSQL Documentation) PostgreSQL
    pg_blocking_pids(): danh sách session đang chặn không cho session chỉ định lấy được khóa

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 (Trễ thao tác)

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