SQL Server Always On: Hướng dẫn đầy đủ dành cho DBA [2026]

SQL Server Always On là giải pháp toàn diện về tính khả dụng cao và phục hồi sau thảm họa của Microsoft, được giới thiệu cùng với... SQL Server Năm 2012. Công nghệ này thể hiện một bước tiến đáng kể so với các công nghệ trước đây như sao chép cơ sở dữ liệu và vận chuyển nhật ký, đảm bảo truy cập dữ liệu liên tục đồng thời giảm thiểu thời gian ngừng hoạt động và mất dữ liệu.

1.2 Tại sao doanh nghiệp cần các giải pháp luôn hoạt động

Trong nền kinh tế kỹ thuật số hiện nay, việc cơ sở dữ liệu ngừng hoạt động đồng nghĩa với việc mất doanh thu, tổn hại danh tiếng và các vấn đề tuân thủ quy định. Các tổ chức cần các giải pháp có tính khả dụng cao, có thể đảm bảo thời gian hoạt động gần như liên tục đồng thời bảo vệ chống lại nhiều kịch bản lỗi khác nhau.

Các quy trình sao lưu và phục hồi truyền thống không đáp ứng đủ nhu cầu kinh doanh hiện đại. Khi cơ sở dữ liệu quan trọng gặp sự cố, doanh nghiệp không thể dành hàng giờ để phục hồi từ bản sao lưu. Giải pháp Always On cung cấp khả năng chuyển đổi dự phòng tự động, có thể khôi phục dịch vụ chỉ trong vài giây hoặc vài phút thay vì hàng giờ, giảm thiểu đáng kể tác động của sự cố hệ thống.

Ngoài khả năng hoạt động cơ bản, các doanh nghiệp cần giảm tải các tác vụ đọc dữ liệu chuyên sâu khỏi cơ sở dữ liệu sản xuất, thực hiện bảo trì mà không gây gián đoạn hoạt động và bảo vệ chống lại các thảm họa ở cấp độ toàn hệ thống. SQL Server Always On đáp ứng tất cả các yêu cầu này thông qua một kiến trúc thống nhất có khả năng mở rộng từ các triển khai nhỏ đến các hệ thống phân tán toàn cầu.

1.3 Khái niệm chính: RTO, RPO, HA và DR

Mục tiêu thời gian phục hồi (RTO) Xác định thời gian ngừng hoạt động tối đa có thể chấp nhận được sau sự cố — tốc độ mà cơ sở dữ liệu phải hoạt động trở lại.

Mục tiêu điểm khôi phục (RPO) Xác định mức độ mất dữ liệu tối đa có thể chấp nhận được tính bằng thời gian — lượng dữ liệu đã được ghi nhận gần đây mà doanh nghiệp có thể chấp nhận mất.

Tính sẵn sàng cao (HA) Tập trung vào việc giảm thiểu thời gian ngừng hoạt động do các sự cố thường xuyên như trục trặc phần cứng hoặc lỗi phần mềm trong cùng một trung tâm dữ liệu.

Phục hồi thảm họa (DR) Giải quyết các sự kiện thảm khốc ảnh hưởng đến toàn bộ hệ thống, duy trì các bản sao dữ liệu tại các vị trí địa lý riêng biệt. Trong khi HA tập trung vào việc giảm thiểu thời gian ngừng hoạt động, DR tập trung vào việc đảm bảo bảo vệ dữ liệu và tính liên tục của hoạt động kinh doanh trong các sự cố lớn.

SQL Server Always On hỗ trợ cả tính năng HA (High Availability) và DR (Disaster Recovery) trong một kiến trúc thống nhất duy nhất. Chế độ cam kết đồng bộ mang lại RPO = 0 với khả năng tự động chuyển đổi dự phòng cho RTO gần bằng không; chế độ cam kết không đồng bộ chấp nhận khả năng mất dữ liệu để đổi lấy độ trễ thấp hơn giữa các địa điểm ở xa.

1.4 Giải pháp luôn hoạt động

SQL Server Always On cung cấp ba tùy chọn triển khai, mỗi tùy chọn phù hợp với các yêu cầu về tính khả dụng và cơ sở hạ tầng khác nhau. Hướng dẫn này bao gồm cả ba tùy chọn:

Nhóm khả dụng luôn hoạt động (Always On Availability Groups - AG): Khả năng hoạt động liên tục và phục hồi sau sự cố ở cấp độ cơ sở dữ liệu mà không cần lưu trữ chung.
Các phiên bản cụm chuyển đổi dự phòng luôn hoạt động (FCI): Khả năng hoạt động liên tục ở cấp độ từng instance bằng cách sử dụng bộ nhớ dùng chung.
Sự kết hợp giữa AG và FCI: Bảo vệ hai lớp kết hợp khả năng chuyển đổi dự phòng ở cấp độ phiên bản và cấp độ cơ sở dữ liệu để đạt được khả năng phục hồi tối đa.

2. Nhóm khả dụng luôn hoạt động

Nhóm luôn sẵn sàng (AG) Đây là giải pháp đảm bảo tính sẵn sàng cao và phục hồi sau thảm họa ở cấp độ cơ sở dữ liệu, sao chép một tập hợp các cơ sở dữ liệu người dùng thành tối đa tám bản sao thứ cấp thông qua việc sao chép nhật ký giao dịch liên tục.

Các tính năng chính của 2.1

Chuyển đổi dự phòng ở cấp độ cơ sở dữ liệu: các cơ sở dữ liệu riêng lẻ hoặc nhóm cơ sở dữ liệu có thể chuyển đổi dự phòng độc lập với nhau. SQL Server ví dụ;
Tối đa chín bản sao (một bản chính, tám bản phụ) trong phiên bản Enterprise Edition;
Chế độ cam kết đồng bộ để không mất dữ liệu; cam kết không đồng bộ cho các bản sao DR ở xa;
Tự động chuyển đổi dự phòng cho các bản sao đồng bộ khi máy chủ chính không khả dụng;
Các bản sao phụ có thể đọc được để giảm tải khối lượng công việc báo cáo và sao lưu;
Trình lắng nghe nhóm khả dụng cung cấp một điểm cuối kết nối duy nhất tự động định tuyến đến máy chủ chính hiện tại.

2.2 Các bước thực hiện

Chuẩn bị tài khoản dịch vụ Active Directory và cấu hình quyền trên tất cả các máy chủ;
Cài đặt và xác thực Windows Server Failover Clustering trên tất cả các máy chủ tham gia;
cài đặt, dựng lên SQL Server như một phiên bản độc lập trên mỗi nút sử dụng các đường dẫn và cài đặt nhất quán;
kích hoạt tính năng Nhóm khả dụng luôn bật thông qua SQL Server Trình quản lý cấu hình hoặc PowerShell;
Đặt cơ sở dữ liệu ở chế độ phục hồi đầy đủ và thực hiện sao lưu đầy đủ cũng như sao lưu nhật ký;
Tạo nhóm khả dụng, thêm bản sao và cấu hình chế độ khả dụng và chuyển đổi dự phòng;
Tạo bản sao thứ cấp bằng cách sử dụng phương pháp gieo hạt tự động hoặc sao lưu và khôi phục thủ công;
Tạo trình lắng nghe nhóm khả dụng và xác minh kết nối của máy khách.

Để xem hướng dẫn từng bước đầy đủ, hãy xem phần hướng dẫn của chúng tôi. Hướng dẫn đầy đủ về Nhóm Khả dụng Luôn Bật (Always On Availability Groups).

2.3 Tốt nhất cho

Các cơ sở dữ liệu quan trọng đòi hỏi không mất dữ liệu và khả năng tự động chuyển đổi dự phòng;
khối lượng công việc cần các bản sao lưu phụ có thể đọc được để báo cáo hoặc sao lưu dữ liệu;
Triển khai hệ thống trên nhiều địa điểm để phục hồi sau thảm họa;
môi trường không có cơ sở hạ tầng lưu trữ dùng chung hiện có.

2.4 Ưu điểm

Không cần dùng chung bộ nhớ lưu trữ — mỗi bản sao sử dụng bộ nhớ lưu trữ cục bộ độc lập;
Hỗ trợ cả tính năng HA (High Availability) và DR (Disaster Recovery) trong cùng một cấu hình;
Các tài liệu phụ dễ đọc giúp giảm bớt khối lượng công việc chính;
Độ chi tiết ở cấp độ cơ sở dữ liệu cho phép áp dụng các chính sách chuyển đổi dự phòng khác nhau cho từng nhóm cơ sở dữ liệu.

Nhược điểm

Yêu cầu phiên bản Enterprise để có đầy đủ tính năng (phiên bản Standard hỗ trợ Basic AG nhưng có nhiều hạn chế);
Chế độ cam kết đồng bộ làm tăng độ trễ ghi tỷ lệ thuận với thời gian truyền tải khứ hồi qua mạng;
Việc đăng nhập, các tác vụ SQL Agent và máy chủ được liên kết yêu cầu đồng bộ hóa thủ công. SQL Server Năm 2019 trở về trước;
Tất cả các bản sao phải nằm trên các nút của cùng một Cụm máy chủ chuyển đổi dự phòng Windows Server.

Tài liệu tham khảo 2.6

Tài liệu chính thức của Microsoft: Nhóm khả dụng Always On là gì?
Tài liệu chính thức của Microsoft: Hướng dẫn bắt đầu sử dụng Nhóm Khả dụng Luôn Bật

3. Các phiên bản cụm chuyển đổi dự phòng luôn hoạt động

Các phiên bản cụm chuyển đổi dự phòng luôn hoạt động (FCI) Cung cấp tính khả dụng cao ở cấp độ phiên bản bằng cách chạy một hệ thống duy nhất. SQL Server Phiên bản này được phân bổ trên nhiều nút vật lý dùng chung bộ nhớ. Khi nút đang hoạt động gặp sự cố, thì... SQL Server Phiên bản trên nút dự phòng sẽ tự động được khởi động lại, giúp quá trình chuyển đổi diễn ra liền mạch đối với các ứng dụng khách.

Các tính năng chính của 3.1

Chuyển đổi dự phòng cấp độ phiên bản: tất cả các cơ sở dữ liệu trên phiên bản đó sẽ chuyển đổi dự phòng cùng nhau như một đơn vị duy nhất;
Bộ nhớ dùng chung (Mạng lưu trữ (SAN), iSCSI, Storage Spaces Direct hoặc SMB) có thể truy cập được bởi tất cả các nút;
Tên mạng ảo và địa chỉ IP ảo cung cấp điểm kết nối ổn định bất kể nút nào đang hoạt động;
Windows Server Failover Clustering quản lý việc giám sát trạng thái hoạt động của các nút, thiết lập số lượng nút tối thiểu cần thiết và điều phối quá trình chuyển đổi dự phòng;
Hỗ trợ các kiểu cấu hình nút Active/Standby, Active/Active, N+1 và N+M.

3.2 Các bước thực hiện

Cấp phát và gắn bộ nhớ dùng chung cho tất cả các nút trong cụm;
Cài đặt tính năng Failover Clustering và xác thực cấu hình cụm;
Tạo cụm máy chủ chuyển đổi dự phòng Windows Server và cấu hình số lượng người tham gia tối thiểu;
chạy SQL Server Quá trình cài đặt bao gồm việc chọn tùy chọn cụm chuyển đổi dự phòng và chỉ định tên mạng ảo cũng như đường dẫn lưu trữ dùng chung;
thêm các nút bổ sung vào SQL Server Phiên bản cụm chuyển đổi dự phòng;
Xác minh hành vi chuyển đổi dự phòng bằng cách kiểm tra quá trình chuyển đổi dự phòng thủ công giữa các nút.

Để xem hướng dẫn từng bước đầy đủ, hãy xem phần hướng dẫn của chúng tôi. SQL Server Hướng dẫn đầy đủ về Cụm chuyển đổi dự phòng.

3.3 Tốt nhất cho

Môi trường có cơ sở hạ tầng lưu trữ dùng chung hiện có (SAN hoặc iSCSI);
các ứng dụng yêu cầu chuyển đổi dự phòng ở cấp độ phiên bản, trong đó tất cả các cơ sở dữ liệu phải chuyển đổi dự phòng cùng nhau;
các trường hợp mà tính minh bạch của khách hàng là tối quan trọng và không thể chấp nhận bất kỳ thay đổi nào ở phía ứng dụng;
các tổ chức ưu tiên sự đơn giản của mô hình dự phòng một phiên bản duy nhất.

3.4 Ưu điểm

Tự động chuyển đổi dự phòng ở cấp độ phiên bản mà không cần cấu hình lại phía máy khách;
Không phát sinh chi phí sao chép dữ liệu — tất cả các nút đều truy cập cùng một bộ nhớ lưu trữ;
Hành vi chuyển đổi dự phòng có thể dự đoán được cho tất cả các cơ sở dữ liệu cùng một lúc;
Hỗ trợ cấu hình nút linh hoạt (Active/Active, N+1, N+M) để tối ưu hóa việc sử dụng phần cứng.

Nhược điểm

Lưu trữ dùng chung là một điểm yếu tiềm tàng trừ khi chính hệ thống lưu trữ đó có tính dự phòng;
chỉ có một nút hoạt động SQL Server tại một thời điểm — không có tính năng cân bằng tải đọc trên các nút phụ;
Không có tính năng phục hồi sau sự cố tích hợp sẵn nếu không được ghép nối với nhóm khả dụng;
Cơ sở hạ tầng lưu trữ dùng chung làm tăng chi phí và độ phức tạp so với AG.

Tài liệu tham khảo 3.6

Tài liệu chính thức của Microsoft: Các phiên bản cụm chuyển đổi dự phòng luôn hoạt động (SQL Server)

4. Kết hợp Nhóm Khả dụng với các Phiên bản Cụm Chuyển đổi Dự phòng

Dành cho các tổ chức yêu cầu bảo vệ cả ở cấp độ phiên bản và cấp độ cơ sở dữ liệu, SQL Server Hỗ trợ lưu trữ các bản sao nhóm khả dụng trên các phiên bản cụm chuyển đổi dự phòng (FCI). Trong cấu hình này, mỗi nút FCI hoạt động như một bản sao khả dụng duy nhất, do đó việc chuyển đổi dự phòng FCI diễn ra minh bạch đối với nhóm khả dụng trong khi việc chuyển đổi dự phòng AG cung cấp khả năng bảo vệ ở cấp độ cơ sở dữ liệu trên nhiều địa điểm. Sự kết hợp này mang lại phạm vi bảo mật cao nhất về tính khả dụng và khả năng phục hồi thảm họa hiện có. SQL Server.

Các tính năng chính của 4.1

Chuyển đổi dự phòng hai lớp: FCI xử lý các lỗi ở cấp độ nút; AG xử lý các lỗi ở cấp độ trang web hoặc cấp độ bản sao;
Mỗi FCI được tính là một bản sao duy nhất trong nhóm khả dụng, bất kể FCI đó chứa bao nhiêu nút;
Các bản sao được lưu trữ trên FCI vẫn yêu cầu bộ nhớ dùng chung theo các yêu cầu tiêu chuẩn của FCI;
Các bản sao AG được lưu trữ trên FCI chỉ hỗ trợ chuyển đổi dự phòng thủ công — tính năng chuyển đổi dự phòng tự động không khả dụng đối với các bản sao được lưu trữ trên FCI;
Các phiên bản độc lập có thể tham gia cùng một nhóm khả dụng với các bản sao được lưu trữ trên FCI.

4.2 Các bước thực hiện

Triển khai và xác thực từng FCI một cách độc lập theo các quy trình thiết lập FCI tiêu chuẩn;
Đảm bảo tất cả các nút FCI và các nút bản sao độc lập đều thuộc cùng một Cụm chuyển đổi dự phòng Windows Server;
Kích hoạt tính năng Nhóm khả dụng luôn hoạt động (Always On Availability Groups) trên mỗi phiên bản FCI;
Xác minh rằng không có nút WSFC nào lưu trữ hai bản sao của cùng một nhóm khả dụng sau bất kỳ sự cố chuyển đổi dự phòng FCI nào có thể xảy ra;
Tạo nhóm khả dụng, chỉ định các phiên bản FCI làm bản sao và cấu hình chế độ chuyển đổi dự phòng thủ công cho tất cả các bản sao được lưu trữ trên FCI;
Khởi tạo các bản sao thứ cấp và cấu hình trình lắng nghe nhóm khả dụng.

Để biết chi tiết về thiết lập FCI, vui lòng xem phần hướng dẫn của chúng tôi. SQL Server Hướng dẫn đầy đủ về Cụm chuyển đổi dự phòng. Để biết chi tiết về thiết lập AG, hãy xem hướng dẫn đầy đủ về Nhóm khả dụng Always On của chúng tôi.

4.3 Tốt nhất cho

Môi trường hoạt động quan trọng đòi hỏi khả năng bảo vệ chống lại cả lỗi từng nút riêng lẻ và thảm họa cấp độ toàn hệ thống;
các tổ chức hiện đang sử dụng FCI cần bổ sung khả năng phục hồi sau thảm họa giữa các địa điểm;
các ngành công nghiệp được quản lý chặt chẽ, nơi mà các thỏa thuận mức dịch vụ (SLA) về bảo vệ dữ liệu và tính khả dụng tối đa là bắt buộc;
Các triển khai quy mô lớn, nơi các chính sách chuyển đổi dự phòng ở cấp độ phiên bản và cấp độ cơ sở dữ liệu phải cùng tồn tại.

4.4 Ưu điểm

Bảo vệ tối đa: lỗi nút được xử lý bởi FCI, lỗi toàn hệ thống được xử lý bởi AG;
Quá trình chuyển đổi dự phòng FCI diễn ra minh bạch đối với nhóm khả dụng — Nhóm khả dụng không thấy bất kỳ sự thay đổi bản sao nào trong quá trình chuyển đổi dự phòng FCI;
Cấu trúc liên kết linh hoạt: kết hợp các bản sao được lưu trữ trên FCI và các bản sao độc lập trong cùng một nhóm khả dụng.

Nhược điểm

Các bản sao được lưu trữ trên FCI chỉ hỗ trợ chuyển đổi dự phòng AG thủ công — tính năng chuyển đổi dự phòng AG tự động không khả dụng cho các bản sao này;
Yêu cầu lập kế hoạch cẩn thận cho các nút WSFC để ngăn một nút duy nhất lưu trữ hai bản sao của cùng một nhóm khả dụng (AG) sau khi xảy ra sự cố chuyển đổi dự phòng FCI;
Chi phí cơ sở hạ tầng và độ phức tạp vận hành cao hơn so với AG hoặc FCI riêng lẻ;
Mỗi thành phần của FCI vẫn cần có bộ nhớ dùng chung.

Tài liệu tham khảo 4.6

Tài liệu chính thức của Microsoft: Cụm máy chủ chuyển đổi dự phòng và Nhóm khả dụng luôn hoạt động (Always On Availability Groups)SQL Server)
Tài liệu chính thức của Microsoft: Nhóm khả dụng Always On là gì?
Tài liệu chính thức của Microsoft: Hướng dẫn bắt đầu sử dụng Nhóm Khả dụng Luôn Bật
Tài liệu chính thức của Microsoft: Các phiên bản cụm chuyển đổi dự phòng luôn hoạt động (SQL Server)

5. So sánh các giải pháp Always On

5.1 Bảng so sánh tính năng

Tính năng	Nhóm khả dụng	Các phiên bản cụm chuyển đổi dự phòng	AG + FCI kết hợp
Phạm vi chuyển đổi dự phòng	Cấp độ cơ sở dữ liệu	Cấp độ phiên bản	Cả hai
Cần có bộ nhớ dùng chung	Không	Có	Có (đối với thành phần FCI)
Sao chép dữ liệu	Dựa trên nhật ký cho mỗi bản sao	Không có (bộ nhớ dùng chung)	Dựa trên nhật ký giữa các FCI
Chuyển đổi dự phòng tự động	Có (bản sao đồng bộ)	Có	FCI: Có; AG: Không
Phụ lục dễ đọc	Có	Không	Có (thành phần AG)
Khôi phục thảm họa	Built-in	Không tích hợp sẵn	Built-in
Bản sao Max	9 (Doanh nghiệp)	N/A	9 (Doanh nghiệp)
Sự phức tạp của cơ sở hạ tầng	Trung bình	Trung bình	Cao
Chi phí	Thấp hơn (không cần SAN)	Cao hơn (yêu cầu SAN)	Cao nhất

5.2 Chọn giải pháp luôn hoạt động của bạn

Hãy bắt đầu với cơ sở hạ tầng lưu trữ của bạn: nếu bạn chưa có hệ thống lưu trữ dùng chung, Nhóm khả dụng (Availability Groups) là lựa chọn tự nhiên và là con đường tiết kiệm chi phí nhất để đảm bảo cả tính sẵn sàng cao (HA) và khả năng phục hồi thảm họa (DR). Nếu bạn đã vận hành môi trường SAN và cần khả năng chuyển đổi dự phòng ở cấp độ phiên bản, FCI là tùy chọn đơn giản hơn — nhưng hãy lên kế hoạch bổ sung AG sau này nếu khả năng phục hồi thảm họa đa địa điểm là yêu cầu trong tương lai.

Chỉ nên chọn kết hợp AG + FCI khi bạn thực sự cần cả hai lớp bảo vệ và có đủ năng lực vận hành để quản lý sự phức tạp gia tăng. Điều cần nhớ là các bản sao AG được lưu trữ trên FCI không hỗ trợ chuyển đổi dự phòng AG tự động, do đó cấu trúc liên kết này yêu cầu can thiệp thủ công đối với các chuyển đổi dự phòng ở cấp nhóm khả dụng.

Đối với hầu hết các triển khai mới hiện nay, Always On Availability Groups (Always On Availability Groups) là điểm khởi đầu được khuyến nghị: nó bao gồm cả tính sẵn sàng cao (HA) và phục hồi thảm họa (DR), không yêu cầu lưu trữ dùng chung và hỗ trợ các máy chủ phụ có thể đọc được — những khả năng mà FCI đơn thuần không thể đáp ứng.

6. Thực tiễn tốt nhất cho SQL Server Giải pháp luôn sẵn sàng

6.1 Quy hoạch và thiết kế

Xác định các yêu cầu về RTO và RPO trước khi lựa chọn giải pháp Always On — các mục tiêu này sẽ trực tiếp quyết định xem chế độ cam kết đồng bộ hay không đồng bộ là phù hợp, và liệu tính năng chuyển đổi dự phòng tự động có khả thi hay không.
Hãy thiết lập kích thước các bản sao phụ sao cho chúng có thể xử lý toàn bộ khối lượng công việc của bản sao chính trong trường hợp xảy ra sự cố, bao gồm cả các kịch bản tải cao điểm.
Đối với các triển khai AG, hãy đặt các bản sao đồng bộ trong cùng một trung tâm dữ liệu hoặc mạng có độ trễ thấp để giảm thiểu tác động của độ trễ ghi. Chỉ nên sử dụng chế độ không đồng bộ cho các bản sao DR ở vị trí địa lý xa.
Thiết kế cơ chế bỏ phiếu đồng thuận với số phiếu lẻ. Đối với các cụm hai nút, hãy thêm chia sẻ tệp hoặc chứng thực đám mây làm phiếu bầu thứ ba để ngăn ngừa các kịch bản phân tách bộ nhớ (split-brain).
Hãy lập kế hoạch cấu trúc mạng cẩn thận cho việc triển khai đa mạng con. Mỗi mạng con yêu cầu một địa chỉ IP lắng nghe riêng và các máy khách cần có MultiSubnetFailover=True trong chuỗi kết nối của chúng.

6.2 Hướng dẫn thực hiện

Sử dụng nhất quán SQL Server Phiên bản, ấn bản và mức độ cập nhật tích lũy trên tất cả các bản sao. Các mức độ vá lỗi khác nhau có thể gây ra hành vi không mong muốn trong quá trình chuyển đổi dự phòng.
Cấu hình các giao diện mạng chuyên dụng cho lưu lượng tín hiệu nhịp tim của cụm, tách biệt với lưu lượng ứng dụng.
Bật tính năng tự động gieo dữ liệu ban đầu để đồng bộ hóa cơ sở dữ liệu. SQL Server Từ năm 2016 trở đi, tính năng này loại bỏ nhu cầu sao chép thủ công các bản sao lưu sang bản sao thứ cấp trong hầu hết các trường hợp.
Đối với cấu trúc liên kết AG + FCI, sau mỗi lần thay đổi cấu hình nút FCI, hãy xác minh rằng không có nút WSFC nào có thể lưu trữ hai bản sao của cùng một nhóm khả dụng.
Luôn luôn sử dụng SQL Server Sử dụng Management Studio hoặc Transact-SQL để quản lý việc chuyển đổi dự phòng nhóm khả dụng — tuyệt đối không sử dụng Failover Cluster Manager trực tiếp, vì nó không nhận biết được trạng thái đồng bộ hóa nhóm khả dụng và có thể gây ra thời gian ngừng hoạt động kéo dài hoặc mất dữ liệu.

6.3 Giám sát và Bảo trì

Theo dõi trạng thái đồng bộ hóa, hàng đợi gửi và hàng đợi hoàn tác thường xuyên bằng cách sử dụng bảng điều khiển nhóm khả dụng. SQL Server Management Studio hoặc Dynamic Management Views (DMVs). Hàng đợi redo ngày càng tăng trên máy chủ dự phòng cho thấy có sự tắc nghẽn I/O, điều này sẽ làm chậm quá trình khôi phục khi xảy ra lỗi.
Chạy lệnh DBCC CHECKDB trên các bản sao phụ để giảm tải việc kiểm tra tính toàn vẹn dữ liệu cho bản sao chính. Xem thêm thông tin chi tiết tại đây. Hướng dẫn DBCC CHECKDB để biết thêm chi tiết.
Rắc bột SQL Server Áp dụng phương pháp vá lỗi bằng cách nâng cấp cuốn chiếu: vá các bản sao phụ trước, thực hiện chuyển đổi dự phòng thủ công theo kế hoạch sang bản sao phụ đã được vá, sau đó vá bản sao chính trước đó. Điều này giúp giới hạn thời gian ngừng hoạt động chỉ trong thời gian của một lần chuyển đổi dự phòng.
Hãy thường xuyên kiểm tra khả năng chuyển đổi dự phòng trong môi trường phi sản xuất. Chức năng chuyển đổi dự phòng tự động chưa từng được kiểm tra sẽ không phải là chiến lược phục hồi đáng tin cậy.
Cấu hình cảnh báo cho các thay đổi về trạng thái sức khỏe của nhóm khả dụng, chuyển đổi vai trò bản sao và lỗi đồng bộ hóa bằng cách sử dụng SQL Server Một tác nhân hoặc một công cụ giám sát chuyên dụng như SQL Server Performance Monitor.

7. Câu hỏi thường gặp

Q: là gì SQL Server Luôn bật?

A: SQL Server Always On là nền tảng khả năng hoạt động liên tục và phục hồi sau thảm họa của Microsoft, được giới thiệu vào năm 1964. SQL Server Năm 2012. Công nghệ này bao gồm hai công nghệ — Always On Availability Groups và Always On Failover Cluster Instances — cung cấp khả năng chuyển đổi dự phòng tự động, sao lưu dữ liệu và truy cập liên tục vào cơ sở dữ liệu trong trường hợp xảy ra lỗi phần cứng, phần mềm hoặc sự cố tại địa điểm.

Hỏi: Sự khác biệt giữa Always On Availability Groups và Failover Cluster Instances là gì?

A: Nhóm khả dụng (Availability Groups) hoạt động ở cấp độ cơ sở dữ liệu, sao chép dữ liệu sang các bản sao phụ độc lập thông qua sao chép nhật ký (log shipping) và không yêu cầu bộ nhớ dùng chung. Cụm phiên bản chuyển đổi dự phòng (Failover Cluster Instances - FCI) hoạt động ở cấp độ phiên bản, yêu cầu bộ nhớ dùng chung mà tất cả các nút đều có thể truy cập và chuyển đổi dự phòng tất cả các cơ sở dữ liệu cùng nhau như một đơn vị. AG hỗ trợ các bản sao phụ có thể đọc được và phục hồi thảm họa tích hợp; FCI thì không.

Hỏi: Tôi có cần dùng chung bộ nhớ lưu trữ cho Nhóm Khả dụng Luôn Bật (Always On Availability Groups) không?

A: Không. Mỗi bản sao AG duy trì bản sao độc lập của cơ sở dữ liệu trên bộ nhớ cục bộ. Bộ nhớ dùng chung chỉ cần thiết nếu bạn sử dụng Failover Cluster Instances để lưu trữ các bản sao AG.

Hỏi: Tôi có thể sử dụng Always On với...? SQL Server Phiên bản tiêu chuẩn?

A: SQL Server Phiên bản Standard Edition hỗ trợ Nhóm Khả dụng Cơ bản (Basic Availability Groups) bắt đầu từ... SQL Server Phiên bản năm 2016 có những hạn chế đáng kể: một cơ sở dữ liệu cho mỗi nhóm khả dụng (AG), tối đa hai bản sao và không hỗ trợ cơ sở dữ liệu phụ có thể đọc được. FCI có sẵn trong phiên bản Standard mà không có những hạn chế này. Phiên bản Enterprise là cần thiết để có đầy đủ chức năng Always On.

Hỏi: Số lượng bản sao tối đa trong một nhóm khả dụng là bao nhiêu?

A: SQL Server Phiên bản Enterprise Edition hỗ trợ tối đa chín bản sao: một bản sao chính và tám bản sao phụ. Nhóm khả dụng phân tán có thể mở rộng số lượng này lên đến 18 bản sao trên hai nhóm khả dụng riêng biệt.

Hỏi: Các bản sao được lưu trữ trên FCI có thể sử dụng tính năng chuyển đổi dự phòng AG tự động không?

A: Không. Khi bản sao khả dụng được lưu trữ trên một Phiên bản Cụm Chuyển đổi Dự phòng (Failover Cluster Instance), tính năng chuyển đổi dự phòng nhóm khả dụng tự động không được hỗ trợ cho bản sao đó. Tất cả các chuyển đổi dự phòng nhóm khả dụng liên quan đến các bản sao được lưu trữ trên FCI đều yêu cầu sự can thiệp thủ công.

Hỏi: Sự khác biệt giữa chế độ cam kết đồng bộ và không đồng bộ là gì?

A: Chế độ cam kết đồng bộ yêu cầu máy chủ chính phải đợi máy chủ phụ hoàn tất việc ghi nhật ký trước khi cam kết, đảm bảo không mất dữ liệu (RPO = 0) nhưng đổi lại sẽ làm tăng độ trễ ghi. Chế độ cam kết không đồng bộ cho phép máy chủ chính cam kết mà không cần chờ, giảm độ trễ nhưng có nguy cơ mất dữ liệu nếu máy chủ chính gặp sự cố trước khi máy chủ phụ nhận được tất cả các bản ghi nhật ký. Sử dụng chế độ đồng bộ cho các bản sao HA cục bộ và chế độ không đồng bộ cho các bản sao DR ở xa.

Hỏi: Một cái kéo dài bao lâu? SQL Server Chế độ dự phòng Always On?

A: Quá trình chuyển đổi dự phòng tự động cho bản sao AG đồng bộ thường hoàn tất trong vòng chưa đầy 30 giây trong điều kiện bình thường. Quá trình chuyển đổi dự phòng FCI thường mất từ 20 đến 60 giây tùy thuộc vào thời gian khôi phục cơ sở dữ liệu. Thời gian thực tế phụ thuộc vào khối lượng công việc, kích thước cơ sở dữ liệu và cài đặt thời gian chờ kiểm tra trạng thái được cấu hình trong WSFC.

Hỏi: Điều gì xảy ra với các kết nối của máy khách trong quá trình chuyển đổi dự phòng?

A: Các kết nối hiện có sẽ bị ngắt khi quá trình chuyển đổi dự phòng xảy ra. Các ứng dụng sử dụng trình lắng nghe nhóm khả dụng và bao gồm logic thử lại kết nối sẽ tự động kết nối lại với máy chủ chính mới sau khi quá trình chuyển đổi dự phòng hoàn tất. Thêm MultiSubnetFailover=True vào chuỗi kết nối sẽ cải thiện tốc độ kết nối lại trong các triển khai đa mạng con.

Hỏi: Tôi phải nộp đơn như thế nào? SQL Server Vá lỗi với thời gian ngừng hoạt động tối thiểu trong môi trường Always On?

A: Sử dụng phương pháp nâng cấp cuốn chiếu: vá các bản sao phụ trước, sau đó thực hiện chuyển đổi dự phòng thủ công theo kế hoạch sang bản sao phụ đã được vá, và cuối cùng vá bản sao chính trước đó. Điều này giới hạn thời gian ngừng hoạt động chỉ trong thời gian của một lần chuyển đổi dự phòng theo kế hoạch — thường dưới một phút.

Hỏi: Tôi có thể kết hợp Nhóm khả dụng Always On với các phiên bản Cụm chuyển đổi dự phòng không?

A: Có. Bạn có thể lưu trữ các bản sao AG trên các phiên bản FCI để đạt được khả năng bảo vệ chống lỗi ở cả cấp độ phiên bản và cấp độ cơ sở dữ liệu. Mỗi FCI được tính là một bản sao AG duy nhất. Cấu trúc liên kết này yêu cầu lập kế hoạch cẩn thận cho các nút WSFC để đảm bảo không có nút nào lưu trữ hai bản sao của cùng một AG sau bất kỳ sự cố chuyển đổi dự phòng FCI nào có thể xảy ra.

Hỏi: Tôi nên làm gì nếu cơ sở dữ liệu của tôi bị hỏng trong môi trường Always On?

A: Trước tiên, hãy kiểm tra xem lỗi có xảy ra trên tất cả các bản sao hay chỉ trên bản chính. Nếu có bản sao phụ hoạt động bình thường, hãy chuyển đổi sang bản sao đó ngay lập tức. Nếu lỗi xảy ra trên tất cả các bản sao, hãy khôi phục từ bản sao lưu sạch. Chạy DBCC CHECKDB trên các bản sao phụ thường xuyên để phát hiện lỗi sớm. Nếu các bản sao lưu cũng bị ảnh hưởng, hãy sử dụng một công cụ chuyên dụng. SQL Server công cụ phục hồi dữ liệu Có thể thử trích xuất dữ liệu từ các tệp MDF bị hỏng như một biện pháp cuối cùng.

Hỏi: Nhóm khả dụng Always On (Always On Availability Groups) có những ưu điểm gì so với các hệ thống cũ? SQL Server Giải pháp HA?

A: AG thay thế các công nghệ cũ hơn như đăng nhập vận chuyển và nhân rộngSao chép nhật ký (Log shipping) yêu cầu chuyển đổi dự phòng thủ công và không có chuyển đổi vai trò tự động; sao chép dữ liệu được thiết kế để phân phối dữ liệu chứ không phải để đảm bảo tính sẵn sàng cao (HA). AG cung cấp khả năng chuyển đổi dự phòng tự động, không mất dữ liệu với cam kết đồng bộ và máy chủ phụ có thể đọc được — những khả năng mà các công nghệ kia không thể sánh kịp.

8. Phần kết luận

SQL Server Always On cung cấp một nền tảng linh hoạt, cấp doanh nghiệp cho khả năng hoạt động liên tục và phục hồi sau thảm họa. Always On Availability Groups là lựa chọn phù hợp cho hầu hết các triển khai hiện đại: nó loại bỏ nhu cầu về bộ nhớ dùng chung, hỗ trợ các máy chủ phụ có thể đọc được và xử lý cả khả năng hoạt động liên tục cục bộ (local HA) và phục hồi sau thảm họa liên site (cross-site DR) trong một cấu hình duy nhất. Failover Cluster Instances vẫn là một lựa chọn vững chắc khi khả năng chuyển đổi dự phòng ở cấp độ máy chủ và cơ sở hạ tầng lưu trữ dùng chung hiện có là những yêu cầu chính. Kết hợp cả hai công nghệ này mang lại khả năng bảo vệ sâu rộng nhất hiện có — với chi phí đầu tư cơ sở hạ tầng lớn hơn và độ phức tạp trong vận hành cao hơn.

Dù bạn chọn giải pháp nào, nguyên tắc cơ bản vẫn giống nhau: trước tiên hãy xác định các yêu cầu về RTO và RPO, thiết kế cấu trúc mạng dựa trên các mục tiêu đó và kiểm tra khả năng chuyển đổi dự phòng thường xuyên. Một giải pháp Always On được triển khai tốt và đã được kiểm tra kỹ lưỡng sẽ phục hồi một cách có thể dự đoán được khi xảy ra sự cố trong môi trường sản xuất.

Lưu ý

Nguyên Sinh là quản trị viên cơ sở dữ liệu cao cấp (DBA) với hơn 10 năm kinh nghiệm trong SQL Server môi trường và quản lý cơ sở dữ liệu doanh nghiệp. Ông đã giải quyết thành công hàng trăm tình huống khôi phục cơ sở dữ liệu trên khắp các tổ chức dịch vụ tài chính, chăm sóc sức khỏe và sản xuất.

Yuan chuyên về SQL Server Ông có kinh nghiệm thực tế sâu rộng trong việc quản lý cơ sở dữ liệu hàng terabyte, triển khai các Nhóm Luôn Sẵn Sàng (Always On Availability Groups) và phát triển các chiến lược sao lưu và phục hồi tự động cho các hệ thống kinh doanh quan trọng.

Nhờ chuyên môn kỹ thuật và phương pháp thực tế của mình, Yuan tập trung vào việc tạo ra các hướng dẫn toàn diện giúp quản trị viên cơ sở dữ liệu và chuyên gia CNTT giải quyết các vấn đề phức tạp SQL Server thách thức một cách hiệu quả. Anh ấy luôn cập nhật những thông tin mới nhất SQL Server phát hành và công nghệ cơ sở dữ liệu đang phát triển của Microsoft, thường xuyên kiểm tra các tình huống phục hồi để đảm bảo các khuyến nghị của ông phản ánh những phương pháp hay nhất trong thực tế.

Có thắc mắc về SQL Server phục hồi hoặc cần thêm hướng dẫn khắc phục sự cố cơ sở dữ liệu? Yuan hoan nghênh phản hồi và đề xuất để cải thiện các nguồn lực kỹ thuật này.