Đồng bộ hóa cơ sở dữ liệu SQL Server


21

Định nghĩa vấn đề

Người dùng của chúng tôi cần khả năng truy vấn cơ sở dữ liệu hầu hết được cập nhật. Dữ liệu có thể cũ đến 24 giờ và điều đó có thể chấp nhận được. Điều gì sẽ là cách tiếp cận chi phí thấp nhất để có được và giữ một cơ sở dữ liệu thứ hai được cập nhật với một bản sao sản xuất? Có một cách tiếp cận tôi không nghĩ đến?

Khối lượng công việc

Chúng tôi có một ứng dụng bên thứ ba mà chúng tôi sử dụng để theo dõi hoạt động giao dịch chứng khoán. Trong ngày, rất nhiều thay đổi nhỏ xảy ra như một phần của các luồng công việc khác nhau (vâng, giao dịch này là hợp lệ. Không, điều này là đáng ngờ, v.v.). Vào ban đêm, chúng tôi thực hiện các hoạt động dựa trên tập hợp lớn (tải các giao dịch của ngày hôm trước).

Giải pháp và vấn đề hiện tại

Chúng tôi sử dụng các snapshot cơ sở dữ liệu . Lúc 10 giờ tối, chúng tôi thả và tạo lại ảnh chụp. Quá trình xử lý ETL sau đó bắt đầu. Đây rõ ràng là đánh thuế vào đĩa của chúng tôi nhưng cho phép người dùng của chúng tôi có thể truy vấn cơ sở dữ liệu mà không khóa cơ sở dữ liệu (họ sử dụng giao diện người dùng Access). Họ sử dụng nó vào đêm khuya và sáng sớm nên họ sẽ thấy thời gian chết.

Vấn đề với phương pháp này là hai lần. Đầu tiên là trong trường hợp xử lý hàng đêm không thành công và điều đó không phổ biến lắm, chúng tôi có thể khôi phục cơ sở dữ liệu dẫn đến ảnh chụp nhanh bị bỏ. Vấn đề khác là thời gian xử lý của chúng tôi đang trôi qua SLA của chúng tôi. Chúng tôi đang cố gắng giải quyết vấn đề này bằng cách làm việc với nhà cung cấp sau khi đã xác định được các truy vấn kém bằng văn bản và thiếu lập chỉ mục. Ảnh chụp nhanh cơ sở dữ liệu cũng là thủ phạm gây ra sự chậm chạp này bằng chứng là sự khác biệt về tốc độ khi nó xuất hiện so với không --- gây sốc, tôi biết.

Phương pháp tiếp cận được xem xét

Phân cụm

Chúng tôi đã bật phân cụm cơ sở dữ liệu nhưng điều đó không giải quyết được nhu cầu cung cấp dữ liệu và nói chung chỉ làm phức tạp cuộc sống của quản trị viên. Nó đã bị tắt.

Bản sao máy chủ SQL

Chúng tôi bắt đầu xem xét nhân rộng vào tuần trước. Lý thuyết của chúng tôi là chúng tôi có thể có được một danh mục thứ hai đứng lên và đồng bộ hóa với cơ sở dữ liệu sản xuất. Trước khi bắt đầu ETL, chúng tôi sẽ cắt kết nối và chỉ bật lại khi kết thúc quá trình ETL.

Quản trị viên bắt đầu với Bản sao chụp nhanh nhưng anh ta lo ngại rằng phải mất nhiều ngày sử dụng CPU cao để tạo ảnh chụp nhanh cũng như mức tiêu thụ đĩa cần thiết. Ông chỉ ra rằng nó dường như ghi tất cả dữ liệu ra các tệp vật lý trước khi chuyển đến thuê bao để cơ sở dữ liệu .6TB của chúng tôi sẽ tốn 1,8TB chi phí lưu trữ. Ngoài ra, nếu bạn mất nhiều ngày để tạo ra một snap, thì nó sẽ không phù hợp với SLA mong muốn.

Sau khi đọc bài viết hay, có vẻ như Snapshot có thể là cách để khởi tạo người đăng ký nhưng sau đó chúng tôi muốn chuyển sang Sao chép giao dịch để giữ cho nó được đồng bộ hóa sau đó. Tôi giả sử bật / tắt sao chép giao dịch sẽ không bắt buộc tái cấp phép hoàn toàn? Nếu không, chúng tôi sẽ thổi cửa sổ thời gian của chúng tôi

Cơ sở dữ liệu phản chiếu

Cơ sở dữ liệu của chúng tôi ở chế độ phục hồi ĐẦY ĐỦ vì vậy phản chiếu cơ sở dữ liệu là một tùy chọn nhưng tôi thậm chí còn biết ít hơn về nó so với Sao chép. Tôi đã tìm thấy câu trả lời SO chỉ ra "Phản chiếu cơ sở dữ liệu ngăn chặn dữ liệu được truy cập trực tiếp, dữ liệu được nhân đôi chỉ có thể truy cập thông qua ảnh chụp nhanh cơ sở dữ liệu."

Đăng nhập vận chuyển

Nghe có vẻ như vận chuyển gỗ cũng có thể là một lựa chọn nhưng đây là một trong những điều tôi không biết gì về nó. Nó sẽ là một giải pháp chi phí thấp hơn (thực hiện và bảo trì) hơn bất cứ điều gì khác? Dựa trên nhận xét của Remus "Vận chuyển nhật ký cho phép truy cập chỉ đọc vào bản sao, nhưng sẽ ngắt kết nối tất cả người dùng khi áp dụng nhật ký sao lưu tiếp theo nhận được (ví dụ: cứ sau 15-30 phút)." Tôi không chắc thời gian chết đó sẽ chuyển thành bao lâu để có thể khiến người dùng tức giận.

Đồng bộ hóa MS

Tôi chỉ nghe nói về việc sử dụng Sync vào cuối tuần vừa qua và chưa điều tra về nó. Tôi không muốn giới thiệu một công nghệ mới cho một thứ gì đó có khả năng hiển thị cao như vấn đề này nhưng nếu đó là cách tiếp cận tốt nhất, thì hãy là nó.

SSIS

Chúng tôi có rất nhiều SSIS ở đây vì vậy việc tạo ra vài trăm gói SSIS để giữ cho đồng bộ hóa thứ cấp là một lựa chọn cho chúng tôi, mặc dù là một gói xấu xí . Tôi không phải là người thích làm việc này vì đó là rất nhiều chi phí bảo trì mà tôi muốn đội của tôi không đảm nhận.

Ảnh chụp nhanh "ma thuật" SAN

Trước đây, tôi đã nghe nói về quản trị viên của chúng tôi sử dụng một số công nghệ SAN để tạo bản sao lưu tức thời của toàn bộ đĩa. Có lẽ có một số phép thuật EMC có thể được sử dụng để tạo các bản sao của mdf / ldf và sau đó chúng ta có thể tách / đính kèm cơ sở dữ liệu đích.

Sao lưu và khôi phục

Tôi nghĩ rằng chúng tôi thực hiện sao lưu đầy đủ mỗi tuần một lần, phân biệt hàng đêm và theo dõi cứ sau 15 phút. Nếu người dùng có thể sống với thời gian ngừng hoạt động 3-4 giờ để khôi phục hoàn toàn, tôi cho rằng đây có thể là một cách tiếp cận.

Những ràng buộc

Windows 2008 R2, SQL Server 2008 R2 (Phiên bản doanh nghiệp), VMWare v5 Enterprise Edition, bộ lưu trữ EMC SAN với các ổ đĩa được ánh xạ tới các tệp vmdk, sao lưu xử lý commvault và .6TB dữ liệu trong danh mục nguồn. Đây là một ứng dụng của bên thứ ba mà chúng tôi lưu trữ trong nhà. Sửa đổi cấu trúc của họ thường được tán thành. Người dùng không thể truy cập mà không truy vấn cơ sở dữ liệu và từ chối bị ràng buộc bằng cách chủ động xác định các bảng họ theo dõi để thực hiện công việc của họ.

DBA của chúng tôi hoàn toàn là nhà thầu tại thời điểm này. Bộ định thời đầy đủ đã ra khơi và chúng tôi chưa thay thế chúng. Quản trị viên ứng dụng không thành thạo về các vấn đề của SQL Server và chúng tôi có một nhóm quản trị viên Storage / VM có thể giúp / cản trở nỗ lực này. Các nhóm phát triển hiện không tham gia nhưng có thể được tranh thủ dựa trên cách tiếp cận. Vì vậy, một giải pháp đơn giản hơn để thực hiện và duy trì sẽ được ưa thích hơn.

Tôi, tôi ở phía phát triển của hosue vì vậy tôi chỉ có thể đề xuất các phương pháp tiếp cận và không phải đối phó với khía cạnh quản trị. Vì vậy, không có thời gian trong yên quản trị, tôi ngần ngại nói rằng một cách tiếp cận sẽ vượt trội hơn so với phương pháp khác --- tất cả đều trông tuyệt vời theo các bài báo. Tôi hoàn toàn sẵn sàng để chạy bất kỳ hướng nào mà bạn đề nghị bởi vì như tôi thấy, nó sẽ chỉ khiến tôi trở nên có giá trị hơn với tư cách là một chuyên gia DB. Tôi có một chiếc xe cút kít nhưng không có áo choàng holocaust có sẵn .

Câu hỏi liên quan

Chỉnh sửa

Để giải quyết các câu hỏi của @ onpnt

Chấp nhận độ trễ dữ liệu

Người dùng hiện đang xem dữ liệu chậm hơn 24 giờ. Dữ liệu chỉ hiện tại tính đến 2200

Lượng dữ liệu thay đổi trong một phút, giờ và ngày nhất định Không chắc chắn cách định lượng đó. Giờ làm việc, có thể hàng trăm thay đổi mỗi giờ. Xử lý hàng đêm, hàng triệu hàng mỗi ngày làm việc

Kết nối với thứ cấp

Mạng nội bộ, máy chủ ảo riêng biệt và lưu trữ chuyên dụng

Đọc các yêu cầu về ví dụ phụ

Nhóm Windows sẽ có quyền truy cập đọc vào thứ cấp, tất cả các bảng

Thời gian hoạt động của phiên bản thứ cấp

Không có định nghĩa mạnh mẽ về yêu cầu thời gian lên. Người dùng muốn nó luôn có sẵn nhưng họ sẵn sàng trả tiền cho điều đó, có lẽ không quá nhiều. Trên thực tế, tôi muốn nói rằng 23 giờ trong ngày sẽ đủ.

Thay đổi lược đồ hiện có và tất cả các đối tượng

Sửa đổi không thường xuyên, có thể một lần mỗi quý cho các đối tượng bảng. Có thể mỗi tháng một lần cho các đối tượng mã.

Bảo vệ

Không có nhu cầu bảo mật đặc biệt. Các quyền sản xuất sẽ phù hợp với quyền của bản sao. Mặc dù theo tôi nghĩ, chúng tôi có thể thu hồi quyền truy cập đọc của người dùng vào prod và chỉ cho phép họ đọc bản sao ... Mặc dù không phải là một yêu cầu.

@darin eo biển

Quay lại ảnh chụp nhanh có thể là một lựa chọn nhưng tôi nghĩ có một số lý do khiến họ không theo đuổi nó. Tôi sẽ kiểm tra với quản trị viên

@cfradenburg

Giả định của tôi là chúng tôi chỉ sử dụng một trong những cách tiếp cận này nhưng đó là một điểm tốt khi khôi phục sẽ phá vỡ các công nghệ đồng bộ hóa "khác". Họ đang điều tra bằng cách sử dụng ma thuật chụp nhanh EMC. Như quản trị viên đã mô tả, họ sẽ chụp ảnh vào năm 1900 và di chuyển hình ảnh sang khu vực thứ cấp. Điều đó sẽ hoàn thành vào năm 2200 và sau đó họ sẽ thực hiện tách rời và gắn lại cơ sở dữ liệu thứ cấp.

Gói lại

2012-10-29 Chúng tôi đã đánh giá ma thuật chụp nhanh EMC và một số tùy chọn sao chép khác nhưng các DBA quyết định họ có thể tìm ra Mirroring tốt nhất. Nâng cao các câu trả lời vì tất cả đều giúp đỡ và cho tôi nhiều lựa chọn cũng như "bài tập về nhà" để điều tra.


Bạn có thể hoàn nguyên ảnh chụp cơ sở dữ liệu khi có sự cố không? Điều đó sẽ đưa bạn trở lại vị trí của db khi chụp ảnh nhanh. Sau đó, bạn có thể chụp ảnh mới, khắc phục sự cố xử lý của mình và tiếp tục. Vận chuyển nhật ký W / R / T, bạn không nhất thiết phải khôi phục bản sao lưu nhật ký vào bản sao của mình suốt cả ngày, cùng lúc bạn lấy chúng. Bạn có thể để chúng tích tụ, sau đó khôi phục chúng thành một bó. Điều này giảm thiểu sự gián đoạn của người dùng trên bản sao vì bạn có thể chọn thời gian chậm để thực hiện và điều đó có nghĩa là bản sao sẽ không thay đổi cả ngày.
eo biển darin

Nếu bạn cần khôi phục cơ sở dữ liệu định kỳ, bất kỳ phương pháp nào nhanh chóng sẽ cần được khởi tạo lại. Nếu bạn đang khôi phục các bản sao lưu DIFF hoặc LOG, việc khôi phục hoàn toàn sẽ cần phải được thực hiện để đồng bộ lại các DB. Điều tương tự với phản chiếu và tôi không chắc chắn về sao chép. Đặt cược tốt nhất của bạn có thể là để xem EMC có thể làm gì cho bạn. Tôi biết khi tôi nói chuyện với NetApp, họ có một giải pháp sẽ làm những gì bạn đang tìm kiếm nhưng đó là một công cụ bổ sung.
cfradenburg

Câu trả lời:


6

Sửa đổi cấu trúc của họ thường được tán thành

Bản sao có nhiều khả năng ra ngoài và tôi sẽ ném Sync ra trước đó. (từ các thử nghiệm xuyên biên giới cao ngoài đời thực trên Sync Framework)

Nếu 3-4 giờ là độ trễ dữ liệu của bạn ngoại trừ, vận chuyển nhật ký có thể sẽ được đặt cược tốt nhất của bạn ở đây trên một bản sao chỉ đọc. Nhưng có bao nhiêu thay đổi đang xảy ra trong nhật ký? tìm ra điều đó đang theo dõi nó để xem bạn cần đẩy nhanh như thế nào và bao nhiêu.

Nếu bạn không thể đến Mirroring hoặc nâng cấp lên doanh nghiệp 2012, thì đó là một chiến lược hợp lý nếu bạn có thể đi Enterprise nếu không có nó.

SSIS không có nghĩa là chỉ đổ dữ liệu lên nhưng nó có thể làm điều đó. Bạn đang nhìn quá nhiều về các biến đổi tra cứu và nhiệm vụ sẽ tốn kém về thời gian và tài nguyên. Mặc dù, như tôi đã nói, nó có thể làm điều đó.

Thực sự, sẽ có một sự thu hẹp khác nhau của các lựa chọn dựa trên việc trả lời một vài câu hỏi

  • Chấp nhận độ trễ dữ liệu
  • Lượng dữ liệu thay đổi trong một phút, giờ và ngày nhất định Kết nối với thứ cấp
  • Đọc các yêu cầu về ví dụ phụ
  • Thời gian hoạt động của phiên bản thứ cấp
  • Thay đổi lược đồ hiện có và tất cả các đối tượng
  • Bảo vệ

4

Đây sẽ là một trong những điều bạn cần cố gắng cho bản thân để tìm ra thứ tốt nhất. Nhân rộng có thể là khó khăn vì vậy trong khi có thể không có chi phí tiền tệ trực tiếp, sẽ có chi phí quản lý duy trì.

Để mở rộng trên Nhật ký vận chuyển, bạn không cần khôi phục nhật ký cứ sau 15-30 phút. Nếu bạn chọn, bạn có thể làm điều đó cứ sau bốn giờ hoặc mỗi ngày một lần. Một giải pháp tương tự như giải pháp mà tôi đã triển khai là thực hiện sao lưu toàn bộ hàng tuần và khôi phục lại DB báo cáo (có thể mất một lúc và xảy ra vào cuối tuần). Trong tuần, các bản sao lưu khác biệt được thực hiện và chúng được khôi phục vào cơ sở dữ liệu báo cáo hàng đêm. Người dùng cần được khởi động trước khi khôi phục nhưng vì DB báo cáo là một ứng dụng giờ làm việc nên không có vấn đề gì với điều đó. Dữ liệu là một ngày không nên là một vấn đề dựa trên yêu cầu của bạn.

Để sử dụng phản chiếu cơ sở dữ liệu cho việc này, bạn cần phải mua Enterprise để có thể sử dụng ảnh chụp nhanh nếu bạn chưa chạy Enterprise. Nó cũng sẽ không giữ dữ liệu cập nhật 100% kể từ khi ảnh chụp nhanh cần được loại bỏ (có nghĩa là tất cả người dùng cần phải ra ngoài) và sau đó được tạo lại để lấy dữ liệu mới. Tuy nhiên, điều này sẽ mất ít thời gian hơn so với khôi phục nhật ký hoặc phương pháp tôi đã giải thích ở trên.

Nếu nâng cấp lên SQL 2012 là một tùy chọn, có thể thiết lập một thứ cấp chỉ đọc sẽ được cập nhật với cơ sở dữ liệu chính. Tôi chỉ đề cập đến điều này bởi vì nó có thể là giải pháp trơn tru nhất.


4

Nhiều như mọi người rag về sao chép giao dịch, nó có vẻ phù hợp với tình huống của bạn. Một vài lưu ý:

  1. Bạn không cần phải khởi tạo thuê bao bằng một ảnh chụp nhanh. Bạn có thể lấy một bản sao lưu của nhà xuất bản và khởi tạo với nó.
  2. Bạn có thể tạm dừng phân phối lệnh cho người đăng ký chỉ bằng cách dừng công việc phân phối (đó chỉ là công việc Đại lý SQL thông thường tại nhà phân phối hoặc thuê bao tùy thuộc vào việc bạn thiết lập công việc đó như đăng ký đẩy hay kéo tương ứng). Chỉ cần lưu ý đến việc bạn giữ nhà phân phối sao cho bạn giữ đủ lịch sử xung quanh để bạn có thể bắt kịp.
  3. Bạn có thể thay đổi lập chỉ mục tại thuê bao để phù hợp với khối lượng công việc sẽ được thực hiện ở đó (có lẽ là loại báo cáo) thay vì phải chấp nhận lập chỉ mục từ nhà xuất bản của bạn (có lẽ là loại OLTP) nếu bạn muốn.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.