1. Kích hoạt tính năng Always On và tạo Availability Group
Kích hoạt tính năng Always On Availability Groups
Trước khi tạo nhóm, bạn phải kích hoạt tính năng này trên cả hai node (Primary và Secondary) trong cụm WSFC đã cấu hình ở Phần 3.
Thực thi câu lệnh T-SQL sau trên cả hai instance SQL Server để bật tính năng Always On:
EXEC sys.sp_configure N'Always On High Availability', N'1';
RECONFIGURE WITH REPLICATION;
Kết quả mong đợi: Không có lỗi, thông báo "Configuration option 'Always On High Availability' changed from a value of 0 to a value of 1".
Tạo Availability Group trên Primary Node
Thực hiện việc tạo Availability Group trên node chính (Primary). Giả sử tên cụm là "AG-SQL-Cluster" và tên Availability Group là "AG-Prod-Sales".
Thực thi câu lệnh sau trên Primary Node:
CREATE AVAILABILITY GROUP [AG-Prod-Sales]
WITH (
CLUSTER_TYPE = 'WSFC',
FAILOVER_MODE = SYNCHRONOUS_COMMIT,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILURE_CONDITION_LEVEL = 2,
HEALTH_CHECK_TIMEOUT = 10000
)
FOR REPLICA WITH NAME 'SQL-Primary'
WITH (
ENDPOINT_URL = 'TCP://sql-primary.example.com:5022',
FAILOVER_MODE = SYNCHRONOUS_COMMIT,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
CONNECTION_MODE = AUTOMATIC
)
JOIN REPLICA WITH NAME 'SQL-Secondary'
WITH (
ENDPOINT_URL = 'TCP://sql-secondary.example.com:5022',
FAILOVER_MODE = SYNCHRONOUS_COMMIT,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
CONNECTION_MODE = AUTOMATIC
)
LISTENER WITH (
IP = ('192.168.1.100', '255.255.255.0'),
PORT = 1433,
NAME = 'Listener-AG-Prod-Sales'
);
Kết quả mong đợi: Thông báo "Command(s) completed successfully". Lưu ý: IP Listener (192.168.1.100) phải thuộc dải subnet của cụm WSFC và chưa được sử dụng.
Chấp nhận Availability Group trên Secondary Node
Sau khi tạo trên Primary, Secondary Node cần chấp nhận tham gia vào nhóm. Việc này đồng bộ cấu hình từ Primary sang Secondary.
Thực thi câu lệnh sau trên Secondary Node:
ALTER AVAILABILITY GROUP [AG-Prod-Sales] JOIN;
Kết quả mong đợi: Thông báo "Command(s) completed successfully". Nếu có lỗi, kiểm tra lại đường dẫn endpoint và quyền truy cập trong firewall.
Verify trạng thái Availability Group
Kiểm tra trạng thái của Availability Group và các replica trên Primary Node để đảm bảo Secondary đã tham gia thành công.
SELECT name, replica_server_name, role_desc, operational_state_desc, synchronization_state_desc
FROM sys.dm_hadr_availability_group_states AS ag
CROSS JOIN sys.dm_hadr_database_replica_states AS dr
WHERE ag.group_id = dr.group_id
AND dr.database_id IN (SELECT database_id FROM sys.databases WHERE name = 'master'); -- Kiểm tra master trước
Kết quả mong đợi: Hai dòng trả về, một dòng có role_desc là 'PRIMARY' và một dòng là 'SECONDARY', cả hai đều có operational_state_desc là 'ONLINE'.
2. Thêm Database vào Availability Group
Chuyển đổi Database sang chế độ Full Recovery
Các database muốn tham gia Availability Group bắt buộc phải ở chế độ Recovery Model là FULL. Bạn cần thực hiện trên cả Primary và Secondary trước khi thêm vào nhóm.
Giả sử database cần thêm là "SalesDB". Thực thi trên Primary Node:
ALTER DATABASE [SalesDB] SET RECOVERY FULL;
Kết quả mong đợi: Không có lỗi. Lưu ý: Nếu database đang trong chế độ SIMPLE, lệnh này sẽ chuyển đổi sang FULL ngay lập tức.
Thực hiện Backup Log cuối cùng
Để đồng bộ hóa dữ liệu từ Primary sang Secondary trước khi tham gia nhóm, bạn cần backup transaction log trên Primary và restore nó trên Secondary.
Trên Primary Node:
BACKUP LOG [SalesDB] TO DISK = '/var/opt/mssql/data/SalesDB_log_backup.trn' WITH INIT;
Kết quả mong đợi: Thông báo backup thành công. File log được lưu tại đường dẫn chỉ định.
Restore Log trên Secondary Node
Copy file backup log sang Secondary Node (sử dụng scp hoặc sao chép trực tiếp) và thực hiện restore với tùy chọn NORECOVERY để giữ database ở trạng thái pending.
Trên Secondary Node (giả sử file đã được copy vào cùng đường dẫn):
RESTORE LOG [SalesDB] FROM DISK = '/var/opt/mssql/data/SalesDB_log_backup.trn' WITH NORECOVERY;
Kết quả mong đợi: Thông báo restore thành công. Database "SalesDB" hiện có trạng thái "Restoring" và chưa thể truy cập.
Thêm Database vào Availability Group
Sau khi đồng bộ log, thêm database vào Availability Group từ Primary Node. Lệnh này sẽ kích hoạt quá trình seeding (sao chép dữ liệu) nếu cần và đưa database vào nhóm.
ALTER AVAILABILITY GROUP [AG-Prod-Sales] ADD DATABASE [SalesDB];
Kết quả mong đợi: Thông báo "Command(s) completed successfully". Database sẽ bắt đầu quá trình seeding tự động nếu chưa đồng bộ hoàn toàn.
Verify trạng thái Database trong AG
Kiểm tra xem database đã tham gia nhóm và trạng thái đồng bộ hóa như thế nào.
SELECT
ag.name AS AG_Name,
db.name AS DB_Name,
dr.synchronization_state_desc,
dr.synchronization_health_desc,
dr.is_synchronized
FROM sys.availability_groups AS ag
JOIN sys.availability_databases_cluster AS adc ON ag.group_id = adc.group_id
JOIN sys.databases AS db ON adc.database_id = db.database_id
JOIN sys.dm_hadr_database_replica_states AS dr ON adc.group_id = dr.group_id AND db.database_id = dr.database_id
WHERE ag.name = 'AG-Prod-Sales';
Kết quả mong đợi: Trạng thái synchronization_state_desc là "SYNCHRONIZED" và is_synchronized là 1 (True).
3. Cấu hình Listener và địa chỉ IP
Kiểm tra Listener đã tạo
Trong bước tạo AG ở phần 1, chúng ta đã định nghĩa Listener. Bây giờ hãy kiểm tra xem Listener đã được đăng ký trong WSFC và có IP đúng chưa.
SELECT name, ip_address, port, endpoint_url
FROM sys.dm_hadr_availability_group_states AS ag
CROSS JOIN sys.dm_hadr_listener_ip_addresses AS l
CROSS JOIN sys.dm_hadr_listeners AS ll
WHERE ag.group_id = ll.group_id;
Kết quả mong đợi: Trả về thông tin Listener "Listener-AG-Prod-Sales" với IP 192.168.1.100 và cổng 1433.
Cấu hình Listener trong WSFC (Tùy chọn nhưng khuyến nghị)
Trên Linux WSFC, Listener thường được quản lý tự động bởi SQL Server. Tuy nhiên, nếu cần kiểm tra tài nguyên IP trong cụm, sử dụng lệnh `crm` hoặc `pcs`.
Kiểm tra tài nguyên IP trong cụm:
pcs resource show
Kết quả mong đợi: Bạn sẽ thấy một tài nguyên có tên tương tự như "Listener-AG-Prod-Sales" hoặc "IP_Address" thuộc về nhóm "AG-Prod-Sales" đang ở trạng thái "Started".
Test kết nối qua Listener
Thử kết nối đến Listener từ một máy khác hoặc từ chính node đó để đảm bảo DNS/Resolver đã trỏ đúng IP của Listener.
sqlcmd -S Listener-AG-Prod-Sales -U sa -P "YourStrongPassword" -Q "SELECT @@SERVERNAME, @@VERSION"
Kết quả mong đợi: Kết nối thành công, trả về tên server là tên của node hiện đang là Primary.
4. Cấu hình chế độ sao chép và ưu tiên Failover
Cấu hình chế độ Synchronous/Asynchronous
Để cân bằng giữa tính nhất quán dữ liệu (Synchronous) và hiệu năng (Asynchronous), bạn có thể điều chỉnh chế độ sao chép cho từng replica.
Chuyển Secondary sang chế độ Asynchronous (cho phép Primary commit ngay mà không chờ Secondary):
ALTER AVAILABILITY GROUP [AG-Prod-Sales]
MODIFY REPLICA WITH NAME 'SQL-Secondary'
WITH (
FAILOVER_MODE = ASYNCHRONOUS_COMMIT,
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
);
Kết quả mong đợi: Thông báo thành công. Secondary sẽ không còn là replica có thể failover tự động (Automatic Failover) mà chỉ là Manual Failover.
Đặt ưu tiên Failover (Failover Priority)
Trong trường hợp có nhiều hơn 2 replica, hoặc muốn ưu tiên node nào trở thành Primary khi failover, bạn cần thiết lập Failover Priority. Giá trị càng cao càng được ưu tiên.
Thiết lập Priority cho Primary là 100 và Secondary là 50:
ALTER AVAILABILITY GROUP [AG-Prod-Sales]
MODIFY REPLICA WITH NAME 'SQL-Primary'
WITH (FAILOVER_PRIORITY = 100);
ALTER AVAILABILITY GROUP [AG-Prod-Sales]
MODIFY REPLICA WITH NAME 'SQL-Secondary'
WITH (FAILOVER_PRIORITY = 50);
Kết quả mong đợi: Thông báo thành công. Khi xảy ra sự cố, hệ thống sẽ ưu tiên đưa node có priority cao hơn lên làm Primary.
Verify cấu hình Failover
Kiểm tra lại các tham số cấu hình vừa thay đổi:
SELECT
name,
replica_server_name,
failover_mode_desc,
availability_mode_desc,
failover_priority
FROM sys.availability_replicas
WHERE group_id = (SELECT group_id FROM sys.availability_groups WHERE name = 'AG-Prod-Sales');
Kết quả mong đợi: Bảng trả về hiển thị đúng chế độ (ASYNCHRONOUS_COMMIT) và độ ưu tiên (100 và 50) tương ứng cho từng replica.
Điều hướng series:
Mục lục: Series: Triển khai Database SQL Server Always On với Ubuntu 24.04
« Phần 3: Cấu hình Cluster Linux (WSFC) cho Always On
Phần 5: Kiểm thử Failover và cân bằng tải cho Always On »