Lập kế hoạch và triển khai một kế hoạch phục hồi sau thảm họa và có tính khả dụng cao đáp ứng tất cả các thỏa thuận cấp dịch vụ là một công việc không hề nhỏ và đòi hỏi bạn phải hiểu rất rõ về các điểm mạnh và điểm yếu cơ bản của SQL Server. Khi so khớp các yêu cầu với sự kết hợp của các tính năng, một số chi tiết quan trọng có thể bị đánh bóng và trong bài đăng này, tôi sẽ giới thiệu cho các bạn một số biến dạng phổ biến và các giả định xấu có thể đi vào giải pháp - cuối cùng khiến chúng ta bỏ lỡ dấu hiệu về điểm khôi phục và mục tiêu thời gian phục hồi của chúng tôi. Một số ví dụ về sự xuyên tạc hoặc tự huyễn hoặc bản thân mà tôi nêu chi tiết ở đây có thể được khái quát qua các tính năng khác nhau và một số là đặc điểm cụ thể.
"Chúng tôi đã thử nghiệm kế hoạch khắc phục thảm họa khi chúng tôi khởi chạy dự án lần đầu tiên và chúng tôi biết rằng nó sẽ hoạt động"
Tôi đã làm việc với những khách hàng thực sự có cách tiếp cận khắc phục thảm họa “đúng” - một lần. Nhưng một khi mọi người cảm thấy tin tưởng vào hiệu quả của giải pháp, thì không có bài tập khắc phục thảm họa nào khác được thực hiện trở lại. Tất nhiên - trong khi đó, cấp dữ liệu và ứng dụng liên tục thay đổi theo thời gian. Những thay đổi đó giới thiệu các đối tượng và quy trình mới quan trọng đối với ứng dụng. Và ngay cả khi mọi thứ vẫn ổn định sau khi ra mắt, bạn vẫn phải tính đến sự luân chuyển nhân sự và các bộ kỹ năng khác nhau. Nhân viên của ngày hôm nay có thể thực hiện thành công bài tập khắc phục thảm họa không? Và ngay cả những nhân viên giỏi nhất cũng cần thực hành liên tục.
"Chúng tôi sẽ không bị mất dữ liệu vì chúng tôi đang sử dụng phản chiếu cơ sở dữ liệu đồng bộ"
Giả sử bạn đang sử dụng sao chép cơ sở dữ liệu đồng bộ giữa hai phiên bản SQL Server, với mỗi phiên bản trong một trung tâm dữ liệu riêng biệt. Trong ví dụ này, giả sử rằng độ trễ giao dịch có thể chấp nhận được mặc dù đây là một phiên phản chiếu cơ sở dữ liệu đồng bộ với một vài dặm giữa các trung tâm dữ liệu. Bạn không có nhân chứng trong hỗn hợp vì bạn muốn kiểm soát chuyển đổi dự phòng cơ sở dữ liệu nhân bản theo cách thủ công.
Bây giờ, giả sử trung tâm dữ liệu khôi phục sau thảm họa của bạn ngừng hoạt động - nhưng trung tâm dữ liệu chính của bạn vẫn hoạt động. Cơ sở dữ liệu chính của bạn bị ngắt kết nối với cơ sở dữ liệu nhân bản, nhưng nó vẫn đang chấp nhận các kết nối và sửa đổi dữ liệu. Còn yêu cầu “không mất dữ liệu” bây giờ thì sao? Nếu các giao dịch chạy ngược lại số tiền gốc bị ngắt kết nối trong một giờ nữa, kế hoạch của bạn là gì nếu trung tâm dữ liệu chính cũng bị mất?
"Chủ doanh nghiệp của chúng tôi cho biết chúng tôi có thể mất tới 12 giờ dữ liệu"
Điều quan trọng là đặt một số câu hỏi nhiều lần và cho nhiều cá nhân trong tổ chức. Nếu ai đó nói với bạn rằng "12 giờ mất dữ liệu là có thể chấp nhận được" - hãy hỏi lại họ hoặc hỏi họ hậu quả của việc mất dữ liệu đó sẽ như thế nào. Hãy hỏi những người khác. Họ có thể đưa ra cho bạn một yêu cầu khắt khe hơn nhiều. Tôi nhận thấy rằng các mục tiêu về điểm khôi phục đòi hỏi một số thương lượng và hơn một vài cuộc thảo luận cân nhắc, kỹ lưỡng.
"Chúng tôi đang sử dụng [nhóm phản chiếu cơ sở dữ liệu hoặc nhóm khả dụng] và vì vậy, chúng tôi sẽ được đáp ứng những gì chúng tôi cần trong trường hợp xảy ra thảm họa"
Các nhóm khả dụng và nhân bản cơ sở dữ liệu chắc chắn có thể được sử dụng để bảo vệ bạn ở cấp cơ sở dữ liệu, nhưng mọi thứ khác thì sao? Còn về thông tin đăng nhập của bạn? Các gói SSIS? Việc làm? Cơ sở dữ liệu mô hình khôi phục không ĐẦY ĐỦ? Máy chủ được liên kết?
"Chúng tôi đang sử dụng tính năng XYZ của SQL Server, vì vậy chúng tôi sẽ không mất bất kỳ giao dịch trên chuyến bay nào"
Không, xin lỗi. Mặc dù một số tính năng cho phép chuyển hướng minh bạch, nhưng điều này không giống như việc giữ lại và duy trì các giao dịch đang mở tại thời điểm chuyển đổi dự phòng. Không có tính năng SQL Server nào cung cấp chức năng này ngày hôm nay.
"Nhóm hỗ trợ cấp dữ liệu cho ứng dụng này ghét tính năng XYZ của Máy chủ SQL, nhưng chúng tôi đang tiếp tục sử dụng tính năng này vì đó là điều mà chuyên gia tư vấn bên ngoài đề xuất cho chúng tôi"
Mặc dù sẽ rất tuyệt nếu mọi người không phát triển các thành kiến cụ thể về các tính năng trong SQL Server, nhưng trường hợp này thường không xảy ra. Nếu bạn cố gắng áp dụng các giải pháp cho một nhân viên không có trong tay họ, bạn sẽ có nguy cơ thất bại được xác định trước. Là một phần của các bài tập HA / DR mà tôi đã thực hiện trước đây, tôi luôn muốn nghe về những trải nghiệm trong quá khứ của mọi người với các tính năng cụ thể. Ví dụ:một số công ty tận dụng hàng trăm Phiên bản cụm chuyển đổi dự phòng rất tốt - trong khi những công ty khác tránh chúng vì trải nghiệm xấu từ các phiên bản trước. Khi lập kế hoạch giải pháp, bạn không thể bỏ qua lịch sử hoặc khuynh hướng của nhân viên, những người cuối cùng sẽ chịu trách nhiệm triển khai và hỗ trợ giải pháp được đề xuất.
"Với tư cách là DBA, tôi quyết định sử dụng công nghệ HA / DR nào cho cấp dữ liệu, vì vậy chúng tôi sẽ sử dụng các nhóm khả dụng trong tương lai"
Một quản trị viên cơ sở dữ liệu có thể có khả năng thiết lập phản chiếu cơ sở dữ liệu mà ít hoặc không có sự tham gia của các nhóm khác. Bây giờ với các nhóm khả dụng, ngay cả khi người quản trị cơ sở dữ liệu có thể tự mình làm tất cả, họ có thể không khôn ngoan khi làm như vậy. Xét cho cùng - nếu bạn đang triển khai các nhóm khả dụng cho mục đích khôi phục sau thảm họa, bạn sẽ muốn mọi người tham gia vào hoạt động khôi phục sau thảm họa nhận thức được giải pháp của bạn và các yêu cầu cần thiết để trực tuyến trở lại và khôi phục dữ liệu thành công. Với các nhóm khả dụng, bạn sẽ cần suy nghĩ về Cụm chuyển đổi dự phòng Windows Server, cấu hình túc số, phiếu bầu của nút, trình nghe nhóm khả dụng và hơn thế nữa. Nếu bạn cần người khác hỗ trợ một giải pháp, hãy đảm bảo rằng họ tham gia vào đề xuất ban đầu.
"Chúng tôi đang sử dụng các nhóm khả dụng để chúng tôi có thể có tính khả dụng chỉ đọc trong trường hợp hết bản sao đọc-ghi của chúng tôi"
Đây chỉ là một ví dụ về kịch bản “điều gì xảy ra nếu”. Với bất kỳ việc triển khai chức năng nào, bạn sẽ muốn hình dung các cách khác nhau mà lỗi có thể xảy ra - và sau đó nhớ kiểm tra nó để đảm bảo các yêu cầu của bạn vẫn được đáp ứng. Ví dụ - nếu bạn nghĩ rằng bản sao chỉ đọc không đồng bộ trong nhóm khả dụng SQL Server 2012 của bạn sẽ khả dụng khi bản sao chỉ đọc-ghi không khả dụng, bạn sẽ ngạc nhiên khi thấy Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections thông điệp trong quá trình sản xuất.
"Chúng tôi đã thử nghiệm tính năng XYZ của SQL Server và chuyển đổi dự phòng diễn ra nhanh chóng, vì vậy chúng tôi đã xác định rằng chúng tôi có thể đáp ứng các mục tiêu thời gian khôi phục một cách dễ dàng"
Giả sử bạn quyết định sử dụng phản chiếu cơ sở dữ liệu để có tính khả dụng cao ở cấp độ cơ sở dữ liệu người dùng. Bạn muốn chuyển đổi dự phòng nhanh chóng (tính bằng giây) và bạn thực sự thấy chuyển đổi dự phòng nhanh chóng trong quá trình thử nghiệm. Nhưng đó có phải là một thử nghiệm thực tế? Bạn có đang đẩy một khối lượng công việc đáng kể không? Trong ví dụ về phản chiếu cơ sở dữ liệu, phần dài nhất của hoạt động chuyển đổi dự phòng của bạn có thể dành cho các hoạt động làm lại. Nếu bạn không thúc đẩy khối lượng công việc thực tế, thì bạn không thể thực sự nói rằng chuyển đổi dự phòng của bạn thực sự sẽ "nhanh".
"Nếu chúng tôi gặp thảm họa và cần cứu vãn và điều chỉnh dữ liệu, chúng tôi sẽ tìm ra khi đến thời điểm"
Đây là một trong những khó khăn. Giả sử bạn gặp sự cố và cần phải đưa trung tâm dữ liệu phụ của mình vào hoạt động. Bạn quyết định bắt buộc cung cấp dịch vụ cho các cơ sở dữ liệu quan trọng nhất trong trung tâm dữ liệu thứ cấp và giờ đây bạn có sự phân chia trong dòng sửa đổi dữ liệu (một số hàng chưa được cấu trúc trong trung tâm dữ liệu chính và bây giờ là các sửa đổi mới trong trung tâm dữ liệu thứ cấp). Cuối cùng thì trung tâm dữ liệu chính của bạn cũng được đưa lên mạng - nhưng bây giờ bạn có dữ liệu cần được thu hồi và đối chiếu trước khi bạn có thể thiết lập lại giải pháp HA / DR tổng thể. Công việc của bạn là gì? Bạn có thể làm gì? Cuộc thảo luận này hiếm khi là một cuộc thảo luận dễ dàng và có thể phụ thuộc vào một số yếu tố như gói phần mềm bạn đã mua, độ phức tạp của cấp dữ liệu và các công cụ hội tụ dữ liệu theo ý của bạn. Trên thực tế, cuộc thảo luận thường khó đến nỗi mọi người hoàn toàn không có. Nhưng nếu dữ liệu đủ quan trọng để bạn thiết lập trung tâm dữ liệu thứ cấp, thì phần quan trọng của cuộc thảo luận phải bao gồm cách tốt nhất để cứu dữ liệu và cũng có thể điều chỉnh nó sau khi thảm họa xảy ra.
Tóm tắt
Bài viết này chỉ bao gồm một số ví dụ về cách chúng ta có thể tự huyễn hoặc bản thân khi nghĩ rằng một giải pháp đáp ứng đầy đủ các yêu cầu của họ. Mặc dù bản chất của con người là phải làm điều này - khi nói đến mất dữ liệu và tính liên tục trong kinh doanh, công việc của chúng ta sẽ phụ thuộc vào việc chúng ta quyết liệt hơn trong việc kiểm tra niềm tin và giả định của chính mình.
