Sao chép SQL Server để sao chép trang web

Chúng tôi có máy chủ SQL chính trong nhà (15 máy chủ chính tại thời điểm hiện tại (500 cơ sở dữ liệu tổng thể), hầu hết các máy chủ đều có bộ xử lý lõi hex).

Chúng được nhân đôi cho các máy chủ dự phòng khác trong một tòa nhà gần kề (thông qua liên kết sợi 0ms chuyên dụng).

Những gì chúng tôi muốn làm là duy trì một bản sao dữ liệu trực tiếp của chúng tôi trong một trung tâm dữ liệu ngoài địa điểm cách xa (như một phần của dự án DR lớn hơn nhiều - tức là nếu có vấn đề về giao thông trong khu vực của chúng tôi).

Hiện tại chúng tôi sử dụng SQL Server 2008 R2 - Phiên bản tiêu chuẩn.

Rõ ràng việc sử dụng "Phiên bản tiêu chuẩn" của SQL Server 2008 R2 giới hạn chúng tôi trong việc phản chiếu đồng bộ vì không đồng bộ là một tính năng "Phiên bản doanh nghiệp".

Chúng tôi đã thực hiện thử nghiệm với phản chiếu đồng bộ ngoại vi nhưng độ trễ chỉ khiến nó không hoạt động.

Tôi muốn nâng cấp lên SQL Server 2012 Enterprise và triển khai các nhóm khả dụng Luôn sẵn sàng, nhưng công ty không sẵn sàng chi 100.000 bảng + để nâng cấp giấy phép SQL (cấp phép 2012 cho mỗi lõi + bộ xử lý lõi hex của chúng tôi = thất bại sử thi) - họ thậm chí không sẵn sàng chi tiền để nâng cấp lên Doanh nghiệp 2008, do đó, điều đó cũng không đồng bộ ngoài cửa sổ.

Vì vậy, với đôi tay bị trói buộc bởi những hạn chế tài chính này, tôi bị mắc kẹt với phiên bản 2008 R2 Standard.

Các tùy chọn duy nhất còn mở cho tôi là vận chuyển và sao chép nhật ký (sửa tôi nếu tôi bỏ lỡ bất cứ điều gì) - Log Shipping rất thô sơ - nhưng khi được quản lý đúng cách có thể khả thi - vì vậy chúng tôi đã có được điều đó ngay bây giờ.

Những câu hỏi của tôi):

1. SQL Server 2008 R2 Standard có tất cả các tính năng sao chép mà chúng tôi cần thực hiện sao chép ngoài trang web không?
2. Việc sao chép các máy chủ nội bộ sang một trung tâm dữ liệu ngoài địa điểm (độ trễ 20-30ms) có khả thi mà không ảnh hưởng đến hiệu suất trên máy chủ chính theo bất kỳ cách nào (chúng tôi có thể cài đặt Nhà phân phối sao chép trên máy chủ "Nguyên tắc" không?
3. Cho rằng sao chép không phải là một giải pháp sao chép mức cá thể - việc quản lý này có thể hơn 1 DBA có thể xử lý không? (cho rằng tôi đã quản lý 15 máy chủ Nguyên tắc & các đối tác Gương của họ - phải thừa nhận rất nhiều tự động hóa)
4. Có thể sao chép từ chính của chúng tôi mà không ảnh hưởng đến cấu hình phản chiếu hiện tại - theo tôi hiểu rằng cách tốt nhất là phản chiếu Người đăng ký trái ngược với Nhà xuất bản - điều này có đúng không?
5. Có điều gì khác Bản sao Virgins quên rằng bạn cần phải chú ý đến tôi không?

Dựa trên những gì bạn đã mô tả Đăng nhập vận chuyển sẽ là cách để đi. Đăng nhập vận chuyển là trường học cũ, đã thử và đúng.

Bản sao khá mỏng manh, cung cấp số lượng lớn chỗ cho sự thất bại, đặc biệt là khi thêm các bảng mới và đưa các bảng đó vào cấu trúc liên kết sao chép.

Đối với chi phí nâng cấp năm 2012, chúng có thể không tệ như bạn nghĩ. Nếu bạn có bảo đảm phần mềm và thỏa thuận doanh nghiệp sẽ giúp bạn tiết kiệm rất nhiều tiền khi cấp phép.

Nhật ký vận chuyển có thể là "thô" (tôi thích gọi nó là đơn giản), nhưng sao chép là phức tạp và, theo kinh nghiệm của tôi, dễ vỡ. Bạn không muốn thêm phức tạp nếu bạn có thể tránh nó. Bạn không muốn phải trải qua một số loại anh hùng để sửa chữa một thiết lập sao chép bị hỏng.

Việc quản lý cấu hình sao chép của tất cả các cơ sở dữ liệu đó sẽ là một vấn đề. Bạn không thể sử dụng các hình thức sao chép sẽ thay đổi các bảng cơ sở dữ liệu, vì tôi nghi ngờ việc thử nghiệm những thay đổi đó trên 500 cơ sở dữ liệu là một dự án rất lớn, nếu không phải là một nghề nghiệp, trong chính nó. Bạn có thể bắt đầu gặp vấn đề về hiệu suất ở phía thuê bao yêu cầu bạn bắt đầu xem xét fillfactor, kế hoạch bảo trì và các biến chứng tương tự khác. Điều gì xảy ra nếu bạn cần chuyển từ các máy chủ chính sang các máy chủ thứ cấp "cục bộ" của mình? Bạn sẽ làm lại tất cả các cấu hình nhân rộng? Đó có thể là một nhiệm vụ lớn. Nếu bạn tự động hóa nó, đó là thời gian dành cho việc tạo và thử nghiệm tự động hóa, và sau đó nó cần được xem xét khi bạn thay đổi 500 cơ sở dữ liệu đó.

Hãy nhớ lại rằng tất cả những gì chúng tôi có cho DR là đăng nhập vận chuyển cho đến SQL Server 2005. Nó không quyến rũ, nhưng nó hoạt động.

TL; DR- Đơn giản hơn. Sử dụng nhật ký vận chuyển.