Tình huống: migration khoá bảng orders Trung cấp

Migration chỉ một dòng ADD COLUMN, staging chạy 4 ms, vậy mà production sập API ngay sau deploy. Bạn lần lượt chẩn đoán, gỡ hàng đợi lock, chạy lại cho an toàn và review PR migration tiếp theo.

• Hành vi lock trong game đã được dựng lại trên PostgreSQL 17: SELECT bị chặn bởi migration đang chờ, không phải bởi transaction đang giữ lock.
• Chọn sai thì đọc giải thích rồi Chọn lại; điểm chỉ tính lựa chọn đầu tiên.

Tình huống

Deploy 14:05: một câu ALTER TABLE làm sập API

Bạn là backend dev on-call. Bảng orders 80 triệu row, 6 pod API, mỗi pod pool 40 connection. Mỗi lựa chọn hiển thị ngay hậu quả trên các chỉ số.

API lỗi 5xx0 %

p99 API120 ms

Query chờ lock trên orders0

Connection pool bận25 %

Bước 1/4 · API treo ngay sau deploy

14:05 pipeline deploy bản mới. Container chạy npm run migrate && node server.js, migration chỉ có một dòng. Hai phút sau, mọi endpoint đọc orders timeout. CPU database 8%, không có query nặng nào đang chạy.

pool

240/240 connection bận

lỗi app

timeout exceeded when trying to connect

CPU DB

8%

-- migrations/20261024_add_discount_code.sql
ALTER TABLE orders ADD COLUMN discount_code text;
-- staging: 4 ms

Bạn làm gì?

AMở pg_stat_statements, tìm query có mean_exec_time tăng mạnh nhất để tối ưuBChạy pg_stat_activity kèm pg_blocking_pids(pid) để dựng cây ai chặn aiSELECT pid, application_name, state, now() - xact_start, pg_blocking_pids(pid) FROM pg_stat_activity WHERE wait_event_type = 'Lock' OR state = 'idle in transaction'CScale API từ 6 lên 12 pod cho đủ connectionDXem pg_locks WHERE NOT granted để biết có chờ lock không

Muốn hiểu vì sao một DDL chưa chạy được lại chặn cả SELECT, đọc Lock queue.