Tại sao nên chọn Logical Replication thay vì Streaming Replication?
Streaming Replication (vật lý) là giải pháp quá quen thuộc để sao chép toàn bộ cluster từ node Primary sang Standby. Tuy nhiên, đời không như là mơ. Trong nhiều dự án thực tế, mình đã gặp những bài toán mà sao chép vật lý tỏ ra quá cồng kềnh hoặc bất khả thi. Chẳng hạn, bạn chỉ cần đẩy 5 bảng dữ liệu quan trọng sang node Reporting để làm báo cáo, hoặc cần đồng bộ dữ liệu giữa hai phiên bản PostgreSQL khác nhau như v12 và v16.
Đây chính là lúc Logical Replication phát huy sức mạnh. Thay vì sao chép từng block dữ liệu thô trên ổ đĩa, nó giải mã các thay đổi (INSERT, UPDATE, DELETE) thành các luồng dữ liệu logic. Cơ chế này cho phép chúng ta chọn lọc chính xác từng bảng, thậm chí là lọc dữ liệu theo hàng (row filter) để tối ưu băng thông.
Mình từng xử lý một ca migrate dữ liệu khách hàng từ Monolith DB nặng 2.5TB sang Microservice mới. Nếu dùng dump/restore truyền thống, hệ thống sẽ phải ngừng hoạt động ít nhất 4-6 tiếng. Nhờ Logical Replication, mình đã rút ngắn thời gian downtime xuống còn chưa đầy 30 giây – chỉ đủ để đội DevOps thay đổi connection string.
Hiểu nhanh về Publication và Subscription
Để vận hành trơn tru, bạn chỉ cần nắm vững hai khái niệm then chốt:
- Publication (Phía nguồn): Đây là nơi bạn định nghĩa danh sách các bảng muốn “phát sóng”. Bạn có thể chọn
FOR ALL TABLEShoặc chỉ định danh sách bảng cụ thể. - Subscription (Phía đích): Đây là bên đăng ký nhận dữ liệu. Một Subscriber có thể kết nối tới nhiều Publisher khác nhau, cực kỳ hữu ích khi bạn muốn gom dữ liệu từ 5-10 database chi nhánh về một kho dữ liệu trung tâm.
Lưu ý: Logical Replication không đồng bộ cấu trúc bảng (Schema/DDL). Trước khi kết nối, hãy đảm bảo bảng ở phía đích đã được tạo sẵn với cấu trúc tương ứng.
Các bước triển khai chi tiết
Bước 1: Cấu hình phía Publisher (Nguồn)
Mở file postgresql.conf và tìm tham số wal_level. Giá trị mặc định thường là replica, bạn cần chuyển nó sang logical để hệ thống ghi nhận đủ thông tin giải mã.
# Cấu hình tối thiểu trong postgresql.conf
wal_level = logical
max_replication_slots = 10
max_wal_senders = 10Đừng quên restart lại PostgreSQL để cấu hình có hiệu lực. Tiếp theo, hãy tạo một user chuyên dụng cho việc đồng bộ:
CREATE ROLE replicator_user WITH REPLICATION LOGIN PASSWORD 'strong_password';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replicator_user;Sau đó, tạo Publication cho các bảng cần thiết, ví dụ bảng orders và customers:
CREATE PUBLICATION my_selective_pub FOR TABLE orders, customers;Bước 2: Thiết lập phía Subscriber (Đích)
Bước đầu tiên là copy khung xương dữ liệu (schema). Cách nhanh nhất là dùng pg_dump với cờ --schema-only để tránh kéo theo dữ liệu rác:
pg_dump -h source_host -U username -s -t orders -t customers source_db | psql -h target_host -U username target_dbCuối cùng, hãy kích hoạt việc nhận dữ liệu bằng lệnh CREATE SUBSCRIPTION:
CREATE SUBSCRIPTION my_selective_sub
CONNECTION 'host=source_host port=5432 user=replicator_user password=strong_password dbname=source_db'
PUBLICATION my_selective_pub;Ngay khi lệnh này thực thi thành công, PostgreSQL sẽ tiến hành “Initial Copy” để đổ toàn bộ dữ liệu hiện có sang đích trước khi chuyển sang chế độ đồng bộ thời gian thực.
Kinh nghiệm thực chiến và các lỗi dễ “ăn hành”
1. Rắc rối với Primary Key
Để đồng bộ các lệnh UPDATE và DELETE, bảng của bạn phải có Primary Key. Nếu không, bạn sẽ gặp lỗi ngay lập tức. Trong trường hợp bất khả kháng không có khóa chính, bạn phải set REPLICA IDENTITY FULL, nhưng hãy cẩn thận vì nó sẽ làm tăng tải CPU đáng kể trên server nguồn.
2. Quên đồng bộ Sequence
Logical Replication không tự cập nhật giá trị của Sequence (các cột auto-increment). Khi thực hiện switchover sang DB mới, nếu bạn không cập nhật MAX(id) cho sequence thủ công, ứng dụng sẽ crash do lỗi trùng lặp khóa chính khi insert bản ghi mới.
3. Áp lực lên ổ đĩa từ Replication Slot
Đây là lỗi gây chết hệ thống nhanh nhất. Nếu Subscriber bị mất kết nối, Publisher sẽ giữ lại toàn bộ file WAL để chờ. Mình từng chứng kiến một server bị treo cứng vì ổ đĩa đầy thêm 200GB chỉ trong 3 tiếng do Subscriber gặp sự cố mạng. Hãy luôn thiết lập cảnh báo (alerting) cho dung lượng đĩa và trạng thái slot.
4. Giám sát độ trễ (Lag)
Để kiểm tra xem dữ liệu có đang bị delay hay không, hãy sử dụng query sau trên node Publisher:
SELECT application_name, client_addr, state,
pg_wal_lsn_diff(sent_lsn, write_lsn) AS write_lag
FROM pg_stat_replication;Lời kết
Logical Replication là công cụ đắc lực nhưng cần sự tỉ mỉ. Nó giúp bạn linh hoạt hóa kiến trúc dữ liệu: từ việc tách microservices đến tổng hợp dữ liệu cho BI/Data Warehouse. Tuy nhiên, đừng quên thiết lập monitoring chặt chẽ cho các Replication Slot để tránh rủi ro tràn ổ đĩa. Hy vọng những chia sẻ từ thực tế này giúp bạn triển khai hệ thống ổn định và hiệu quả hơn.
