tài liệu thiết lập hệ quản trị cơ sở dữ liệu sql server

Thiết lập hệ quản trị cơ sở dữ liệu SQL Server
Giải pháp Database Mirroring giúp xây dựng hệ quản trị cơ sở
dữ liệu có độ sẵn sàng cao trong SQL Server khá đơn giản và
phù hợp với các cơ sở dữ liệu loại vừa trở xuống.
Yêu cầu về một hệ quản trị cơ sở dữ liệu có độ sẵn sàng cao ngày
càng trở nên cấp thiết, đôi khi là yếu tố sống cịn với các tổ chức,
cơng ty. Tuy nhiên, để đạt mức độ sẵn sàng cao (gần như luôn hoạt
động) là một điều khơng đơn giản, vì ln có nhiều yếu tố làm ảnh
hưởng đến hoạt động của hệ thống: sự cố phần cứng, hạ tầng
mạng, lỗi hệ điều hành, lỗi phần mềm ứng dụng, virus… Bài viết
giới thiệu về 1 giải pháp giúp đạt độ sẵn sàng cao (HA – High
Availability) trên hệ quản trị cơ sở dữ liệu được dùng phổ biến
hiện nay: SQL Server.
Các giải pháp HA trên SQL Server
Failover cluster
Giải pháp này sử dụng một ổ cứng dùng chung – thường là SAN
để chứa cơ sở dữ liệu. Có nhiều “instance” của SQL Server được
cài đặt, mỗi instance là 1 node, nhưng tại 1 thời điểm chỉ có 1 node
được quyền điều khiển cơ sở dữ liệu. Khi node này gặp trục trặc, 1
node khác sẽ thay thế nó quản lý cơ sở dữ liệu.
Log shipping
Cơ cấu bổ sung 1 cơ sở dữ liệu làm mirror (bản sao). Khi có thay
đổi hoặc cập nhật từ cơ sở dữ liệu chính, file log ghi lại các thay
đổi này sẽ được gửi sang cho instance của máy chủ mirror. Bằng
cách này, người ta duy trì một bản sao cập nhật của cơ sở dữ liệu.
Trong trường hợp xảy ra sự cố, cơ sở dữ liệu bản sao sẽ được
chuyển thành cơ sở dữ liệu chính trong thời gian ngắn.
Replication


Nếu như Failover cluster và Log Shipping là 2 giải pháp đảm bảo

high-availability ở cấp độ cơ sở dữ liệu thì Replication chỉ đảm
bảo high-availability ở cấp độ các đối tượng trong cơ sở dữ liệu
như table, view… Các đối tượng này sẽ được copy sang một
instance thứ 2 của SQL Server để lưu trữ.
Data Mirroring trong SQL Server
Database Mirroring (DM) là giải pháp mới xây dựng cơ sở dữ liệu
có tính sẵn sàng cao trong SQL Server. DM khắc phục các nhược
điểm của các giải pháp trước đó như:
• So với Failover Cluster, DM không yêu cầu phần cứng đặc biệt
như SAN, vì vậy giảm được chi phí khi cấu hình
• So với Log Shipping, DM có thể tự động chuyển sang máy
mirror khi xảy ra lỗi mà không cần người quản trị phải tác động.
Log shipping yêu cầu phải cấu hình thủ cơng bằng T-SQL. Chính
vì vậy, DM được gọi là “hot standby”, khi thời gian gián đoạn
(downtime) có thể tính bằng giây, cịn Log-shipping được gọi là
“warm standby”, vì thời gian gián đoạn có thể tính bằng phút hoặc
hơn.
• So với Replication, DM vượt trội hơn do bảo vệ được tồn bộ cơ
sở dữ liệu, cịn Replication chỉ bảo vệ từng phần trong cơ sở dữ
liệu, ví dụ các table như master.
Tuy nhiên, DM chỉ có trong phiên bản Enterprise/Developer của
SQL Server 2005 SP1/2008.
1. Cơ cấu của DM trong SQL Server
DM trong SQL Server yêu cầu 3 instance: 1 instance chính
(principal role) quản lý cơ sở dữ liệu, 1 instance phụ (mirror) đảm
bảo việc sao lưu cơ sở dữ liệu. 1 instance giám sát (witness) kết nối
với 2 instance chính và phụ để giám sát và đảm bảo tính sẵn sàng
của cơ sở dữ liệu.

Khi có mặt witness: Máy chủ witness kết nối với cả 2 máy chủ
chính và máy chủ mirror. Lúc này toàn bộ hệ thống trở thành 1
quorum mà 2 trong số 3 thành phần có quyền quyết định . Trong
trường hợp máy chủ chính gặp sự cố, máy chủ witness sẽ tự động
chuyển máy chủ mirror thành máy chủ chính. Nếu sau đó, máy chủ
chính hoạt động trở lại, máy chủ chính sẽ đảm nhận vai trị là máy
chủ mirror (2 máy chủ giờ đổi vai trò cho nhau) cho đến khi có sự
can thiệp của nhà quản trị (sơ đồ 1).

Khi khơng có máy chủ witness: Q trình chuyển đổi tự động sẽ
khơng thực hiện được mà cần có tác động của nhà quản trị.
Trong SQL Server có khái niệm “endPoint” có thể hiểu là “điểm
kết nối”, cho phép các instance SQL Server liên lạc với nhau thông
qua giao thức TCP (sơ đồ 2).
Mỗi endpoint được xác định bằng một địa chỉ và cổng tương ứng.
Về mặt lý thuyết, địa chỉ phải là địa chỉ tên miền đầy đủ, nhưng
thực tế có thể dùng một trong 4 cách sau:


-Xác định thơng qua tên server. Ví dụ: TCP://PRINCIPAL:7024.
-Xác định thơng qua domain name. Ví dụ:
TCP://PRINCIPAL.DELTAX.COM:7024.
-Xác định thơng qua Ipv4. Ví dụ: TCP://192.168.1.3:7024.
-Xác định thơng qua Ipv6.
Cần chú ý: Trong trường hợp các Instance SQL Server cùng chạy
trên một máy thì cổng TCP phải khác nhau.
2. Trao đổi thơng tin giữa máy chủ chính và máy chủ phụ

Chế độ tốc độ cao (High-Performance):

Chế độ High-Performance tương ứng với việc tạo bản sao khơng
đồng bộ. Máy chủ chính gửi các bản cập nhật sang máy chủ mirror
và tiếp tục thực hiện các thay đổi khác mà không cần máy chủ
mirror báo đã cập nhật thành công.
Nhờ việc không phải chờ đợi máy chủ mirror cập nhật các thay
đổi, nên máy chủ chính có tốc độ truy xuất nhanh hơn và tránh
được tải không cần thiết.
Quy trình này có thể được minh họa bằng lược đồ sau:
Đối với chế độ tốc độ cao, máy chủ mirror luôn cập nhật chậm hơn
so với máy chủ chính, và có thể xảy ra mất mát dữ liệu trong
trường hợp máy chủ chính gián đoạn hoạt động mà chưa kịp gửi
dữ liệu sang máy chủ mirror. Tuy nhiên, phần cơ sở dữ liệu khác
biệt này tương đối nhỏ và có thể chấp nhận được. Chế độ tốc độ
cao – High performance mode khơng bắt buộc phải có máy chủ
Witness.
Chế độ an toàn cao (High-Safety):
Khác với chế độ tốc độ cao, chế độ an toàn cao sử dụng cơ chế
đồng bộ (Synchronous). Khi ứng dụng hoặc người dùng cập nhật,
nó sẽ được cập nhật gần như đồng thời trên cả máy chủ chính và
máy chủ mirror. Điều này sẽ đảm bảo khi máy chủ chính xảy ra sự
cố, máy chủ mirror sẽ có bản sao đầy đủ và tồn vẹn của cơ sở dữ
liệu, vì vậy đảm bảo an toàn dữ liệu cao.
Chế độ an toàn cao yêu cầu một máy chủ witness để đảm bảo tính
thay thế nóng – hot standby.
3. Cấu hình DM:


Cấu hình DM trên SQL Server gồm 3 bước cơ bản:
- Sao lưu (backup) toàn bộ cơ sở dữ liệu trên máy chủ chính và sau

đó khơi phục (restore) trên máy chủ mirror.
- Tạo các endpoint tương ứng để các máy chủ chính, mirror và
witness làm việc với nhau.
- Tạo một phiên làm việc (Database Mirroring Session)
Việc cấu hình DM có thể thực hiện bằng giao diện của SQL Server
Management Studio (SSMS), hoặc có thể cấu hình bằng T-SQL:
Cấu hình bằng giao diện của SQL Server Management Studio khá
đơn giản, sau khi đã restore dữ liệu thành công trên máy chủ
mirror, chỉ cần nhấn chuột phải vào cơ sở dữ liệu và chọn
“Mirroring”, sau đó thực hiện theo từng bước.
Kết quả thu được sẽ là việc khởi tạo một session của DM.


Việc cấu hình bằng SSMS cho phép loại bỏ gần hết các thao tác
khi thực hiện bằng T-SQL, tuy nhiên nếu muốn bạn vẫn có thể
dùng T-SQL để đạt độ mềm dẻo cao nhất.
Cấu hình trên T-SQL có thể dùng 2 cách để các endpoint xác thực
lẫn nhau: Xác thực bằng login hoặc xác thực bằng certificate. Đoạn
mã T-SQL hoàn thiện để cấu hình DM khá dài nên chúng tơi chỉ
giới thiệu một số bước tiêu biểu.
Cấu hình bằng Login
Giả sử chúng ta dùng tài khoản Windows để đăng nhập vào SQL
Server, trường hợp dùng tài khoản SQL Server cũng thực hiện
hoàn toàn tương tự.
CREATE LOGIN [PRICIPAL-SRVAdministrator]
FROM WINDOWS
GO
Tạo các endpoint:
CREATE ENDPOINT Partner
STATE = STARTED

AS TCP ( LISTENER_PORT = 5022 )
FOR DATABASE_MIRRORING (
AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = SUPPORTED,
ROLE=ALL)
GO
Chú ý là việc tạo endpoint với ROLE=ALL cần thực hiện trên cả
máy chủ principal và mirror, trên máy chủ witness, bạn thay bằng
ROLE=WITNESS.


Cấu hình bằng Certificate:


Thay vì sử dụng tài khoản login để cho các endpoint nhận diện
nhau, có thể dùng giải pháp thay thế là tạo các chứng thực –
certificate.
- Tạo mã hóa master key (bắt buộc để xuất certificate):
create master key encryption by password = ‘abc123!!’;
- Tạo một cerfiticate:
create certificate PRINCIPAL_cert
with subject = ‘PRINCIPAL certificate’,
start_date = ’2007/11/01′,
expiry_date = ’2020/11/01′;

- Tạo endpoint tương ứng với certificate:
Create endpoint endpoint_mirroring state = started
as tcp(listener_port = 7024, listener_ip = all)
for database_mirroring (authentication = certificate
PRINCIPAL_cert, encryption = disabled, role = all);

- Xuất certificate ra một file riêng:
Backup certificate PRINCIPAL_cert to file =
‘c:PRINCIPAL_cert.cer’;
Thực hiện tương tự trên máy chủ mirror và witness, chú ý thay đổi


role = witness khi cần thiết. Sau khi đã tạo các Endpoint và xuất
các certificate trên cả 3 instance, quay trở lại máy chủ principal:
- Tạo một login cho máy chủ mirror:
create login MIRROR_login with PASSWORD = ‘abc123!!’;
GO
- Tạo một user tương ứng với Login đó
create user MIRROR_user from login MIRROR_login;
GO
- Tạo certificate từ file .cer của máy chủ mirror:
Create certificate MIRROR_cert
Authorization MIRROR_user
From file = ‘c:MIRROR_cert.cer’;
GO
- Cấp quyền kết nối đến endpoint cho login của máy chủ mirror:
Grant CONNECT ON Endpoint::endpoint_mirroring to
[MIRROR_login];
GO


Thực hiện công việc tương tự đối với certificate của máy chủ
witness, cũng như trên các máy chủ mirror và witness để 3 máy có
thể nhận diện và xác thực lẫn nhau.
Sau khi đã tạo các endpoint, bạn có thể kiểm tra chúng bằng truy
vấn:

SELECT name, state_desc, role_desc
FROM sys.database_mirroring_endpoint
Công việc cuối cùng là khởi tạo một session cho DM:
- Trên máy chủ principal:
ALTER DATABASE AdventureWorks
SET PARTNER = ‘TCP://mirror-srv.deltax.com:5022′
GO
- Trên máy chủ mirror:
ALTER DATABASE AdventureWorks
SET PARTNER = ‘TCP://pricipal-srv.deltax.com:5022′
GO
- Trên máy chủ principal, thiết lập máy chủ witness:
ALTER DATABASE AdventureWorks
SET WITNESS = ‘TCP://witness-srv.deltax.com:5022′
GO
Sau khi hệ thống đã đi vào hoạt động, có thể giám sát bằng công cụ
Database Mirroring Monitor:


4. Lập trình middleware:
Việc sử dụng DM có thể nói là gần như trong suốt đối với việc kết
nối cơ sở dữ liệu từ phía middleware. Nếu bạn sử dụng thư viện
ADO.NET, chỉ cần sửa đổi ConnectionString để thêm trường
“failover partner” chỉ đến máy chủ mirror, ví dụ:


Data Source=pricipal.database.com;Failover
Partner=mirror.database.com;Initial Catalog=AdventureWorks;
Integrated Security=True;
Ngoài ra, ADO.NET tạo một “connection pool” cho phép lưu đệm

(cache) các connection đã được khởi tạo, nên trong trường hợp xảy
ra sự cố dẫn đến phải chuyển đổi máy chủ, bạn cần chủ động thực
hiện thêm thao tác xóa bộ nhớ cache này.

Lời kết
DM trong SQL Server khá đơn giản, dễ cấu hình, sử dụng và theo
dõi, tuy nhiên khả năng của nó tương đối hạn chế. Nó chỉ phù hợp
với các cơ sở dữ liệu loại vừa trở xuống, còn với các cơ sở dữ liệu
lớn có u cầu nghiêm ngặt về tính liên tục thì cách làm đề xuất ở
trên chưa đáp ứng được mà cần những giải pháp tổng thể cả về hệ
điều hành, hệ thống phần cứng, mạng.