Di chuyển cơ sở dữ liệu đến các trung tâm dữ liệu mới


8

Công ty của tôi đang chuyển cơ sở hạ tầng của chúng tôi sang trung tâm dữ liệu mới và tôi đang cố gắng tìm ra cách tốt nhất để giữ cơ sở dữ liệu trên máy chủ mới đồng bộ với cơ sở dữ liệu sản xuất hiện tại cho đến khi môi trường mới sẵn sàng hoạt động. Không phải là một DBA toàn thời gian, tôi đã thực hiện một số nghiên cứu và từ những gì tôi đã đọc, có vẻ như một thiết lập sao chép xuyên quốc gia sẽ đáp ứng tốt nhất nhu cầu của chúng tôi.

Một số chi tiết: DB sản xuất có kích thước khoảng 90 GB và sử dụng Robocopy, mất khoảng 9 giờ để chuyển một bản sao của nó sang một trong các máy chủ mới. Cơ sở dữ liệu sản xuất hiện tại sẽ cần duy trì trực tuyến và có thể truy cập trong toàn bộ quá trình di chuyển. Đó là trong phục hồi đơn giản, vì vậy phản ánh cơ sở dữ liệu là không có sẵn.

Là một bản sao giao dịch là phương pháp tốt nhất để giữ cho cơ sở dữ liệu đồng bộ?

Kế hoạch của tôi:

  1. (Xong) Chuyển cơ sở dữ liệu hiện tại và đăng nhập vào máy chủ mới và đính kèm với cơ sở dữ liệu mới của SQL Server
  2. Thiết lập một nhà phân phối trên máy cơ sở dữ liệu phát triển của chúng tôi và xuất bản cho nó từ cơ sở dữ liệu sản xuất
  3. Tạo một thuê bao trên máy cơ sở dữ liệu mới sẽ chấp nhận các cập nhật được đẩy ra từ nhà phân phối, mỗi đêm một lần

Có hai điều trong tâm trí của tôi. Sao chép giao dịch yêu cầu mỗi bảng được xuất bản có một khóa chính và rất nhiều bảng trong cơ sở dữ liệu sản xuất không có các khóa chính được xác định. Tôi không nghĩ rằng đây sẽ là một vấn đề quá lớn vì mối quan tâm chính của tôi chỉ là đồng bộ hóa cơ sở dữ liệu. Chúng tôi sẽ kiểm tra các ứng dụng khác nhau mà cơ sở dữ liệu sử dụng ở dữ liệu sau này, nhưng tôi muốn chắc chắn rằng đó không phải là vấn đề nghiêm trọng. Thứ hai, tôi cũng cần di chuyển bất kỳ DB hệ thống liên quan nào từ phiên bản gốc, chẳng hạn như master? Chúng tôi đang chuyển sang thiết lập Active Directory trong môi trường mới, vì vậy tôi không quan tâm đến người dùng và như vậy, nhưng tôi không chắc về sự cần thiết của DB hệ thống.

Và nói chung, tôi có nắm bắt chính xác các khái niệm này không?

Câu trả lời:


9

Tình hình hiện tại của bạn:

  • Cơ sở dữ liệu 90 GB mà bạn muốn chuyển đến một trung tâm dữ liệu mới.
  • Cơ sở dữ liệu đang trong phục hồi đơn giản.
  • Bạn đang nghĩ đến việc sử dụng T-Rep để giữ dữ liệu đồng bộ.
  • Có nhiều bảng trong cơ sở dữ liệu không có Khóa chính - đây là yêu cầu cho bất kỳ bảng nào được xuất bản.
  • Bạn đã có một bản sao lưu được sao chép vào trung tâm dữ liệu đích.

Tôi thấy nhiều nhược điểm trong cách tiếp cận của bạn:

  • T-Rep không dễ cài đặt so với các công nghệ khác. Nếu có bất kỳ thay đổi lược đồ nào thì nó yêu cầu một ảnh chụp nhanh mới.
  • Nếu bạn đang sử dụng T-REP thì bạn phải thay đổi lược đồ - thêm Khóa chính vào các bảng không có.
  • Thực hiện bất kỳ thay đổi nào đối với cơ sở dữ liệu hiện tại của bạn, ứng dụng của bạn phải được kiểm tra đầy đủ để tránh mọi hành vi không mong muốn.
  • Nếu cơ sở dữ liệu của bạn có số lượng giao dịch lớn và tùy thuộc vào băng thông mạng giữa 2 trung tâm dữ liệu, thì cũng sẽ có độ trễ sao chép.

Dựa trên kinh nghiệm của tôi, dưới đây là khuyến nghị của tôi:

  • Thay đổi cơ sở dữ liệu của bạn để phục hồi đầy đủ. Đây không phải là một tác động lớn so với việc tạo PK.
  • Gửi bản sao lưu đầy đủ của cơ sở dữ liệu nguồn - thực hiện sao lưu với nén và cho phép khởi tạo tệp ngay lập tức. Điều này sẽ giúp bạn giảm thời gian khôi phục trên trung tâm dữ liệu đích.
  • Khôi phục cơ sở dữ liệu trên máy chủ đích WITH NORECOVERY.
  • Thực hiện Logshipping và khởi tạo nó từ bản sao lưu.
  • Có logshipping gửi nhật ký cứ sau 1 phút.
  • Trong ngày chuyển đổi dự phòng, hãy thực hiện sao lưu nhật ký đuôi cuối cùng trên nguồn và khôi phục nó trên đích bằng cách sử dụng WITH RECOVERY. Điều này sẽ mang lại cơ sở dữ liệu đích trực tuyến.
  • Khi cơ sở dữ liệu đích trực tuyến, bạn phải đồng bộ hóa người dùng .
  • Bạn nên thay đổi web.config để trỏ nó đến máy chủ mới.

Bạn không phải di chuyển bất kỳ cơ sở dữ liệu hệ thống. Hãy chắc chắn rằng bạn thực hiện tất cả các công việc chuẩn bị trước khi ra tay đăng nhập, công việc, gói ssis, v.v. và tạo chúng trên máy chủ đích.

Tham khảo câu trả lời này cho các bước khôi phục bài và các thực hành tốt nhất khác .

Lưu ý: Bạn cũng có thể triển khai phản chiếu cơ sở dữ liệu (SYNC hoặc ASYNC tùy thuộc vào phiên bản máy chủ sql bạn đang sử dụng), nhưng logshipping chỉ đơn giản để thực hiện và nếu bạn kiểm tra nó, nó sẽ không làm bạn thất vọng. Tôi đã chuyển thành công cơ sở dữ liệu terabyte từ trung tâm dữ liệu này sang cơ sở dữ liệu khác bằng kỹ thuật trên và nó hoạt động hoàn toàn tốt.

Cơ sở dữ liệu sản xuất hiện tại sẽ cần duy trì trực tuyến và có thể truy cập trong toàn bộ quá trình di chuyển.

Sẽ luôn có một thời gian chết và bạn phải lên lịch cho nó. Ngay cả khi bạn đầu tư trả số tiền cao trong các giải pháp như phân cụm, khi bạn chuyển đổi dự phòng, sẽ có một số thời gian chết. Bạn phải cân bằng xem công ty của bạn có thể đầu tư bao nhiêu để có thời gian chết gần như bằng không so với thời gian có thể chấp nhận được.


Những gì ông nói. Hãy chắc chắn rằng các bản sao lưu nhật ký đủ thường xuyên để đảm bảo cơ sở dữ liệu hiện tại không lấp đầy đĩa của nó trong khi phục hồi hoàn toàn.
Michael Green

@MichaelGreen Việc lưu giữ nhật ký có thể được điều chỉnh để giải quyết vấn đề làm đầy đĩa.
Kin Shah

@Kin cảm ơn bạn đã trả lời tuyệt vời. Liên quan đến vận chuyển nhật ký, tôi lấy nó trên máy chủ để làm điều này không quá cao?
Snake_Plissken

@Snake_Plissken chi phí không cao .. Nếu bạn có số lượng lớn cơ sở dữ liệu thường xuyên bị logship, bạn có thể thấy một chút tranh cãi trong bảng msdb..sysjobhistory (Tôi đang nói db hơn 100+). Tôi có các máy chủ thực hiện logshipping từ quốc gia này sang quốc gia khác mỗi phút chạy hơn 50 cơ sở dữ liệu mà không gặp sự cố.
Kin Shah

0

Không có cơ hội sử dụng bản thân mình và tôi nghĩ rằng nó vẫn còn trong bản xem trước, nhưng SQL Data Sync trên nền tảng Azure có thể là một tùy chọn tiềm năng:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Nó hoạt động với cơ sở dữ liệu tại cơ sở cũng như Azure SQL và có vẻ như là một công cụ hữu ích để giữ cho cơ sở dữ liệu được đồng bộ hóa.


Đồng bộ hóa dữ liệu SQL đã được xem trước từ nhiều năm (hơn 4 năm nếu tôi nhớ chính xác). Nó rất có lỗi. Không có đăng nhập thích hợp và thất bại ngẫu nhiên mà không cung cấp cho bạn bất kỳ chi tiết. Tôi đã thử dùng nó làm bằng chứng khái niệm và quyết định không sử dụng nó và đi với SSIS để tải dữ liệu từ tiền đề vào Azure. Để thoát khỏi đồng bộ hóa dữ liệu, MS hiện đã T-rep từ tiền đề đến Azure trong bản xem trước mà tôi sẽ thử sớm!
Kin Shah

Đó là một sự xấu hổ khi nhìn từ bản demo tôi thấy khá hứa hẹn, ồ ...
steoleary
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.