Hệ quản trị CSDL SQL là một hệ quản trị CSDL quan hệ, đƣợc phát triển bởi tập đoàn Microsoft.
2.4.1.Giải pháp sử dụng Replication cơ sở dữ liệua) Merge replication a) Merge replication
Merge replication đƣợc thực hiện bởi SQL Server Snapshot Agent và Merge Agent. Nếu publication (publication đƣợc định nghĩa trong một hoặc nhiều cơ sở dữ liệu trong Publisher, publication thiết lập các bảng, cột và các bộ lọc) không đƣợc lọc hoặc sử dụng bộ lọc tĩnh, Snapshot Agent tạo ra một ảnh chụp duy nhất. Nếu publication sử dụng bộ lọc tham số, Snapshot Agent tạo ra một ảnh chụp cho mỗi phân mảnh của dữ liệu. Merge Agent áp dụng cho các ảnh chụp ban đầu đến các Subscriber. Khi dữ liệu thay đổi và lƣợc đồ đƣợc sửa đổi ở Publisher thì Subscriber đƣợc theo dõi với các thay đổi đó. Subscriber đồng bộ với Publisher khi kết nối mạng và trao đổi tất cả những thay đổi giữa Publisher và Subcriber kể từ khi đồng bộ hóa xảy ra ở thời điểm gần nhất [19].
Merge replication thƣờng đƣợc sử dụng trong môi trƣờng server-client. Merger replication thích hợp trong bất kỳ tình huống sau:
- Subscriber có thể có nhiều cập nhật cùng một dữ liệu ở các thời điểm khác nhau và sau đó lan truyền những thay đổi đó đến Publisher và đến các Subscriber khác. - Subscriber cần để nhận dữ liệu, làm thay đổi ngoại tuyến, và sau đó đồng bộ các
thay đổi với Publisher và các Subscriber khác.
- Mỗi Subscriber yêu cầu các phân mảnh khác nhau của dữ liệu.
- Xung đột có thể xảy ra, khi đó cần có khả năng phát hiện và giải quyết chúng. - Ứng dụng yêu cầu dữ liệu
22
Hình 8: Giải pháp Merge replication cân bằng tải cho hệ quản trị CSDL SQL
Đây là một loại cấu hình lý tƣởng, kể từ khi Subscriber đƣợc truy vấn/cập nhật suốt cả ngày, trong khi kho cung cấp thông tin có thể đƣợc cập nhật hàng trăm hoặc hàng ngìn lần trƣớc khi một cập nhật đƣợc thông qua Publisher. Một hệ thống nhƣ vậy sẽ giữ cho độ trễ mạng ở mức tối thiểu cũng nhƣ giảm tải mạng cần thiết cho một hệ thống chức năng.
b) Transactional replication
Transactional replication thƣờng bắt đầu với một ảnh chụp của các đối tƣợng và dữ liệu từ publication. Ngay sau khi ảnh chụp ban đầu đƣợc thực hiện, những thay đổi dữ liệu và sửa đổi biểu đồ đƣợc thực hiện tại Publisher sẽ thƣờng xuyên đƣợc phân phối đến Subscriber khi chúng xảy ra (gần thời gian thực). Những thay đổi dữ liệu đƣợc áp dụng cho Subscriber trong cùng một thứ tự và trong phạm vi giao dịch giới hạn khi chúng xảy ra ở Publisher; vì vậy, trong một publication, thống nhất giao dịch đƣợc đảm bảo.
Transactional replication thƣờng đƣợc sử dụng trong môi trƣờng server-to-server và thích hợp trong mỗi trƣờng hợp sau:
23
- Ứng dụng yêu cầu độ trễ tối thiểu giữa thời gian truyền thay đổi đƣợc tạo ra ở Publisher đến Subscriber.
- Ứng dụng yêu cầu truy cập đến trạng thái dữ liệu trung gian. Ví dụ, nếu một dòng thay đổi năm lần, transactional replication cho phép một ứng dụng trả lời cho mỗi thay đổi.
- Publisher có khối lƣợng các hoạt động insert, update và delete rất lớn.
- Máy chủ cơ sở dữ liệu của Publisher hoặc Subscriber không phải là máy chủ cơ sở dữ liệu SQL, chẳng hạn nhƣ Oracle.
Mặc định, các Subscriber đƣợc coi là read-only, bởi vì các thay đổi không đƣợc truyền lại cho Publisher. Transactional replication không cung cấp các tùy chọn cho phép cập nhật ở Subscriber.
Transaction replication đƣợc thực hiện bởi SQL Server Snapshot Agent, Log Reader Agent và Distribution Agent. Snapshot Agent chuẩn bị các file ảnh chụp bao gồm sơ đồ và dữ liệu của các bảng published và các đối tƣợng cơ sở dữ liệu, lƣu trữ các file trong một thƣ mục ảnh chụp, và đồng bộ hóa các bản ghi trong cơ sở dữ liệu distributor
trên Distributor server.
Log Reader Agent giám sát các transaction log của mỗi cơ sở dữ liệu đƣợc cấu hình cho transaction replication và sao lƣu các giao dịch đƣợc đánh dấu cho replication từ bản ghi transaction trong cơ sở dữ liệu distributor, đóng vai trò nhƣ một hàng đợi lƣu trữ và chuyển tiếp. Distribution Agent sao chép các file ảnh chụp ban đầu từ thƣ mục ảnh chụp và các giao dịch lƣu giữ trong các bảng của cơ sở dữ liệu distribution đến Subscriber.
Các thay đổi tăng lên sẽ tạo ra ở Publisher một luồng đến Subscriber theo lịch trình của Distribution Agent, cái mà có thể chạy liên tiếp cho độ trễ tối thiểu, hoặc trong khoảng thời gian theo lịch trình. Bởi vì các thay đổi từ dữ liệu phải đƣợc tạo ra ở Publisher (khi transation replication đƣợc sử dụng mà không cập nhật ngay tức khắc hoặc tùy chọn cập nhật theo hàng đợi), tránh khỏi xung đột cập nhật. Cuối cùng, tất cả Subscriber sẽ nhận đƣợc cùng một giá trị nhƣ Publisher. Nếu cập nhật ngay tức khắc hoặc tùy chọn cập nhật theo hàng đợi đƣợc sử dụng với transaction replication, cập nhật có thể đƣợc tạo ra ở Subscriber và với cập nhật theo hàng đợi thì xung đột có thể xảy ra.
24
Các Subscriber sẽ trả lời các truy vấn chỉ đọc từ client gửi đến và Publisher sẽ chịu trách nhiệm trả lời các truy vấn ghi với các lệnh cập nhật dữ liệu nhƣ : CREATE, UPDATE, INSERT, DELETE, DROP,… Công việc phân phối các truy vấn đến các Subscriber và Publisher đƣợc giao cho một Load Balancer. Load Balancer phải lọc ra các truy vấn chỉ đọc gửi đến Subsriber và các truy vấn còn lại gửi về Publisher. Nếu có nhiều Subscriber thì Load Balancer sẽ sử dụng một thuật toán để phân tải đều cho các Subscriber [20].
Hình 9: Giải pháp Transaction replication cân bằng tải cho hệ quản trị CSDL SQL
25
SQL server Log shipping cho phép tự động gửi các bản ghi sao lƣu giao dịch từ primary database trên một thể hiện của primary server đến một hoặc nhiều secondary database trên các thể hiện riêng biệt của secondary server. Các bản ghi sao lƣu giao dịch đƣợc áp dụng cho mỗi secondary database riêng. Một tùy chọn thể hiện server thứ ba, đƣợc gọi là monitor server, ghi lại lịch sử và trạng thái của sao lƣu và khôi phục lại các hoạt động và, tùy chọn, đƣa ra cảnh báo nếu các hoạt động đó thất bại không xảy ra nhƣ dự kiến.
Lợi ích của Log shipping:
- Cung cấp một giải pháp phục hồi thảm họa cho một primary database và một hoặc nhiều secondary database, trên mỗi một thể hiện riêng biệt của SQL server. - Hỗ trợ giới hạn truy cập read-only đến secondary database (trong khoảng thời
gian giữa các công việc khôi phục).
- Cho phép một một sự chậm chễ giữa thời gian khi primary server sao lƣu bản ghi của primary database và khi secondary server phải khôi phục lại bản khi sao lƣu. Một sự chậm chễ lâu hơn có thể là hữu ích, ví dụ, nếu dã liệu vô tình thay đổi trên primary database, nếu phát hiện ra điều này một cách nhanh chóng thì thời gian chậm chễ có thể lấy lại đƣợc dữ liệu chƣa bị thay đổi từ secondary database trƣớc khi thay đổi đƣợc diễn ra ở secondary database [21].
26