Sao chép cơ sở dữ liệu (Replication) và thiết kế tính sẵn sàng cao
1. Tổng quan
Định nghĩa: Sao chép cơ sở dữ liệu (Replication) là kỹ thuật truyền và tái thực thi một thay đổi dữ liệu logic sang các thể hiện (instance) cơ sở dữ liệu khác để duy trì nhiều bản sao; tính sẵn sàng cao (High Availability) là mục tiêu vận hành nhằm tiếp tục cung cấp dịch vụ trong giới hạn thời gian và mức mất dữ liệu đã thỏa thuận ngay cả khi xảy ra sự cố.
Khi một dịch vụ trực tuyến phụ thuộc vào một cơ sở dữ liệu duy nhất, hỏng máy chủ, hư hỏng lưu trữ, đứt mạng, lỗi thao tác của người vận hành hay quá tải đều trực tiếp dẫn đến gián đoạn nghiệp vụ. Sao chép là phương tiện đặt dữ liệu ở nhiều vị trí để tách biệt các miền sự cố (failure domain) và phân tán tải đọc, nhưng chỉ cấu hình sao chép thì chưa tự động đạt được tính sẵn sàng cao. Độ trễ sao chép, phát hiện sự cố, bầu chọn leader, chuyển đổi kết nối, tính nhất quán dữ liệu cùng việc kiểm chứng sao lưu và khôi phục phải được thiết kế đồng thời.
Trong bài thi Kỹ sư chuyên nghiệp (Professional Engineer), cần vượt qua kiểu liệt kê "đặt máy chủ chính và máy chủ dự phòng" mà phải định nghĩa trước sự cố nào được phát hiện trong thời gian bao lâu và dữ liệu tại thời điểm nào được bảo toàn đến mức nào. Ví dụ, nếu mục tiêu của sổ cái tài chính là RPO gần bằng 0 thì sao chép đồng bộ có thể phù hợp, nhưng sao chép đồng bộ qua mạng diện rộng sẽ tạo ra cái giá phải trả giữa độ trễ và tính sẵn sàng. Ngược lại, sao chép bất đồng bộ có lợi cho hiệu năng và phân tán địa lý nhưng có thể làm mất các thay đổi cuối cùng tại thời điểm sự cố.
Mục đích của sao chép được chia thành ba nhóm lớn. Thứ nhất là bảo đảm tính sẵn sàng bằng cách chuyển sang thể hiện thay thế khi có sự cố. Thứ hai là bảo đảm khả năng mở rộng bằng cách tách tải nghiệp vụ sang bản sao chỉ đọc hoặc bản sao phân tích. Thứ ba là bảo đảm khả năng phục hồi và khai thác bằng cách duy trì bản sao ở vùng (region) khác để phòng thảm họa và hỗ trợ sao lưu, kiểm toán, khai thác dữ liệu. Dù dùng cùng một công nghệ, nếu mục tiêu khác nhau thì topology và chính sách nhất quán cũng khác nhau.
1.1 Bối cảnh ra đời và sự cần thiết
Mở rộng theo chiều dọc bằng cách tăng CPU và bộ nhớ cho cơ sở dữ liệu là cách ứng phó ban đầu nhanh, nhưng có giới hạn về trần phần cứng và điểm lỗi đơn (single point of failure). Với dịch vụ có nhiều yêu cầu đọc, việc giữ một chủ thể ghi duy nhất trong khi gửi truy vấn đến nhiều bản sao có thể hiệu quả về chi phí. Tuy nhiên, khi ứng dụng cần đọc ngay dữ liệu vừa lưu, cần có đường dẫn bảo đảm tính nhất quán khi đọc.
Tính sẵn sàng của dịch vụ không chỉ được đánh giá bằng việc tiến trình cơ sở dữ liệu còn sống hay không. Nó bao gồm cả việc ứng dụng có kết nối đúng leader không, giao dịch có bị thực thi trùng không, DNS, connection pool, bộ cân bằng tải có nhận biết việc chuyển đổi không, và hệ thống giám sát cùng chế độ trực (on-call) có hoàn tất được khôi phục không. Do đó, sao chép vừa là công nghệ của tầng dữ liệu, vừa là vấn đề của kiến trúc vận hành và quy trình tổ chức.
1.2 Mục tiêu cốt lõi và chỉ số đánh giá
- RPO (Recovery Point Objective): phạm vi thời điểm mất dữ liệu được chấp nhận khi có sự cố. Nếu độ trễ sao chép bất đồng bộ là 5 giây, điều đó có nghĩa trong trường hợp xấu nhất có thể mất các thay đổi của 5 giây gần nhất, chứ không phải lúc nào cũng mất 5 giây.
- RTO (Recovery Time Objective): thời gian cho phép từ khi nhận biết sự cố đến khi dịch vụ trở lại bình thường. Ngay cả khi dùng chuyển đổi tự động, vẫn phải đo bao gồm cả thời gian thử kết nối lại và vô hiệu hóa cache.
- Độ trễ sao chép (Replication Lag): thời gian hoặc lượng thay đổi chưa xử lý cho đến khi thay đổi ở nguồn được phản ánh vào bản sao. Cần làm rõ đang đo theo thời gian hay theo vị trí log.
- Tính sẵn sàng: tỷ lệ cung cấp dịch vụ, bao gồm cả gián đoạn có kế hoạch và không có kế hoạch. Miền sự cố và tỷ lệ chuyển đổi thành công thực tế quan trọng hơn số lượng bản sao.
- Tính nhất quán: mức độ mà việc đọc và ghi trên một dữ liệu logic không vi phạm quy tắc nghiệp vụ. Không phải màn hình nào cũng cần nhất quán mạnh, vì vậy cần phân rã thành chính sách theo từng nghiệp vụ.
2. Nguyên lý và các thành phần của sao chép
2.1 Luồng logic
Sao chép thông thường có luồng như sau: cơ sở dữ liệu nguồn ghi lại sự kiện thay đổi, tầng truyền sao chép chuyển sự kiện đó đến bản sao, và tiến trình áp dụng của bản sao kiểm tra thứ tự và tính toàn vẹn rồi phản ánh vào dữ liệu. Tùy cách hiện thực, sự kiện thay đổi được biểu diễn dưới dạng log giao dịch, bản ghi thu thập dữ liệu thay đổi (CDC), thay đổi hàng logic, sự kiện tài liệu, v.v.
flowchart LR
A[Ứng dụng] --> B[DB leader/nguồn]
B --> C[Log commit·WAL·sự kiện thay đổi]
C --> D[Truyền·hàng đợi·mạng]
D --> E[Bộ nhận sao chép]
E --> F[Kiểm tra thứ tự·toàn vẹn]
F --> G[DB follower/bản sao]
G --> H[Dịch vụ đọc·phân tích·sao lưu]
F --> I[Giám sát độ trễ·lỗi·vị trí áp dụng]
I --> J[Cảnh báo·tự động hóa·phán đoán của người vận hành]
Leader là điểm chuẩn quyết định thứ tự ghi. Khi một giao dịch thay đổi nhiều bảng, bản sao không được phản ánh từng hàng theo thứ tự tùy ý mà phải bảo toàn ranh giới giao dịch và thứ tự commit. Đặc tính này tạo nên sự khác biệt giữa sao chép và việc sao chép tệp đơn thuần.
Log commit là nền tảng cho cả khôi phục sự cố lẫn sao chép. Ý nghĩa đồng bộ hay bất đồng bộ được xác định bởi việc bản sao phải nhận log đến vị trí nào trước khi leader trả về phản hồi commit. Nếu thời gian lưu giữ log ngắn, khi bản sao tạm dừng sẽ không thể tái đồng bộ và có thể phải chuyển sang sao chép toàn bộ, vì vậy đĩa và chính sách lưu giữ cũng phải được đưa vào kế hoạch dung lượng.
Bộ nhận sao chép đọc sự kiện từ mạng, còn bộ áp dụng phản ánh chúng vào tệp dữ liệu hoặc storage engine thực tế. Tách vị trí nhận và vị trí áp dụng giúp phân biệt tình huống mạng bình thường nhưng việc áp dụng chậm do CPU, khóa hay I/O đĩa. Người vận hành không được chỉ nhìn trạng thái "đã kết nối" rồi cho là bình thường.
2.2 Các loại topology sao chép
Cấu trúc phổ biến nhất là primary-replica, gồm một leader duy nhất và một hoặc nhiều follower. Xung đột ghi đơn giản và dễ thiết kế thủ tục bầu chọn leader, nhưng mở rộng ghi và chuyển đổi khi leader gặp sự cố trở thành thách thức cốt lõi. Khi dùng follower làm bản chỉ đọc, cần kiểm soát định tuyến lưu lượng có tính đến độ trễ sao chép.
Cấu trúc nhiều leader cho phép nhiều node nhận ghi, có lợi cho việc tiếp nhận ghi theo khu vực và rút ngắn độ trễ. Tuy nhiên, khi cùng một khóa bị thay đổi ở các leader khác nhau sẽ phát sinh xung đột, vì vậy phải nêu rõ thiết kế khóa tránh xung đột, quy tắc giải quyết xung đột và trải nghiệm người dùng của nhất quán cuối cùng (eventual consistency). Nếu chỉ nhìn vào ưu điểm "có thể ghi ở nhiều nơi" mà áp dụng, vấn đề sẽ lớn đối với dữ liệu có chi phí xung đột cao như tồn kho, số dư.
Sao chép dạng chuỗi hoặc phân cấp là cách leader không gửi trực tiếp đến nhiều bản sao mà bản sao trung gian chuyển tiếp xuống bản sao cấp dưới. Cách này giảm được đường truyền liên vùng hoặc số kết nối, nhưng node trung gian trở thành nút thắt hoặc điểm lỗi bổ sung, nên khi chuyển đổi phải xác nhận phả hệ và vị trí log.
| Loại | Cách ghi | Ưu điểm | Rủi ro chính | Tình huống phù hợp |
|---|---|---|---|---|
| Một leader - follower | Tập trung vào leader | Ít xung đột, mô hình vận hành đơn giản | Sự cố leader, độ trễ sao chép | OLTP thông thường, mở rộng đọc |
| Sao chép đồng bộ nhiều bản | Xác nhận đa số trước commit | RPO thấp, bảo vệ mạnh | Tăng độ trễ, hạn chế ghi khi đứt mạng | Nghiệp vụ cốt lõi có chi phí mất dữ liệu cao |
| Sao chép bất đồng bộ | Chuyển sau khi leader commit | Độ trễ ghi thấp, phân tán diện rộng | Mất log chưa chuyển khi sự cố | Phân tích, khôi phục thảm họa, mở rộng đọc |
| Nhiều leader | Nhiều node ghi | Tiếp nhận ghi theo khu vực, giảm độ trễ khu vực | Xung đột và độ phức tạp giải quyết | Nghiệp vụ phân tán có xung đột hạn chế |
| Sao chép phân cấp | Node trung gian chuyển tiếp | Giảm số kết nối·tải đường truyền | Sự cố trung gian·lan truyền độ trễ | Môi trường có nhiều vùng·chi nhánh |
Các loại trong bảng cần được hiểu như các trục ra quyết định chứ không phải tên sản phẩm. Ví dụ, cấu trúc một leader vẫn có thể có bản sao đồng bộ và vận hành riêng một bản sao bất đồng bộ cho khôi phục thảm họa. Do đó, không nên khẳng định một hệ thống chỉ có một chính sách sao chép, mà hãy tách yêu cầu theo sổ cái cốt lõi, mô hình truy vấn và kho phân tích.
2.3 Sao chép đồng bộ và sao chép bất đồng bộ
Sao chép đồng bộ yêu cầu xác nhận rằng bản sao được chỉ định đã nhận và ghi thay đổi trước khi leader chốt commit. Cách này tăng khả năng tiếp tục với dữ liệu mới nhất từ bản sao đã xác nhận ngay cả khi leader đột ngột mất đi. Tuy nhiên, độ trễ mạng khứ hồi ảnh hưởng đến mọi độ trễ ghi, và nếu không có thiết lập chịu được sự cố bản sao thì vấn đề ở bản sao có thể làm dừng cả việc ghi của leader.
Sao chép bất đồng bộ cho phép leader phản hồi sau khi ghi log của chính nó, rồi mới chuyển thay đổi đến bản sao. Khả năng phản hồi người dùng tốt và phù hợp với sao chép khoảng cách xa, nhưng khi leader gặp sự cố, log chưa được gửi có thể bị mất. Cách nói "bất đồng bộ = không an toàn" là không chính xác. Kết hợp lưu giữ log, nhiều bản sao, khôi phục thảm họa và thiết kế xử lý lại ở ứng dụng có thể đạt được RPO chấp nhận được về mặt nghiệp vụ.
Phương thức bán đồng bộ (semi-synchronous) là giải pháp dung hòa, cho phép commit khi ít nhất một bản sao được chỉ định xác nhận đã nhận log, thay vì tất cả bản sao. Ở đây, mức bảo vệ khác nhau tùy "nhận" là đến bộ nhớ hay đã lưu bền xuống đĩa, và khi đứt mạng thì sau bao nhiêu giây chuyển sang bất đồng bộ. Tài liệu thiết kế phải ghi cụ thể điểm xác nhận và hành vi khi sự cố hơn là chỉ dùng thuật ngữ.
2.4 Đọc từ bản sao và tính nhất quán
Trong cấu trúc ghi vào leader và đọc từ follower, có thể xảy ra hiện tượng người dùng truy vấn lại giá trị vừa thay đổi nhưng lại thấy giá trị cũ. Hiện tượng này gọi là bất nhất quán read-after-write, đặc biệt là vấn đề trong các luồng cần tính tức thời như màn hình hoàn tất thanh toán, trạng thái đơn hàng, thay đổi quyền. Giải pháp bao gồm: buộc đọc từ leader trong một khoảng thời gian, chờ đến khi bản sao bắt kịp vị trí đọc của phiên, hoặc để ứng dụng giữ giá trị ngay sau khi thay đổi.
Gửi mọi truy vấn đến leader thì tính nhất quán đơn giản nhưng mất lợi ích mở rộng đọc. Ngược lại, gửi mọi truy vấn đến bản sao thì stale read tăng lên khi có độ trễ và sự cố. Cần phân loại phạm vi chấp nhận nhất quán mạnh, nhất quán phiên và nhất quán cuối cùng theo từng chức năng nghiệp vụ, rồi phản ánh chính sách định tuyến một cách thống nhất vào mã nguồn, middleware và tầng truy cập dữ liệu.
3. Chuyển đổi sẵn sàng cao và xử lý sự cố
3.1 Cấu trúc chuyển đổi dự phòng (failover)
Với tính sẵn sàng cao, phải vẽ đường thất bại trước đường bình thường. Bộ kiểm tra trạng thái quan sát tiến trình, cổng, phản hồi giao dịch và trạng thái sao chép của leader; bộ điều phối hoặc nhóm đồng thuận phán định sự cố rồi quyết định có nâng cấp bản sao ứng viên hay không. Sau đó, điểm truy cập phải trỏ đến leader mới, connection pool của ứng dụng phải kết nối lại, và leader cũ khi quay lại phải bị cô lập để không nhận ghi nữa.
sequenceDiagram
participant App as Ứng dụng
participant Mon as Giám sát/Điều phối
participant P as Leader hiện tại
participant R as Bản sao ứng viên
participant EP as Endpoint truy cập
App->>P: Ghi giao dịch
Mon->>P: Kiểm tra trạng thái·quorum·vị trí sao chép
P--xMon: Mất heartbeat/phản hồi
Mon->>R: Kiểm chứng log mới nhất·khả năng nâng cấp
R-->>Mon: Báo cáo vị trí áp dụng·timeline
Mon->>P: Cô lập·thử fencing
Mon->>R: Nâng cấp thành leader
Mon->>EP: Cập nhật endpoint leader mới
App->>EP: Thử kết nối lại·quyết định thực thi lại giao dịch
EP->>R: Chuyển các thao tác ghi mới
Phát hiện sự cố nhanh không phải lúc nào cũng tốt. Nếu mạng tạm thời đứt nhưng leader vẫn sống mà lại bị phán đoán nhầm là sự cố, có thể xảy ra split-brain, khi hai node cùng nhận ghi riêng rẽ. Vì vậy, thay vì dựa vào phán đoán của một bộ giám sát duy nhất, cần các phương tiện bảo đảm tính loại trừ lẫn nhau như quorum, lease (hợp đồng thuê), thiết bị fencing, cơ chế cô lập instance của đám mây.
Đối tượng được nâng cấp không đơn giản là máy chủ gần nhất mà phải được chọn trên cơ sở tổng hợp mức mất dữ liệu và khả năng khôi phục. Cần xác nhận vị trí áp dụng sao chép có mới nhất không, log cần thiết có được lưu giữ không, có tương thích với phiên bản schema mà ứng dụng yêu cầu không, và mạng với các vùng khác có bình thường không. Phân biệt tiêu chí nâng cấp tự động và tiêu chí phê duyệt thủ công giúp việc vận hành vẫn kiểm soát được ngay cả trong tình huống khẩn cấp.
3.2 RPO, RTO và thiết kế sao chép
Với nghiệp vụ có RPO gần bằng 0, dữ liệu phải tồn tại ở ít nhất một miền sự cố khác ngay khi commit hoàn tất. Dù vậy, nếu áp dụng sao chép đồng bộ cho mọi vùng, có thể phát sinh độ trễ diện rộng và suy giảm tính sẵn sàng khi đứt kết nối. Thiết kế thực tế là kết hợp sao chép đồng bộ trong cùng một vùng với sao chép bất đồng bộ sang vùng khác, và định nghĩa riêng RPO chấp nhận được khi xảy ra thảm họa.
RTO không giảm chỉ nhờ sao chép dữ liệu. Nó là kết quả tổng hợp của DNS TTL, service discovery, backoff thử lại của connection pool, timeout giao dịch, xử lý lại của cache và consumer thông điệp, cùng thời gian phê duyệt của người vận hành. Ví dụ, dù việc nâng cấp cơ sở dữ liệu kết thúc trong 30 giây, nếu ứng dụng giữ kết nối cũ trong 2 phút thì RTO thực tế là từ 2 phút trở lên.
| Yêu cầu | Lựa chọn thiết kế | Câu hỏi kiểm chứng |
|---|---|---|
| Gần như không mất dữ liệu | Sao chép đồng bộ hoặc bán đồng bộ, nhiều miền sự cố | Điểm commit đã xác nhận nằm ở đâu và việc ghi sẽ ra sao khi đứt kết nối? |
| Chấp nhận mất vài giây | Sao chép bất đồng bộ, lưu giữ log, xử lý lại | Đo độ trễ sao chép tối đa và lượng log mất trong trường hợp xấu nhất như thế nào? |
| Khôi phục trong vài phút | Chuyển đổi tự động, điểm truy cập cố định, chính sách kết nối lại ngắn | Client và connection pool tìm thấy leader mới nhanh đến mức nào? |
| Ứng phó thảm họa khu vực | Sao chép sang vùng khác·sao lưu·runbook khôi phục | Đã diễn tập khôi phục giả định sự cố toàn vùng chưa? |
3.3 Ứng phó theo loại sự cố
Sự cố tiến trình có thể khởi động lại trên cùng máy chủ, nhưng hư hỏng thiết bị lưu trữ đòi hỏi phải cô lập node đó khỏi tập sao chép và tái đồng bộ. Phân vùng mạng (network partition) là khó nhất. Ngay cả khi các node không nhìn thấy nhau, đường ghi có thể khác nhau tùy client kết nối vào phía nào, vì vậy phải dùng quorum và fencing để chỉ còn lại một thẩm quyền ghi duy nhất.
Khi độ trễ sao chép tăng, thay vì loại bỏ bản sao ngay lập tức, hãy phân rã nguyên nhân. Biện pháp khác nhau tùy việc thiếu băng thông mạng, độ trễ ghi đĩa ở bản sao, giao dịch lớn·DDL·tranh chấp khóa, hay chỉ mục và mẫu truy vấn khác biệt. Đặt cơ chế ngắt mạch (circuit breaker) loại bản sao có độ trễ vượt ngưỡng ra khỏi lưu lượng đọc sẽ giảm rủi ro cung cấp kết quả cũ cho người dùng.
Sau khi khôi phục sự cố, không đưa leader cũ trở lại ngay. Phải xác nhận leader cũ đã nhận những log nào trong thời gian bị tách, timeline có khớp với leader mới không, và có qua được kiểm tra toàn vẹn dữ liệu không, rồi mới gắn lại làm bản sao. Nếu bỏ qua thủ tục này, vấn đề hai leader, trong đó leader cũ lại tiếp nhận ghi, có thể tái diễn.
4. Quy trình thiết kế và xây dựng
4.1 Yêu cầu nghiệp vụ và phân loại dữ liệu
Bước đầu tiên không phải là chọn sản phẩm cơ sở dữ liệu mà là phân loại giao dịch nghiệp vụ. Dữ liệu có chi phí mất mát và xử lý trùng lặp cao như đơn hàng, tồn kho, số dư, quyền cần được bảo vệ mạnh và có chính sách chuyển đổi rõ ràng. Dữ liệu chấp nhận một chút độ trễ như gợi ý, tìm kiếm, thống kê thì sao chép bất đồng bộ hoặc pipeline phân tích riêng có thể hiệu quả hơn.
Ghi lại RPO, RTO, nhất quán khi đọc, tính địa phương, thời gian lưu giữ và giới hạn vị trí thông tin cá nhân cho từng đối tượng dữ liệu. Nếu gộp toàn bộ cơ sở dữ liệu vào một chính sách, hiệu năng ghi cốt lõi có thể suy giảm vì các truy vấn không quan trọng, hoặc dữ liệu log thông thường có thể làm loãng mức bảo vệ cần thiết cho sổ cái cốt lõi.
4.2 Thiết kế topology và miền sự cố
Chỉ đặt hai máy chủ trong cùng một rack thì không ngăn được sự cố nguồn điện rack, switch hay lưu trữ. Tối thiểu phải phân tích ranh giới máy chủ, vùng khả dụng (availability zone), vùng (region), tài khoản hoặc dự án như các miền sự cố và quyết định đặt bản sao ở đâu. Vị trí cách xa về vật lý có lợi cho bảo vệ thảm họa nhưng phải cân nhắc đồng thời độ trễ mạng, quy định pháp lý và chi phí.
Số lượng leader và bản sao không phải càng nhiều càng tốt. Khi bản sao tăng, chi phí vận hành cho truyền log, giám sát, vá lỗi, sao lưu, quyền bảo mật và kiểm chứng ứng viên chuyển đổi cũng tăng. Xác định cấu hình tối thiểu dựa trên lượng đọc và mức chịu lỗi của nghiệp vụ, đồng thời tự động hóa thủ tục bổ sung để tăng dung lượng và mở rộng vùng.
4.3 Đồng bộ ban đầu và tái đồng bộ
Bản sao mới có thể được khởi tạo bằng cách tạo snapshot tại một thời điểm chuẩn rồi áp dụng tuần tự các log sau thời điểm đó. Để không gây tải cho leader trong quá trình khởi tạo, hãy tận dụng bản sao lưu, snapshot hoặc nguồn sao chép chuyên dụng, và kiểm tra sự khớp nhau về phiên bản cơ sở dữ liệu, mô-đun mở rộng, mã hóa ký tự và thiết lập múi giờ.
Khi bản sao chỉ tạm dừng, có thể bắt kịp chỉ bằng các log đang được lưu giữ. Nếu log đã bị xóa hoặc tệp dữ liệu bị hỏng, phải tạo mới bản sao chuẩn toàn bộ thay vì tái đồng bộ một phần. Nếu dùng node đang tái đồng bộ cho lưu lượng đọc, trạng thái chỉ một số bảng hoặc phân vùng là mới nhất có thể bị lộ ra, vì vậy phải hiển thị rõ trạng thái dịch vụ.
4.4 Thiết kế truy cập, định tuyến và thử lại
Ứng dụng không nên hard-code một IP cụ thể làm leader mà phải dùng điểm truy cập trừu tượng như endpoint logic, proxy, service discovery. Tuy nhiên, ngay cả khi endpoint thay đổi, các kết nối TCP và connection pool đã thiết lập không tự động thay đổi, nên phải thiết lập đồng thời vòng đời kết nối, kiểm tra kết nối nhàn rỗi, thời gian kết nối lại và cache DNS.
Thử lại không phải là vạn năng. Nếu kết nối bị đứt trước khi nhận phản hồi commit, giao dịch có thể đã thực sự được phản ánh, nên thực thi lại vô điều kiện sẽ gây trùng đơn hàng, thanh toán. Hãy dùng định danh yêu cầu và khóa lũy đẳng (idempotency key), đồng thời phân biệt lỗi có thể thử lại, lỗi phải xác nhận rồi mới thử lại và lỗi cấm thử lại.
4.5 Khả năng quan sát và cảnh báo
Các chỉ số bắt buộc gồm trạng thái kết nối sao chép, độ trễ truyền, độ trễ áp dụng, dư địa lưu giữ log, dung lượng đĩa của bản sao, số lần bầu chọn leader, tỷ lệ chuyển đổi thành công, tỷ lệ định tuyến đọc và tỷ lệ lỗi kết nối. Quan sát xu hướng và tương quan quan trọng hơn một giá trị đơn lẻ. Ví dụ, dù CPU thấp, nếu độ trễ fsync của đĩa tăng thì độ trễ áp dụng có thể tích lũy.
Cảnh báo không nên chỉ có một ngưỡng độ trễ sao chép mà phải gắn với tác động nghiệp vụ. Mức nghiêm trọng của việc bản sao đơn hàng cốt lõi trễ 10 giây và bản sao phân tích trễ 10 phút có thể khác nhau. Cảnh báo nên bao gồm leader hiện tại, ứng viên, vị trí áp dụng cuối cùng, RPO dự kiến và liên kết runbook phụ trách để người vận hành phán đoán ngay.
4.6 Kiểm thử và runbook vận hành
Trước khi gây sự cố trong trạng thái bình thường, hãy kiểm chứng trong môi trường kiểm thử có thể tái hiện các tình huống: dừng tiến trình leader, đứt mạng, đĩa đầy, độ trễ sao chép, thông tin xác thực sai, sai lệch đồng hồ và đứt kết nối giữa các vùng. Kết quả kiểm thử cần ghi lại thời gian phát hiện, thời gian nâng cấp, tỷ lệ lỗi ứng dụng, lượng dữ liệu mất, các thao tác thủ công và tự động.
Runbook phải nêu rõ trình tự: phán định sự cố, có dừng ghi hay không, fencing, kiểm chứng ứng viên, nâng cấp, chuyển endpoint, kết nối lại ứng dụng, kiểm chứng dữ liệu, gỡ cô lập leader cũ và phân tích sau sự cố. Nếu không xác định điểm con người can thiệp và người có thẩm quyền phê duyệt khi tự động hóa thất bại, các phán đoán khác nhau có thể được thực thi đồng thời trong tình huống khẩn cấp.
5. So sánh các phương thức sao chép và phán đoán thực tiễn
Sao chép và sao lưu có mục đích khác nhau. Bản sao có thể nhanh chóng đi theo cả việc xóa, làm hỏng hay cập nhật sai ở leader, nên không phải là phương tiện bảo vệ khỏi lỗi logic. Sao lưu là con đường khôi phục riêng biệt cho phép quay lại một thời điểm cụ thể; nếu coi sao chép và sao lưu là thay thế cho nhau thì hệ thống sẽ dễ bị tổn thương trước ransomware hay lỗi của người vận hành.
Sao chép đồng bộ giảm mất dữ liệu nhưng phụ thuộc vào chất lượng mạng giữa các miền sự cố. Sao chép bất đồng bộ có lợi cho khả năng phản hồi dịch vụ và mở rộng theo khu vực nhưng phải quản lý độ trễ sao chép như RPO. Nhiều leader có thể cung cấp điểm ghi gần người dùng khu vực nhưng phải phản ánh quy tắc nghiệp vụ về giải quyết xung đột vào mô hình dữ liệu.
| Trục so sánh | Sao chép đồng bộ | Sao chép bất đồng bộ | Nhiều leader |
|---|---|---|---|
| Độ trễ commit | Tăng theo xác nhận sao chép | Tương đối thấp | Có thể thấp theo khu vực |
| Mất dữ liệu | Thấp sau điểm đã xác nhận | Có thể mất phần bị trễ | Có thể có vấn đề xung đột·thứ tự |
| Đứt mạng | Dừng ghi hoặc chuyển chính sách | Có thể tiếp tục ghi | Có thể xung đột sau khi hai bên cùng ghi |
| Độ phức tạp vận hành | Quản lý chuyển đổi·quorum | Quản lý độ trễ·RPO | Quản lý xung đột·điều chỉnh lại |
| Phán đoán tiêu biểu | Chi phí mất dữ liệu lớn hơn chi phí độ trễ | Chi phí độ trễ lớn hơn mất một phần dữ liệu | Quyền tự chủ khu vực và quy tắc xung đột rõ ràng |
Khi dùng bản sao để mở rộng đọc theo chiều ngang, phải loại bỏ giả định rằng dữ liệu là mới nhất. Không xử lý bằng cùng một chính sách định tuyến cho truy vấn chấp nhận giá trị hơi cũ như danh sách sản phẩm và truy vấn cần tính mới nhất như tồn kho ngay trước khi thanh toán. Hãy truyền gợi ý nhất quán khi đọc cho ứng dụng, hoặc tách rõ ràng đường nhất quán mạnh và đường nhất quán cuối cùng.
6. Ví dụ áp dụng trong công nghiệp và nghiệp vụ
6.1 Đơn hàng và tồn kho thương mại điện tử
Việc tạo đơn hàng được xử lý ở leader, còn lịch sử đơn hàng và truy vấn sản phẩm có thể phân tán sang bản sao đọc. Tuy nhiên, trừ tồn kho gắn liền với giao dịch cạnh tranh, nên không được dựa vào giá trị tồn kho cũ của bản sao để ra quyết định trừ cuối cùng. Cách an toàn là thực hiện giao dịch trừ tồn kho bằng cập nhật có điều kiện tại leader, rồi chuyển sự kiện kết quả một cách bất đồng bộ đến hệ thống tìm kiếm, gợi ý.
Nếu yêu cầu đặt hàng bị timeout trong quá trình chuyển đổi dự phòng, client có thể gửi lại yêu cầu. Lưu mã đơn hàng hoặc mã phê duyệt thanh toán làm khóa lũy đẳng và kiểm tra khóa đó đã được xử lý chưa sẽ giúp giảm đơn hàng trùng. Ví dụ này cho thấy cần kết hợp công nghệ sao chép với cơ chế chống trùng lặp ở mức ứng dụng.
6.2 Sổ cái tài chính và truy vấn số dư
Sổ cái và số dư có chi phí mất mát, trùng lặp, sai thứ tự rất lớn, nên cần cân nhắc sao chép đồng bộ hoặc chính sách xác nhận commit tương đương. Đưa cả việc ghi sổ cái lẫn truy vấn trên màn hình khách hàng vào một đường nhất quán mạnh duy nhất thì an toàn, nhưng chi phí có thể tăng khi lượng truy vấn tăng. Vì vậy, đặt chính sách: truy vấn số dư sẽ xác nhận vị trí commit của sổ cái rồi đọc từ bản sao đã áp dụng đến vị trí đó trở lên, hoặc đọc từ leader ngay sau các giao dịch quan trọng.
Sao chép bất đồng bộ sang vùng khôi phục thảm họa giúp phòng sự cố khu vực, nhưng khi chuyển vùng cần có thủ tục nhận diện và xử lý lại các sự kiện sổ cái cuối cùng chưa được chuyển. Sau khi chuyển đổi, phải giới hạn thẩm quyền nghiệp vụ vào một vùng duy nhất để hai vùng không đồng thời ghi sổ cái. Chỉ khi kiểm chứng tổng số dư, số thứ tự sổ cái và giao dịch trùng trong buổi diễn tập khôi phục thì mới xác nhận được tính hiệu quả thực tế.
6.3 Tách biệt phân tích và báo cáo
Chạy truy vấn tổng hợp quy mô lớn trên leader OLTP có thể khiến khóa và I/O cản trở giao dịch nghiệp vụ. Dùng bản sao chuyên cho phân tích hoặc kho phân tích dựa trên thu thập dữ liệu thay đổi (CDC) giúp tách tải truy vấn khỏi DB nghiệp vụ. Khi đó, cần hiển thị trên dashboard rằng dữ liệu phân tích không phải là thời điểm mới nhất, và ghi lại đồng thời thời điểm chốt báo cáo cùng thời điểm chuẩn của sao chép.
Dù bản sao phân tích bị trễ, bản thân dịch vụ đơn hàng không được gián đoạn. Hãy tách pipeline phân tích khỏi đường xử lý yêu cầu nghiệp vụ, và áp dụng chính sách cô lập: khi độ trễ bản sao vượt mức nhất định thì hoãn tác vụ phân tích hoặc chuyển sang snapshot riêng.
7. Chuyên sâu: Góc nhìn thiết kế mới nhất trong môi trường phân tán và đám mây
Trên đám mây, dù cơ sở dữ liệu được quản lý (managed database) cung cấp sao chép và chuyển đổi tự động, kết nối ứng dụng, quyền, lưu giữ sao lưu và chuyển vùng thường vẫn thuộc trách nhiệm của người dùng. Cần xác nhận ý nghĩa thực sự của "tùy chọn sẵn sàng cao" mà dịch vụ cung cấp có phải là sao chép đồng bộ không, phạm vi phát hiện sự cố và nâng cấp tự động đến đâu, và có bao quát cả bảo trì theo kế hoạch lẫn thảm họa vùng không.
Trong môi trường container, không được đối xử với cơ sở dữ liệu như một workload không trạng thái (stateless) đơn thuần. Phải thiết kế đồng thời persistent volume, sự cố node, lập lịch, sao chép lưu trữ, thứ tự tắt và quyền của operator sao lưu. Nếu cố giải quyết việc chuyển đổi cơ sở dữ liệu chỉ bằng chính sách khởi động lại của bộ điều phối (orchestrator), có thể không bảo đảm được phả hệ dữ liệu và quorum.
Thu thập dữ liệu thay đổi (CDC) là cách tận dụng log sao chép như một luồng sự kiện. Có thể chuyển thay đổi của DB vận hành đến kho dữ liệu (data warehouse), chỉ mục tìm kiếm, cache, hệ thống thông điệp, nhưng phải quản lý thứ tự sự kiện, trùng lặp, thay đổi schema và vị trí xử lý lại. Thay vì giả định "chuyển đúng một lần", hãy thiết kế mặc định theo chuyển ít nhất một lần (at-least-once) và tiêu thụ lũy đẳng, đồng thời bảo đảm khả năng phát lại sự kiện sổ cái và các mô hình phái sinh.
Active-active đa vùng có vẻ mạnh trước độ trễ và sự cố khu vực, nhưng chi phí cho thứ tự toàn cục và giải quyết xung đột rất lớn. Cố định người dùng theo khu vực hoặc chia quyền sở hữu dữ liệu theo dải khóa có thể giảm xung đột. Dù vậy, với dữ liệu cần một thẩm quyền duy nhất như tồn kho, số dư, quyền ở quy mô toàn cục, duy trì tầng điều phối riêng hoặc một vùng ghi duy nhất có thể là lựa chọn thực tế.
8. Các điểm cần cân nhắc và hàm ý
8.1 Thứ tự ưu tiên giữa mục tiêu sẵn sàng và tính nhất quán
Vì không thể đồng thời tối đa hóa tính sẵn sàng, tính nhất quán và độ trễ, hãy ghi lại thứ tự ưu tiên theo nghiệp vụ trong tài liệu ra quyết định. Thay vì dùng cụm "không gián đoạn", hãy định nghĩa chức năng nào có thể bị hạn chế trong bao nhiêu giây ở sự cố nào. Kỹ sư chuyên nghiệp phải liên kết chế độ sao chép với trải nghiệm người dùng để giải thích sự đánh đổi.
8.2 Miền sự cố và fencing
Đặt bản sao ở các miền sự cố khác nhau quan trọng hơn là có nhiều bản sao. Đặc biệt, nếu không có fencing chắc chắn cấm leader cũ ghi khi phân vùng mạng, việc hỏng dữ liệu có thể bị tự động hóa. Cũng phải kiểm chứng cả trường hợp bản thân thiết bị fencing thất bại và thủ tục thay thế thủ công.
8.3 Quản lý độ trễ sao chép như SLO
Độ trễ sao chép không chỉ là chỉ số vận hành đơn thuần mà là chỉ số độ tin cậy quyết định độ chính xác khi đọc và RPO. Hãy xác định SLO độ trễ, cảnh báo, tiêu chí loại khỏi lưu lượng đọc và người phụ trách khôi phục cho từng bản sao quan trọng. Không chỉ nhìn giá trị trung bình mà cần xem cả giá trị tối đa, phân vị và thời gian kéo dài của độ trễ.
8.4 Tách biệt sao lưu/khôi phục với sao chép
Thực hiện sao lưu từ bản sao có thể giảm tải cho leader, nhưng nếu lỗi logic đã được sao chép thì bản sao lưu cũng có thể bị nhiễm theo. Hãy vận hành sao lưu ngoại tuyến và bất biến, khôi phục theo thời điểm (point-in-time recovery), tách tài khoản khôi phục và kiểm thử khôi phục định kỳ. Trong kiểm thử khôi phục phải xác nhận đến mức ứng dụng thực sự xử lý được nghiệp vụ.
8.5 Tính lũy đẳng và thử lại ở ứng dụng
Chuyển đổi dự phòng cơ sở dữ liệu tạo ra timeout tại thời điểm ranh giới. Để lặp lại an toàn các yêu cầu không rõ đã commit hay chưa, cần khóa lũy đẳng, kiểm tra trùng lặp nghiệp vụ và xử lý tiêu thụ sự kiện trùng. Cách tiếp cận chỉ tăng số lần thử lại sẽ khuếch đại sự cố, vì vậy phải kết hợp exponential backoff và ngắt mạch.
8.6 Bảo mật và quyền truy cập
Kênh sao chép cần áp dụng mã hóa trên đường truyền và xác thực lẫn nhau, còn tài khoản sao chép được vận hành theo đặc quyền tối thiểu, chỉ có quyền log và schema cần thiết. Nếu bản sao nằm ở vùng khác, cần xác nhận các yêu cầu về chuyển thông tin cá nhân ra nước ngoài, thời gian lưu giữ và kiểm toán truy cập. Khi mở bản sao cho phân tích, hãy áp dụng che giấu dữ liệu (masking) và tách quyền để thông tin nhạy cảm không bị lộ cho nhóm người dùng rộng hơn so với sổ cái.
8.7 Quản lý thay đổi và tương thích phiên bản
Thay đổi schema cần triển khai theo từng giai đoạn, có xét đến thứ tự áp dụng giữa leader và bản sao cũng như tính tương thích giữa ứng dụng cũ và mới. Xóa cột mang tính phá hủy hay tạo chỉ mục lớn có thể làm trầm trọng thêm độ trễ sao chép và khả năng chuyển đổi. Hãy xem xét trước thay đổi trực tuyến, chuyển đổi theo kiểu mở rộng rồi chuyển (expand-then-switch) và đường rollback.
8.8 Năng lực tổ chức, vận hành và tự động hóa
Nâng cấp tự động giảm gánh nặng cho người vận hành nhưng có thể khuếch đại hậu quả của việc phán định sự cố sai. Tự động hóa cần bao gồm điều kiện tiên quyết, bước phê duyệt, nhật ký kiểm toán, công tắc dừng và kiểm chứng sau thực hiện. Tổ chức game day và diễn tập khôi phục định kỳ để nhân sự phát triển, DBA, hạ tầng và bảo mật cùng chia sẻ một kịch bản sự cố và bộ thuật ngữ.
9. Kết luận
Sao chép cơ sở dữ liệu không chỉ là chức năng sao chép dữ liệu ra nhiều nơi mà là một kiến trúc gắn kết thẩm quyền ghi, xác nhận commit, độ trễ sao chép, nhất quán khi đọc, chuyển đổi dự phòng và kiểm chứng khôi phục thành một hệ thống vận hành thống nhất. Không có lựa chọn nào luôn vượt trội giữa đồng bộ và bất đồng bộ, một leader và nhiều leader; cần lựa chọn theo chi phí mất dữ liệu, mức chấp nhận độ trễ, yêu cầu khu vực và khả năng xung đột.
Từ góc độ Kỹ sư chuyên nghiệp, cần định lượng trước RPO, RTO và mức độ tác động nghiệp vụ, rồi đưa ra lộ trình liên kết tách miền sự cố, fencing, chuyển endpoint, thử lại lũy đẳng, sao lưu và khôi phục theo thời điểm, bảo mật và tuân thủ quy định, cho đến huấn luyện vận hành. Đồng thời, tiêu chí thành công không phải là "có bản sao" mà là "khi sự cố xảy ra, cung cấp được dữ liệu nào trong thời gian bao lâu ở trạng thái đã được kiểm chứng".
Tài liệu tham khảo
- PostgreSQL Documentation, “High Availability, Load Balancing, and Replication”: https://www.postgresql.org/docs/current/high-availability.html
- PostgreSQL Documentation, “Streaming Replication”: https://www.postgresql.org/docs/current/warm-standby.html
- MySQL Documentation, “Replication”: https://dev.mysql.com/doc/refman/8.4/en/replication.html
- MongoDB Documentation, “Replica Set Members”: https://www.mongodb.com/docs/manual/core/replica-set-members/
- NIST, “Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1)”: https://csrc.nist.gov/pubs/sp/800/34/r1/final
- Google SRE Book, “Addressing Cascading Failures”: https://sre.google/sre-book/addressing-cascading-failures/
Tóm tắt một câu: Tính sẵn sàng cao dựa trên sao chép cơ sở dữ liệu không chỉ là việc chọn sao chép đồng bộ hay bất đồng bộ, mà là chiến lược phục hồi dịch vụ dữ liệu thiết kế đồng thời RPO, RTO, miền sự cố, fencing, tính nhất quán, thử lại lũy đẳng, sao lưu/khôi phục và huấn luyện vận hành.