Bài viết này thảo luận về cách thiết lập log shipping, là một giải pháp disaster recovery (DR), với database Microsoft® SQL Server® AlwaysOn đã được cấu hình sẵn.
Giới thiệu
Tính năng AlwaysOn availability group (AG) là giải pháp high-availability và disaster recovery cung cấp giải pháp thay thế cấp enterprise cho database mirroring. Được giới thiệu trong SQL Server 2012 (11.x), AlwaysOn AGs tối đa hóa sẵn sàng của một tập user database cho enterprise. AGs hỗ trợ môi trường fail over cho một tập rời rạc user database, gọi là availability databases, fail over cùng nhau. Chúng cũng hỗ trợ tập read-write primary database và một đến tám tập secondary database tương ứng. Tùy chọn, AGs có thể làm cho secondary database có sẵn cho read-only access và một số backup operation.
SQL Server log shipping cho phép bạn tự động gửi transaction log backup từ primary database trên primary server instance đến một hoặc nhiều secondary database trên secondary server instance riêng biệt. Transaction log backup được áp dụng cho từng secondary database riêng lẻ.
Lý do bạn có thể cần AlwaysOn log shipping
Giả sử bạn đã cấu hình AlwaysOn setup giữa primary replica server và secondary replica của bạn và AlwaysOn được dùng trong main data center. Bạn có thể cần dùng log shipping nếu bạn không thể mở rộng cấu hình Windows Server Failover Cluster (WSFC) yêu cầu vào DR site. Lý do bao gồm các khả năng sau:
- Cơ sở hạ tầng hoặc nhân sự không thể duy trì cấu hình WSFC giữa các site khác nhau.
- Bạn không thể tận dụng target server trong DR site trong cấu hình WSFC vì nó đã là một phần của cấu hình WSFC khác.
- Service level agreements (SLAs) trên recovery point objective (RPO) và recovery time objective (RTO) buộc khôi phục nhanh từ lỗi thủ công, chỉ có thể thực hiện được với delayed recovery restoring transaction log backup trên một instance của chiến lược high availability (HA) và DR.
Do đó, bạn cần cung cấp target server, ở DR site, bằng cách dùng log shipping để ship transaction log từ backup được thực hiện ở main site trên current primary.
Điều kiện tiên quyết cho log shipping
Trước khi thiết lập log shipping, hãy chắc chắn bạn đáp ứng các điều kiện tiên quyết sau:
- Primary database phải dùng full hoặc bulk-logged recovery model. Chuyển database sang simple recovery khiến log shipping ngừng hoạt động.
- Trước khi cấu hình log shipping, bạn phải tạo shared path để transaction log backup có sẵn cho secondary server.
- Stored procedure log-shipping yêu cầu membership trong sysadmin fixed server role.
- Backup shared path nên có read và write permissions cho SQL Server service account.
Ví dụ cấu hình giải pháp DR log shipping
Trong ví dụ này, chúng ta đã setup AlwasyOn giữa primary replica server, gọi là PRIMEHEAD, và secondary replica của bạn, gọi là HEAD2, như hình sau:
Phần này cung cấp giải pháp từng bước để cấu hình log shipping trên database đã là một phần của AlwaysOn AG.
Bước 1
Cấu hình log shipping cho database AdventureWork2014 giữa PRIMEHEAD và DR server, HEAD3.
Khi cấu hình log shipping trên database, lấy full backup của database AdventureWork2014 và restore nó trên HEAD3 với non-recovery. Bạn cần tạo shared folder trên PRIMEHEAD để lưu log backup mà job LSCopy (log shipping) dùng.
Bước 2
Chuột phải vào database, chọn Properties, và click vào tùy chọn Transaction Log Shipping ở bên trái của PRIMEHEAD. Sau đó, click vào checkbox Enable this as a primary database in a log shipping configuration được highlight như hình sau:
Bước 3
Click Backup Setting để cấu hình tùy chọn LS Backup. Chọn network-shared path cho LS Backup, như hình sau:
Bước 4
Tại thời điểm này, bạn cũng có thể lên lịch LS Backup theo yêu cầu của bạn. Tuy nhiên, trong kịch bản này, dùng cài đặt mặc định.
Bước 5
Để thêm DR server, click Add như hình sau:
Bước 6
Click Connect để kết nối đến HEAD3, DR server, như hình sau:
Bước 7
Trên tab Initialize Secondary Database, chọn tùy chọn thứ ba vì database đã được khởi tạo trên HEAD3.
Bước 8
Click tab Copy Files. Trong hộp Destination folder for copied files, nhập đường dẫn nơi transaction log backup được copy. Cho kịch bản này, dùng C:\LSCopyAlwaysOn cho đường dẫn, như hình sau:
Bước 9
Trên tab Restore Transaction Log, dưới Database state when restoring backups, chọn No recovery mode hoặc Standby mode, như hình sau:
Trong ví dụ này, chúng tôi chọn No recovery mode, ngụ ý DR database không thể truy cập. Nếu bạn chọn Standby Mode, DR database có sẵn cho end user ở chế độ read-only.
Bước 10
Click OK để bắt đầu log shipping.
Màn hình sau hiển thị:
Bước 11
Để kiểm tra trạng thái log shipping, chuột phải vào DR server, HEAD3, instances, và chọn Reports->Standard reports—>Transactional Log Shipping Status. Nếu màn hình sau xuất hiện, log shipping khỏe mạnh và hoạt động như mong đợi.
Nếu AG fail over giữa PRIMEHEAD và HEAD2 xảy ra, log shipping bị gián đoạn cho đến khi bạn cấu hình nó xem xét AG specifications.
Bây giờ bạn có thể cấu hình log shipping từ HEAD2 đến HEAD3, sẽ không ảnh hưởng chức năng log shipping ngay cả khi có fail over trong tương lai giữa AG replicas. Log backup luôn xảy ra trên cùng path hoặc location, bất kể replica nào đang phục vụ như primary.
Bạn cần khởi tạo fail over giữa các replica. Trước khi khởi tạo fail over, hoàn thành các bước sau:
Thực thi LS backup job trên primary replica và disable job.
Thực thi LS copy và restore job trên secondary replica và sau đó disable nó.
Để làm điều này, chuột phải vào AG và chọn tùy chọn fail over như hình sau:
Bạn cũng có thể thực hiện điều này bằng cách dùng các lệnh T-SQL sau để thủ công kích hoạt AG fail over:
USE master; GO ALTER AVAILABILITY GROUP [AGName] FAILOVER GO Sau khi fail over hoàn tất, cửa sổ sau hiển thị:
Bước 12
Sau AG fail over giữa PRIMEHEAD và HEAD2, current primary instance là HEAD2.
Làm theo các bước tương tự để cấu hình log shipping từ current primary server hoặc node, HEAD2, đến DR Server, HEAD3. Khi cấu hình log shipping, chọn cùng shared path mà bạn dùng trong cấu hình LS giữa PRIMEHEAD và HEAD3, \Avail2017\lsbackup.
Bước 13
Sau khi log shipping giữa HEAD2, current primary, và HEAD3 hoàn tất, một LS backup job được tạo trên HEAD2, và một tập LS copy và LS restore job khác được tạo trên HEAD3.
Một lần nữa, khởi tạo fail over giữa AG replicas. Trước khi khởi tạo fail over, hãy chắc chắn hoàn thành các bước sau:
Thực thi LS backup job trên primary (HEAD2) và disable job.
Thực thi LS copy và restore job trên secondary (HEAD3) và sau đó disable nó.
Bước 14
Sau fail over cuối cùng, current primary là PRIMEHEAD, HEAD2 là secondary replica, và HEAD3 là DR server. Vì LS backup job tồn tại trên cả hai server (primary và secondary), bạn cần sửa đổi LS backup job trên cả PRIMEHEAD và HEAD2 để đảm bảo nó chỉ lấy log backup từ current primary.
Để làm điều này, thêm mã sau vào job step 1:
Declare @dbname as varchar(20) Set @dbname=’AdventureWorks2014’ If sys.fn_hadr_backup_is_preferred_replica (@dbname)<>1 begin RAISERROR (50005,-- Message id, 16, -- Severity, 1, --State, N’This is not the primary server backup is rolled back’); end Hình sau minh họa điều này:
Sau khi thực hiện thay đổi trước, lưu ý LS backup job bắt đầu fail trên secondary server nhưng chạy tốt trên primary.
Bước 15
Vì có hai tập LS copy và restore job trên HEAD3, DR server, bạn phải đảm bảo chỉ một tập job chạy tại một thời điểm. Bạn cần giữ job enabled được tạo khi cấu hình log shipping giữa HEAD2 và HEAD3 và disable tập job còn lại.
Hình sau cho thấy thêm chi tiết:
Bây giờ, bạn đã cấu hình thành công log shipping trên database là một phần hiện có của AlwaysOn AG. Không quan trọng server nào đang làm việc như primary server, log shipping của bạn sẽ in sync.
Lưu ý: Chúng tôi mạnh mẽ khuyên bạn không nên làm bất kỳ thay đổi nào trong production mà không test. Trước khi triển khai giải pháp này trong môi trường production của bạn, hãy triển khai cấu hình này trong môi trường test trước.
Validation:
a) Đảm bảo backup job chạy thành công trên current primary replica. b) Backup path nên giống với shared path. c) Copy và restore job, được tạo trong cấu hình LS từ HEAD2 đến HEAD3 nên chạy đúng trên DR server. d) Kiểm tra Transactional Log Shipping Status trong phần standard report.
Kết luận
Cấu hình log shipping trên database high availability cho phép bạn có DR server được thiết lập ở data center khác. Thiết lập này chứng minh hữu ích trong trường hợp thảm họa và giữ cho kinh doanh của bạn không bị ảnh hưởng trong khi yêu cầu nỗ lực thủ công tối thiểu ngay cả khi server ở data center khác bị ảnh hưởng.
Sử dụng tab Feedback để đưa ra bình luận hoặc đặt câu hỏi.
Tối ưu môi trường của bạn với quản trị, quản lý và cấu hình chuyên nghiệp
Các chuyên gia Dịch vụ ứng dụng của Rackspace (RAS) cung cấp các dịch vụ chuyên nghiệp và được quản lý sau đây trên danh mục ứng dụng rộng:
- Nền tảng eCommerce và Trải nghiệm số
- Quản trị nguồn lực doanh nghiệp (ERP)
- Business Intelligence
- Salesforce Quản trị quan hệ khách hàng (CRM)
- Databases
- Lưu trữ Email và Năng suất
Chúng tôi cung cấp:
- Chuyên môn khách quan: Chúng tôi đơn giản hóa và hướng dẫn hành trình hiện đại hóa của bạn, tập trung vào các khả năng mang lại giá trị ngay lập tức.
- Fanatical Experience™: Chúng tôi kết hợp phương pháp Process first. Technology second.® với hỗ trợ kỹ thuật chuyên dụng để cung cấp giải pháp toàn diện.
- Danh mục không đối thủ: Chúng tôi áp dụng kinh nghiệm đám mây rộng lớn để giúp bạn chọn và triển khai công nghệ phù hợp trên đám mây phù hợp.
- Giao hàng Agile: Chúng tôi gặp gỡ bạn ở bất kỳ đâu trong hành trình của bạn và điều chỉnh thành công của chúng tôi với của bạn.
Chat ngay để bắt đầu.