Sqlserver
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Sqlserver

Cách sử dụng các tính năng AlwaysOn của SQL Server

Khi máy chủ ngừng hoạt động, nó có thể dẫn đến gián đoạn các mục tiêu kinh doanh của bạn và dẫn đến mất doanh thu. Ví dụ:một hãng hàng không có thể không đặt được chuyến bay cho khách hàng nếu các phiên bản và cơ sở dữ liệu không có sẵn. Hệ thống có thể bị lỗi vì nhiều lý do, chẳng hạn như cháy, lỗi do con người, lỗi máy tính, lỗi đĩa và lỗi lập trình.

Để tránh gián đoạn và đảm bảo rằng có sự liên tục trong các dịch vụ kinh doanh, điều cực kỳ quan trọng là phải có sẵn các chiến lược phục hồi sau thảm họa (HA) và khả năng phục hồi sau thảm họa (DR). HA và DR thường được thảo luận cùng nhau. HA quan tâm đến việc giảm thời gian ngừng hoạt động của máy chủ càng nhiều càng tốt, nhưng vì không có hệ thống nào là hoàn hảo, DR tập trung vào quá trình sử dụng phương tiện sao lưu để khôi phục dữ liệu bị mất trong trường hợp hệ thống cơ sở dữ liệu gặp sự cố.

AlwaysOn là một thuật ngữ thương hiệu / tiếp thị được sử dụng kể từ SQL Server 2012 để mô tả các tính năng HADR nâng cao của Microsoft. Trước AlwaysOn, công cụ cơ sở dữ liệu đã hỗ trợ các giải pháp độc quyền tích hợp sẵn khác, chẳng hạn như phản chiếu cơ sở dữ liệu, cụm chuyển đổi dự phòng và vận chuyển nhật ký. Tuy nhiên, mỗi kỹ thuật đó đều có những lợi ích và hạn chế. Thông thường, tùy thuộc vào mục tiêu của mình, một tổ chức phải kết hợp nhiều phương pháp với nhau để đạt được một chiến lược HADR mong muốn.

Các tính năng của AlwaysOn đã được giới thiệu, do đó bạn không phải mất thêm thời gian và tài nguyên để triển khai, đồng thời gây ra sự phức tạp trong việc triển khai vì lý do dự phòng cả máy chủ và cơ sở dữ liệu, gặp sự cố với việc mở rộng quy mô hoặc có phần cứng dự phòng không được sử dụng hiệu quả. Những tính năng này kết hợp một cách thuận tiện nhiều phương pháp cũ lại với nhau và cải thiện những lĩnh vực mà chúng còn thiếu sót. Để thực sự hiểu giá trị của các dịch vụ AlwaysOn, điều quan trọng là phải xem lại các khái niệm cơ bản ban đầu về cách công cụ cơ sở dữ liệu đảm bảo hệ thống HADR trong quá khứ.

Phản chiếu cơ sở dữ liệu

Dự phòng cơ sở dữ liệu có thể được thực hiện thông qua phản chiếu. Ví dụ:bạn có thể có một ứng dụng client front-end, tạo doanh thu cho phép sinh viên đặt mua sách giáo khoa trực tuyến. Một khách hàng chọn giao dịch mua của họ và các yêu cầu được thực hiện dựa trên cơ sở dữ liệu của PsychologyBooks ở mặt sau. Trong trường hợp xảy ra thảm họa khiến cơ sở dữ liệu PsychologyBooks không khả dụng, học sinh sẽ không thể hoàn thành đơn đặt hàng của mình.

Để tránh sự gián đoạn này, bạn có thể có một phiên bản chính được triển khai trong quá trình sản xuất có chứa cơ sở dữ liệu PsychologyBooks và có thêm một bản sao của cơ sở dữ liệu PsychologyBooks đó trên một máy chủ được nhân bản ở chế độ chờ. Các ứng dụng khách có thể kết nối lại với bản sao được nhân đôi thay vì gặp phải sự cố gián đoạn và phải đợi quá trình khôi phục để kết thúc bản chính. Bản sao theo kịp những thay đổi được thực hiện trên bản gốc bằng cách nhận nhật ký giao dịch và sau đó thực hiện lại những thay đổi đã ghi đó.

Phiên phản chiếu có thể hoạt động ở các chế độ khác nhau tùy thuộc vào hiệu suất hoặc lý do an toàn cao. Thuận tiện, chuyển đổi dự phòng tự động được hỗ trợ khi phiên phản chiếu được vận hành ở chế độ đồng bộ an toàn cao và sự đồng thuận số đại biểu được thiết lập với sự hiện diện của máy chủ nhân chứng tùy chọn.

Mặc dù có những lợi ích của việc nhân bản, nhưng nó không thành công vì nó chỉ cung cấp dự phòng cơ sở dữ liệu chứ không phải dự phòng máy chủ. Điều đó có nghĩa là nếu phiên bản máy chủ chính gặp sự cố, cả hai phiên bản sẽ ngừng hoạt động và việc có một bản sao dự phòng của dữ liệu ở cấp cơ sở dữ liệu sẽ không thành vấn đề. Chế độ chờ không hỗ trợ hoạt động của người dùng và cần có ảnh chụp nhanh để có được bản sao chỉ đọc của dữ liệu trên phiên bản được phản chiếu. Cơ sở dữ liệu được bảo vệ, nhưng các đối tượng cấp máy chủ, chẳng hạn như tư cách thành viên vai trò máy chủ, thông tin đăng nhập và công việc tác nhân, thì không.

Ví dụ:nếu có một nhóm tiếp thị lớn và mỗi thành viên đều có thông tin đăng nhập riêng, họ sẽ phải thực hiện lại quá trình tạo lại thông tin đăng nhập cho từng người. Khi chuyển đổi dự phòng xảy ra, nó dựa trên cơ sở cơ sở dữ liệu độc lập chứ không phải là một nhóm.

Phân cụm chuyển đổi dự phòng

Phân cụm chuyển đổi dự phòng cung cấp khả năng dự phòng ở cấp cá thể và cung cấp khả năng bảo vệ khỏi các lỗi phần cứng và hệ điều hành. Ví dụ:giả sử một nút trong Queen Anne bốc cháy, gây ra lỗi thiết bị. Toàn bộ phiên bản — bao gồm các đối tượng mức cá thể, chẳng hạn như thông tin đăng nhập hoặc các công việc cụ thể đã được tạo để thực hiện các tác vụ cụ thể — sẽ được bảo vệ và có thể tự động khởi động lại trên một nút khác thuộc cụm. Các ứng dụng và dịch vụ của khách hàng sẽ tiếp tục khả dụng cho khách hàng.

Trường hợp trên hoạt động vì bộ nhớ được chia sẻ giữa các máy chủ vật lý dự phòng trong nhóm Cụm chuyển đổi dự phòng Windows Server (WSFC). Cả OS và SQL Server đều hoạt động cùng nhau để chỉ một nút sở hữu nhóm tài nguyên WSFC tại một thời điểm.

Thật không may, với một bộ nhớ chung, giải pháp này không cung cấp cơ sở dữ liệu dự phòng mà chiến lược sao chép trước đó đã cung cấp. Việc có một bộ nhớ dùng chung sẽ dẫn đến rủi ro vì nó dẫn đến một điểm lỗi duy nhất. Ví dụ:các đĩa bên ngoài có thể chứa bản sao duy nhất của cơ sở dữ liệu PsychologyBooks quan trọng và, mặc dù phiên bản được chuyển đến nút Ballard thành công, vẫn có thể bị gián đoạn các mục tiêu kinh doanh nếu thành phần lưu trữ duy nhất bị xâm phạm. Phân cụm chuyển đổi dự phòng cũng đề xuất các hạn chế về khả năng mở rộng vì các ứng dụng khách không thể xử lý khối lượng công việc ngày càng tăng và mở rộng ra xa hơn cụm.

Đăng ký Vận chuyển

Một phương pháp khác để đạt được sự dự phòng của cơ sở dữ liệu là thông qua việc vận chuyển nhật ký. Nhật ký giao dịch được sao lưu trên máy chủ chính và được gửi đến một hoặc nhiều máy chủ phụ để được khôi phục. Không giống như sao chép, (các) cơ sở dữ liệu thứ cấp có thể đủ điều kiện cho hoạt động chỉ đọc và tần suất vận chuyển nhật ký có thể được định cấu hình cho các khoảng thời gian khác nhau. Có một lợi ích về hiệu suất trong các tình huống trong đó cơ sở dữ liệu thứ cấp không nhất thiết phải đồng bộ với cơ sở dữ liệu chính trong thời gian thực.

Ví dụ:chạy một báo cáo tóm tắt thống kê vào cuối đêm để xem những cuốn sách tâm lý học nào được bán trong ngày không yêu cầu cơ sở dữ liệu sao chép phải đồng bộ chính xác với cơ sở dữ liệu chính. Hoạt động đọc nhiều đặt các ổ khóa trên các đối tượng cơ sở dữ liệu và có thể tăng thời gian chờ. Do đó, việc chạy báo cáo trên máy chủ phụ sẽ giảm bớt nhu cầu khối lượng công việc trên máy chủ tạo doanh thu chính.

Hạn chế là vận chuyển nhật ký không hỗ trợ chuyển đổi dự phòng tự động. Do đó, nếu máy chủ nguồn bị lỗi, cơ sở dữ liệu cần được khôi phục theo cách thủ công. Giống như phản chiếu, vận chuyển nhật ký không cung cấp dự phòng cho máy chủ và là một giải pháp cấp cơ sở dữ liệu.

Hiểu AlwaysOn

Các công nghệ cũ đều có những lợi ích và sự đánh đổi của chúng. Tuy nhiên, việc triển khai một giải pháp HADR tùy chỉnh có thể nhanh chóng trở nên phức tạp và đòi hỏi nhiều quản lý hơn vì các chiến lược khác nhau này được kết hợp tùy ý và kết hợp với nhau để đáp ứng nhu cầu kinh doanh. Do đó, các tính năng AlwaysOn đã được giới thiệu và cung cấp một phiên bản nâng cao, đã được kết hợp của các chiến lược trước đó.

SQL Server cung cấp hai tính năng:Nhóm sẵn sàng AlwaysOn (AG) và Phiên bản cụm chuyển đổi dự phòng AlwaysOn (FCI). Cả hai đều yêu cầu thực hiện phân cụm chuyển đổi dự phòng Windows Server (WSFC).

AG là một nhóm cơ sở dữ liệu sẽ chuyển đổi dự phòng cùng nhau. Bạn sẽ cần một số nút vật lý dự phòng với phiên bản SQL Server được cài đặt trên mỗi nút để lưu trữ các bản sao khả dụng. Mỗi bản sao phải nằm trên một nút khác nhau của cùng một WSFC. Trong giản đồ trên, bản sao chính được lưu trữ trên Node 01 và tất cả các bản sao thứ cấp khác đủ điều kiện để chuyển đổi dự phòng khi WSFC phát hiện có vấn đề.

Cách các bản sao thứ cấp luôn đồng bộ với bản chính là bằng cách gửi nhật ký giao dịch và thực hiện lại các thay đổi. AG hỗ trợ cả chế độ cam kết không đồng bộ và đồng bộ. Bản sao chính đủ điều kiện để đọc và ghi, trong khi các bản sao thứ cấp chỉ đủ điều kiện để đọc. Sao lưu có thể được thực hiện trên vị trí phụ.

Ngay lập tức, có những lợi ích với AlwaysOn AG. Nhớ lại từ trước rằng một số sai sót với phản chiếu cơ sở dữ liệu là cơ sở dữ liệu chỉ có thể được sao chép đến một máy chủ phụ và khi chuyển đổi dự phòng xảy ra, mỗi cơ sở dữ liệu được nhân bản độc lập. Với AG, cơ sở dữ liệu được tạo dư thừa ở nhiều nơi, chẳng hạn như Node 02, Node 03, Node 04 và Node 05 trong ví dụ trên. Hỗ trợ tính khả dụng của cơ sở dữ liệu cho phép lên đến chín bản sao tính khả dụng.

Hơn nữa, vận chuyển nhật ký sẽ là cần thiết để đạt được dữ liệu chỉ đọc trên máy chủ phụ. Nhưng với AG, dữ liệu chỉ đọc đã được tính đến. Các hoạt động cần đọc nhiều như báo cáo có thể được thực hiện trên bất kỳ bản sao thứ cấp nào. Cũng lưu ý rằng không có ràng buộc về bộ nhớ dùng chung.

Tuy nhiên, AG có thể được kết hợp với AlwaysOn FCI để cho phép dự phòng máy chủ. Một phiên bản FCI có thể được sử dụng để lưu trữ các bản sao tính khả dụng để các đối tượng cấp máy chủ như thông tin đăng nhập và công việc tác nhân cũng có thể được bảo vệ. Cách tiếp cận này sẽ yêu cầu bộ nhớ được chia sẻ. Tuy nhiên, những bất tiện như phải thực hiện cấu hình lại cho các ứng dụng khách sẽ được loại bỏ.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Chạy tất cả các tệp SQL trong một thư mục

  2. Làm cách nào để truy vấn tất cả các ngày lớn hơn một ngày nhất định trong SQL Server?

  3. DATETIME2FROMPARTS () Ví dụ trong SQL Server (T-SQL)

  4. Phải khai báo lỗi biến @myvariable với truy vấn được tham số ADO

  5. Làm cách nào để tạo một thủ tục được lưu trữ sẽ tùy chọn tìm kiếm các cột?