Giới thiệu
Thông thường, chúng tôi cần đảm bảo khả năng chịu lỗi của MS SQL Server DBMS, đặc biệt, khi không có phiên bản Enterprise mà chỉ có phiên bản Chuẩn.
Chúng tôi muốn lưu ý rằng chúng tôi sẽ không kiểm tra phiên bản Express vì có những hạn chế đáng kể đối với phiên bản này. Chắc chắn, chúng tôi có thể bỏ qua một số trong số họ. Ví dụ:để giải quyết vấn đề với kích thước cơ sở dữ liệu là 10 GB, chúng tôi có thể chia cơ sở dữ liệu lớn thành các cơ sở dữ liệu nhỏ hơn. Để làm điều này, chúng ta có thể tạo một cơ sở dữ liệu mới dựa trên một thuộc tính nhất định và kết hợp các lựa chọn từ các bảng giống nhau của các cơ sở dữ liệu khác nhau trong các dạng xem trong cơ sở dữ liệu chính. Tuy nhiên, khả năng chịu lỗi trong phiên bản Express sẽ được thực hiện bởi quản trị viên hệ thống hoặc bằng cách sử dụng phần mềm của riêng bạn hoặc bên thứ ba.
Trong bài viết này, chúng ta sẽ khám phá tất cả các công nghệ chống lỗi tiêu chuẩn hiện có cho MS SQL Server 2017 và một ví dụ về việc triển khai tiêu chuẩn hợp nhất phù hợp nhất về khả năng chịu lỗi trong phiên bản Standard.
Đánh giá ngắn
-
AlwaysOn
Phân phối tải giữa các bên, tất cả các bên phải giống nhau về đặc tính của họ. Chế độ đồng bộ đảm bảo độ tin cậy tối đa của việc truyền dữ liệu; tuy nhiên, hiệu suất sẽ bằng với tốc độ của bên chậm nhất. Chế độ không đồng bộ đảm bảo hiệu suất cao nhất, nhưng có thể có dữ liệu không khớp giữa các bên, điều này có thể gây ra việc bảo trì phức tạp hơn và xác suất mất các thay đổi mới nhất trong trường hợp bên chính bị lỗi. gần như tức thời và không yêu cầu quản trị viên hệ thống và DBA, trong khi ở chế độ không đồng bộ, nó phụ thuộc vào trạng thái hiện tại của các bản sao DB và thường mất khoảng 5 phút (bạn cũng có thể tự động hóa quá trình chuyển đổi bằng một DBA mà không cần quản trị viên hệ thống ) .Microsoft khuyên bạn nên sử dụng công nghệ này cho cơ sở dữ liệu. Nó có sẵn trong phiên bản Enterprise bắt đầu từ phiên bản 2012 trở lên và có những hạn chế trong phiên bản Chuẩn (Để tìm hiểu thêm, vui lòng tham khảo 5 câu hỏi hàng đầu về Nhóm tính khả dụng cơ bản).
-
Phân cụm
Mặc dù cấu hình đơn giản, giải pháp này không đáng tin cậy do nút cổ chai ở dạng một kho dữ liệu duy nhất. Trong trường hợp kho dữ liệu bị lỗi, sẽ mất hơn 1 giờ để khôi phục lại. Công nghệ này có sẵn trong phiên bản Tiêu chuẩn của phiên bản 2008 trở lên.
-
Nhân rộng
Bất kỳ sao chép nào liên quan đến việc tạo các trình kích hoạt hệ thống cho mỗi bảng tham gia trong khi sao chép ảnh chụp nhanh sẽ tải nặng cơ sở dữ liệu chính. Do đó, việc sao chép ảnh chụp nhanh chỉ có thể được thực hiện trong giờ thấp điểm của tải cơ sở dữ liệu (ví dụ:vào ban đêm), điều này là không thể chấp nhận được, vì cần phải có chế độ chờ nóng. Việc nhân rộng hợp nhất rất phức tạp để được duy trì bởi một số hệ thống (ví dụ:CRM, NAV).
Có thể nhân rộng giao dịch trong phiên bản Enterprise. Có sẵn trong phiên bản Tiêu chuẩn (hợp nhất và ảnh chụp nhanh cơ sở dữ liệu) và phiên bản Doanh nghiệp (giao dịch) cho đến phiên bản 2008 trở lên. -
Bắt chước
Nó có thể ở bất kỳ chế độ nào. Tuy nhiên, chế độ đồng bộ đảm bảo độ tin cậy tối đa và chuyển đổi nhanh chóng, trong khi chế độ không đồng bộ cung cấp cho người dùng tốc độ hoạt động tối đa của cơ sở dữ liệu chính. Tuy nhiên, dữ liệu không khớp có thể xảy ra giữa các bên và quá trình chuyển đổi có thể chậm.
Ở đây, máy chủ nhân chứng hoặc DBA cung cấp công tắc tự động ở cấp cơ sở dữ liệu (ví dụ:khi tải CPU trên 50% trên máy chủ chính). Quản trị viên hệ thống cấp kết nối đến máy chủ khác. Cơ sở dữ liệu dự phòng cho bất kỳ loại sao chép nào đang ở chế độ khôi phục liên tục, vì vậy nó không thể được truy cập.
Chế độ khôi phục của cơ sở dữ liệu đã đầy.
Microsoft coi nó như một công nghệ cơ sở dữ liệu lỗi thời. Nó có sẵn trong phiên bản Tiêu chuẩn (ở chế độ đồng bộ) và trong phiên bản Doanh nghiệp (ở chế độ không đồng bộ) cho đến phiên bản 2008 trở lên.
-
Gửi nhật ký giao dịch
Có hai chế độ:phục hồi liên tục trên máy chủ chờ hoặc khôi phục có độ trễ. Chế độ đầu tiên chuyển cơ sở dữ liệu sao lưu sang chế độ khôi phục liên tục và trong trường hợp này, chúng tôi không thể truy cập nó.
Chế độ thứ hai chuyển cơ sở dữ liệu sao lưu sang chế độ khôi phục thường xuyên trong khi triển khai các bản cập nhật (cơ sở dữ liệu sao lưu có sẵn giữa các lần triển khai, nhưng điều này có thể thực hiện được với điều kiện là các phiên bản MS SQL Server có cùng phiên bản).
Cách hoạt động:
- Định kỳ, một bản sao lưu của nhật ký giao dịch cơ sở dữ liệu được lưu trữ vào một thư mục công khai trên nguồn và máy chủ dự phòng (thư mục và lịch biểu được định cấu hình 15 phút một lần theo mặc định).
- Máy chủ dự phòng sao chép định kỳ bản sao lưu nhật ký giao dịch của cơ sở dữ liệu vào một thư mục cục bộ (thư mục và lịch biểu được định cấu hình 15 phút một lần theo mặc định).
- Máy chủ dự phòng khôi phục nhật ký giao dịch từ bản sao lưu nhật ký giao dịch (lịch trình được định cấu hình 15 phút một lần theo mặc định).
Quản trị viên cơ sở dữ liệu có thể tự động hóa quá trình chuyển đổi ở cấp độ cơ sở dữ liệu, trong khi quản trị viên hệ thống có thể thực hiện việc này ở cấp độ kết nối với máy chủ.
Ngoài ra, cần lưu ý rằng phương thức này luôn hoạt động ở chế độ không đồng bộ. Bạn có thể định cấu hình nhiều cơ sở dữ liệu sao lưu.
Chế độ khôi phục cơ sở dữ liệu đã đầy đủ hoặc được ghi hàng loạt.
Nó có sẵn trong phiên bản Tiêu chuẩn cho đến phiên bản 2008 và cao hơn.
Có hai chế độ:khôi phục liên tục trên máy chủ chờ hoặc khôi phục có độ trễ.
Tóm tắt
Ưu tiên nhất là vận chuyển nhật ký giao dịch trong phiên bản Tiêu chuẩn vì nó thuận tiện để sử dụng nó để chuyển đổi suôn sẻ từ máy chủ này sang máy chủ khác, chẳng hạn như khi cập nhật môi trường. Ngoài ra, việc vận chuyển nhật ký giao dịch rất đơn giản và dễ sử dụng, cũng như luôn hoạt động ở chế độ không đồng bộ, không tải cơ sở dữ liệu nhiều, không giống như chế độ sao chép đồng bộ. Trong mọi trường hợp, phản chiếu có thể chấp nhận được, nếu có thể định cấu hình chuyển đổi tự động của chính nó; nếu không, có thể chuyển đổi sai (ví dụ:khi CPU của máy chủ chính được tải hơn 50%).
Đối với phiên bản Enterprise, hãy sử dụng công nghệ AlwaysOn.
Định cấu hình chuyển đổi dự phòng khi vận chuyển nhật ký giao dịch
Bạn có thể tìm thông tin chi tiết hơn về việc định cấu hình vận chuyển nhật ký giao dịch tại đây. Ngoài ra, có thể tự động hóa quá trình này bằng cách phát triển tiện ích của riêng bạn để sử dụng nhiều lần, cũng như để quay lại máy chủ chính sau khi nó đã được sửa chữa trong trường hợp chuyển đổi dự phòng.
Hãy để chúng tôi khám phá một trong những tùy chọn có thể có để gỡ lỗi chuyển đổi dự phòng khi vận chuyển nhật ký giao dịch ở cấp DBMS.
Cần lưu ý rằng phương pháp này phù hợp với máy chủ chỉ dành riêng cho một phiên bản của phiên bản MS SQL Server, vì trong một số trường hợp, có vấn đề trong việc xác định nhiệm vụ nào sẽ thực thi và tác vụ nào chúng tôi không thực thi.
Hãy mô tả trình tự các bước:
- Thực hiện tất cả các tác vụ để sao chép các tệp mới nhất từ nguồn (Với kiến trúc được cân nhắc kỹ lưỡng, thư mục phải có thể truy cập được ngay cả khi máy chủ chính gặp sự cố)
- Tắt tất cả các tác vụ sao chép tệp từ nguồn
- Thực hiện tất cả các tác vụ để khôi phục cơ sở dữ liệu bằng cách sử dụng các tệp mới nhất từ nguồn
- Tắt tất cả các tác vụ khôi phục cơ sở dữ liệu bằng cách sử dụng các tệp mới nhất từ nguồn
- Làm cho cơ sở dữ liệu được khôi phục và chính cho việc vận chuyển nhật ký, nhưng không có người nhận
- Tạo bản sao lưu đầy đủ của cơ sở dữ liệu
- Tạo các tác vụ để sao lưu nhật ký giao dịch
Dưới đây là một ví dụ về việc triển khai trình tự được đề cập ở trên như một thủ tục được lưu trữ.
Cần lưu ý rằng điều quan trọng là phải định cấu hình đăng nhập (tốt nhất là đăng nhập tên miền), theo đó các tác vụ sẽ được thực hiện để tạo bản sao lưu nhật ký giao dịch.
Ví dụ về gỡ lỗi chuyển đổi dự phòng của quá trình vận chuyển nhật ký giao dịch
TẠO THỦ TỤC [srv]. [RunLogShippingFailover] @isfailover bit =1, @login nvarchar (255) =N'LOGIN ', - đăng nhập miền theo đó các tác vụ sẽ được thực hiện để tạo bản sao lưu nhật ký giao dịch. @backup_directory nvarchar (255) =N'DIRECTORY' — thư mục công cộng để gửi bản sao lưu nhật ký giao dịch giữa các phiên bản MS SQL Server (ví dụ:'D:\ Shared') AS / * Di chuyển máy chủ dự phòng sang chế độ chính khi máy chủ máy chủ ngừng hoạt động nếu @ isfailover =1 hoàn toàn tự động khi @isfailover bằng 0, không có gì xảy ra - ở đây chúng ta cần tạo lại nhật ký vận chuyển từ chế độ chờ sang máy chủ chính, sau đó chúng ta cần chuyển sang máy chủ chính và sau đó định cấu hình lại việc vận chuyển nhật ký giao dịch. máy chủ dự phòng này được cho là nhận bản sao lưu nhật ký giao dịch từ một máy chủ * / BEGIN - nếu có sự chuyển đổi sang máy chủ dự phòng, bạn cần thực hiện tất cả các tác vụ để sao chép các tệp mới nhất từ nguồn nếu (@ isfailover =1) bắt đầu chọn [job_id] vào #jobs từ [msdb]. [Dbo]. [Sysjobs] trong đó [name] như 'LSCopy%'; khai báo @job_id uniqueidentifier; while (tồn tại (chọn đầu (1) 1 từ #jobs)) bắt đầu chọn đầu (1) @ job_id =[job_id] từ #jobs; bắt đầu thử EXEC [msdb] .dbo.sp_start_job @ example @ sqldat.com_id; kết thúc thử bắt đầu bắt đầu bắt xóa từ #jobs where [job_id] [email protected]_id; cuối bảng thả #jobs; end - vô hiệu hóa tất cả các tác vụ sao chép tệp từ nguồn khi chuyển sang máy chủ sao lưu - bật tất cả các tác vụ sao chép tệp từ nguồn khi quay lại bản cập nhật máy chủ sản xuất [msdb]. [dbo]. [sysjobs] set [enable] =case when (@ isfailover =1) then 0 else 1 end where [name] like 'LSCopy%'; --nếu chúng ta chuyển sang máy chủ dự phòng, chúng ta cần thực hiện tất cả các tác vụ để khôi phục cơ sở dữ liệu bằng cách sử dụng các tệp mới nhất từ nguồn nếu (@ isfailover =1) begin select [job_id] into # job2 from [msdb]. [dbo ]. [sysjobs] trong đó [name] như 'LSRestore%'; while (tồn tại (chọn hàng đầu (1) 1 từ # công việc2)) bắt đầu chọn đầu trang (1) @ job_id =[job_id] từ # job2; bắt đầu thử EXEC [msdb] .dbo.sp_start_job @ example @ sqldat.com_id; EXEC [msdb] .dbo.sp_start_job @ example @ sqldat.com_id; kết thúc thử bắt đầu bắt đầu bắt xóa từ # job2 where [job_id] [email protected]_id; cuối bảng thả # job2; end - vô hiệu hóa tất cả các tác vụ để khôi phục cơ sở dữ liệu bằng cách sử dụng các tệp mới nhất từ nguồn khi chuyển sang máy chủ dự phòng - bật tất cả các tác vụ để khôi phục cơ sở dữ liệu bằng các tệp mới nhất khi quay lại bản cập nhật máy chủ sản xuất [msdb]. [dbo] . [sysjobs] set [enable] =case when (@ isfailover =1) then 0 else 1 end where [name] like 'LSRestore%'; --khi chuyển sang máy chủ dự phòng, chúng tôi đặt cơ sở dữ liệu có thể khôi phục lại và chính để vận chuyển nhật ký mà không có người nhận nếu (@ isfailover =1) bắt đầu chọn [Secondary_database] làm [name] thành #dbs từ msdb.dbo.log_shipping_monitor_secondary trong đó [Secondary_server ] example @ sqldat.com @ SERVERNAME; khai báo @db nvarchar (255); while (tồn tại (chọn top (1) 1 từ #dbs)) bắt đầu chọn top (1) @ db =[name] từ #dbs; bắt đầu thử KHÔI PHỤC CƠ SỞ DỮ LIỆU @db CÓ PHỤC HỒI; kết thúc thử bắt đầu bắt đầu bắt xóa từ #dbs where [name] [email protected]; cuối bảng thả #dbs; chọn [Secondary_database] làm [name] vào # dbs2 từ msdb.dbo.log_shipping_monitor_secondary trong đó [Secondary_server] example @ sqldat.com @ SERVERNAME; khai báo @jobId BINARY (16); khai báo @command nvarchar (max); khai báo @dt nvarchar (255) =cast (YEAR (GetDate ()) as nvarchar (255)) + '_' + cast (MONTH (GetDate ()) as nvarchar (255)) + '_' + ép kiểu (DAY ( GetDate ()) as nvarchar (255)) + '_' + cast (DatePart (giờ, GetDate ()) as nvarchar (255)) + '_' + cast (DatePart (phút, GetDate ()) dưới dạng nvarchar (255 )) + '. trn'; khai báo @backup_job_name nvarchar (255); khai báo @schedule_name nvarchar (255); khai báo @disk nvarchar (255); khai báo @uid uniqueidentifier; while (tồn tại (chọn đầu (1) 1 từ # dbs2)) bắt đầu chọn đầu (1) @ db =[name] từ # dbs2; set @ example @ sqldat.com_directory + N '\' [email protected]+N'.bak '; set @ backup_job_name =N'LSBackup_'example @ sqldat.com; set @ history_name =N'LSBackupSchedule_'example @ sqldat.com @ SERVERNAME + N '_' [email protected]; set @ command =N'declare @disk nvarchar (max) ='+ N' '' '[email protected]_directory+N' \ '[email protected] +' _ '[email protected]+N' '' ' + N'BACKUP LOG ['[email protected]+'] TO DISK =@disk WITH NOFORMAT, NOINIT, NAME ='+N''''[email protected]+N''''+N', SKIP, NOREWIND, NOUNLOAD, STATS =10; '; đặt @ uid =newid (); bắt đầu thử BACKUP DATABASE @db TO DISK =@disk VỚI NOFORMAT, NOINIT, NAME =@db, SKIP, NOREWIND, NOUNLOAD, STATS =10; EXEC msdb.dbo.sp_add_job @ example @ sqldat.com_job_name, @ enable =1, @ Inform_level_eventlog =0, @ allow_level_email =0, @ Inform_level_netsend =0, @ Inform_level_page =0, @ delete_level =0, @ description =N'Không có mô tả có sẵn. ', @ category_name =N' [Chưa được phân loại (Cục bộ)] ', @ example @ sqldat.com, @job_id =@jobId OUTPUT; EXEC msdb.dbo.sp_add_jobstep @ example @ sqldat.com, @ example @ sqldat.com_job_name, @ step_id =1, @ cmdexec_success_code =0, @ on_success_action =1, @ on_success_step_id =0, @ on_fail_action =2, @ on_fail @ retry_attempts =0, @ retry_interval =0, @ os_run_priasty =0, @ subsystem =N'TSQL ', @ example @ sqldat.com, @ database_name =N'master', @ flags =0; EXEC msdb.dbo.sp_update_job @job_id =@jobId, @start_step_id =1; EXEC msdb.dbo.sp_add_jobschedule @ example @ sqldat.com, @ example @ sqldat.com_job_name, @ enable =1, @ freq_type =4, @ freq_interval =1, @ freq_subday_type =4, @ freq_subday_interval =5, @ freq_relative_interval =0 ,relative_interval @ freq_recency_factor =0, @ active_start_date =20171009, @ active_end_date =99991231, @ active_start_time =0, @ active_end_time =235959, @ example @ sqldat.com; EXEC msdb.dbo.sp_add_jobserver @job_id =@jobId, @server_name =N '(cục bộ)'; kết thúc thử bắt đầu bắt đầu bắt xóa từ # dbs2 where [name] [email protected]; cuối bảng thả # dbs2; endEND
Để quay lại máy chủ chính, cần phải định cấu hình vận chuyển nhật ký giao dịch từ máy chủ dự phòng đến máy chủ chính, sau đó thực hiện gỡ lỗi chuyển đổi dự phòng. Sau đó, máy chủ chính sẽ trở thành máy chủ sản xuất. Sau đó, bạn cần định cấu hình việc vận chuyển nhật ký giao dịch từ máy chủ sản xuất sang máy chủ ở chế độ chờ.
Định cấu hình điều chỉnh tự động để theo dõi việc vận chuyển nhật ký giao dịch
Để giám sát việc vận chuyển nhật ký giao dịch, hãy sử dụng tác vụ LSAlert_
Thông thường, theo thời gian, máy chủ giám sát (trong trường hợp nếu nó không phải là máy chủ sản xuất) lấy sai thời gian gần đây để tạo bản sao lưu của nhật ký giao dịch cơ sở dữ liệu trên máy chủ sản xuất. Do đó, chúng tôi phải đối mặt với các cảnh báo sai.
Có thể giải quyết vấn đề bằng cách sử dụng tập lệnh sau:
Ví dụ về định cấu hình điều chỉnh để giám sát việc vận chuyển nhật ký giao dịch
TẠO THỦ TỤC [srv]. [AutoCorrectMonitorLogShipping] ASBEGIN / * Điều chỉnh giám sát việc vận chuyển nhật ký giao dịch * / BẬT SỐ KHOẢN; cập nhật t2 đặt t2. [last_backup_date] =t1. [BackupFinishDate], t2. [last_backup_date_utc] =DateAdd (giờ, -DateDiff (giờ, GetUTCDate (), GetDate ()), t1. [BackupFinishDate]), t2. [last_backup_file ] =RIGHT (t1. [PhysicalDeviceName], CHARINDEX ('\', REVERSE (t1. [PhysicalDeviceName]), 1) -1) từ [PRODUCTION_INSTANCE_NAME]. [SRV]. [Inf]. [VServerLastBackupDB] với tư cách tham gia bên trong t1 [msdb]. [dbo]. [log_shipping_monitor_primary] là t2 vào t1. [DBName] đối chiếu SQL_Latin1_General_CP1_CI_AS =t2. [primary_database] đối chiếu SQL_Latin1_General_CP1_CI_AS trong đó t1. [BackupType] =N'logChúng tôi có thể tự động gọi một thủ tục được lưu trữ theo thời gian. Ví dụ:chúng ta có thể tạo một nhiệm vụ thích hợp trong Đại lý và lên lịch cho nó cứ sau 5 phút. Tất nhiên, máy chủ sản xuất phải được liên kết với máy chủ dự phòng (Đối tượng máy chủ \ Máy chủ được liên kết).
Ở đây chúng tôi sử dụng chế độ xem [inf]. [VServerLastBackupDB] trong cơ sở dữ liệu SRV để xác định các bản sao lưu cơ sở dữ liệu mới nhất:
Ví dụ về triển khai chế độ xem vServerLastBackupDB:
TẠO CHẾ ĐỘ XEM [inf]. [vServerLastBackupDB] aswith backup_cte as (select bs. [database_name], backup_type =case bs. [type] khi 'D' rồi 'cơ sở dữ liệu' khi 'L' rồi 'log' khi 'I 'then chốt' khác biệt 'khác' khác 'kết thúc, bs. [first_lsn], bs. [last_lsn], bs. [backup_start_date], bs. [backup_finish_date], ép kiểu (bs. [backup_size] dưới dạng số thập phân (18,3)) / 1024/1024 dưới dạng BackupSizeMb, rownum =row_number () over (phân vùng theo bs. [Database_name], nhập thứ tự theo bs. [Backup_finish_date] desc), LogicalDeviceName =bmf. [Logic_device_name], PhysicalDeviceName =bmf. [Physical_device_name], bs . [server_name], bs. [user_name] FROM msdb.dbo.backupset bs INNER JOIN msdb.dbo.backupmediafamily bmf ON [bs]. [media_set_id] =[bmf]. [media_set_id]) chọn [server_name] làm [Tên máy chủ] , [database_name] là [DBName], [user_name] là [ USerName], [backup_type] as [BackupType], [backup_start_date] as [BackupStartDate], [backup_finish_date] as [BackupFinishDate], [BackupSizeMb], - kích thước không nén [LogicalDeviceName], [PhysicalDeviceName], [first_lsn] dưới dạng , [last_lsn] dưới dạng [LastLSN] từ backup_ctewhere rownum =1;Kết quả
Trong bài viết này, chúng tôi đã xem xét ngắn gọn tất cả các tùy chọn khả năng chịu lỗi và tính khả dụng nhanh có thể có trong MS SQL Server 2017, cũng như các ví dụ về việc triển khai gỡ lỗi chuyển đổi dự phòng và điều chỉnh tự động giám sát việc vận chuyển nhật ký giao dịch.
Tài liệu tham khảo:
- msdb
- Các phiên bản SQL Server 2017 có sẵn
- Luôn bật
- Cài đặt cụm chuyển đổi dự phòng SQL Server
- Nhân rộng
- Bắt chước
- Ghi nhật ký Vận chuyển
- Định cấu hình Vận chuyển nhật ký