Làm thế nào để giữ cho cơ sở dữ liệu nhà phát triển ngoài trang web được cập nhật với sản xuất?


7

Chúng tôi có một cơ sở dữ liệu sản xuất chạy trên SQL Server 2008 R2 với các tệp được lưu trữ trong đó. Chúng tôi lo ngại về kích thước của cơ sở dữ liệu vì vậy chúng tôi đã chọn bật FILESTREAM để các tệp sẽ được lưu trữ trên đĩa và chúng tôi hy vọng có thể giảm kích thước của các bản sao lưu. Tôi đã thấy rằng chúng tôi có thể loại trừ filegREAM filege khỏi các bản sao lưu nhưng sau đó chúng tôi gặp vấn đề khi truy vấn các bảng đó khi khôi phục (vì các trường bị thiếu dữ liệu, dự kiến). Suy nghĩ tiếp theo của chúng tôi là có thể đồng bộ hóa các tệp từ đĩa bằng FTP hoặc dropbox tự động hoặc một cái gì đó có tính chất đó. Tôi chưa hoàn toàn khám phá điều này mặc dù.

Vấn đề thực sự mà chúng tôi đang cố gắng giải quyết ở đây là giữ cho các nhà phát triển của chúng tôi cập nhật với cơ sở dữ liệu sản xuất. Với quy mô ngày càng tăng của cơ sở dữ liệu của chúng tôi, việc sao lưu toàn bộ và tải xuống cơ sở dữ liệu ngày càng trở nên khó khăn hơn và cuối cùng nó sẽ trở nên cấm đoán. Tôi đang tự hỏi những người khác đang làm gì để giữ cho các nhà phát triển từ xa cập nhật.

Tôi đã xem nhanh việc vận chuyển nhật ký của SQL Server nhưng có vẻ như nó sẽ yêu cầu rất nhiều tự động hóa tùy chỉnh (lên lịch FTP và khôi phục tập lệnh) để làm cho nó hoạt động đáng tin cậy với một vài nhà phát triển ở các vị trí địa lý khác nhau và tôi không chắc chắn làm thế nào để sử dụng cơ sở dữ liệu thứ cấp để phát triển vì nó có thể chỉ đọc. Tôi cởi mở với bất kỳ đề xuất nào và vui lòng cho tôi biết nếu tôi có thể cung cấp thêm thông tin về tình huống của chúng tôi sẽ giúp đưa ra các đề xuất.

CẬP NHẬT: Các nhà phát triển chỉ cần một bản sao hợp lý hiện tại của dữ liệu sản xuất. Điều này giúp tái tạo các vấn đề để chúng có thể được giải quyết. Chúng tôi ổn với dữ liệu hơi cũ nhưng việc giữ thời gian chuyển ở mức tối thiểu sẽ đề xuất sao lưu thường xuyên.

Cảm ơn các đề xuất cho đến nay, chỉ cần thêm một chút cơ sở dữ liệu của chúng tôi hiện là 12 GB hoặc hơn và chúng tôi hy vọng sẽ tăng gấp đôi trong tương lai gần với việc ký thêm khách hàng. Tôi đã chạy một vài bản sao lưu thử nghiệm với tính năng nén được kích hoạt và điều đó đã giúp chúng tôi tiết kiệm khoảng 1-2 GB nhưng tôi nghĩ rằng vì phần lớn số lượng lớn là các tệp được lưu trữ (hiện tại trong FILESTREAM) mà chúng tôi sẽ không giảm mạnh. hy vọng (mặc dù có lẽ chúng ta vẫn sẽ nén để tiết kiệm không gian chúng ta có thể). Tôi nghĩ rằng chúng tôi muốn có thể khôi phục các bản sao cục bộ một hoặc hai lần một tuần chỉ để theo dõi mọi thứ. Tôi không chắc chắn chính xác giới hạn băng thông của chúng tôi là gì từ máy chủ được lưu trữ của chúng tôi nhưng có vẻ như nhiều người tải xuống các tệp 20GB vài lần một tháng sẽ không sử dụng tốt bất kỳ băng thông nào chúng tôi có. Tôi không


1
Tại sao bạn cần phải cung cấp cho mỗi nhà phát triển một bản sao chính xác của sản xuất?

1
Tôi đã thêm một bản cập nhật ở trên. Các bản sao địa phương giúp gỡ lỗi các vấn đề xảy ra.

Phát triển / QAing / Dàn dựng chống lại prod là một thực tiễn phát triển thực sự tốt, tôi khen bạn đã thực hiện bước này. 1 câu hỏi của bạn.
Ali Razeghi

không có thông tin nhạy cảm trong cơ sở dữ liệu sản xuất?
Neil McGuigan

@NeilMcGuigan trong khi chúng tôi thực sự không có bất kỳ dữ liệu nhạy cảm nào là điểm tốt và tôi nghĩ chúng tôi sẽ sử dụng SFTP hoặc một cái gì đó nếu chúng tôi đi theo lộ trình vận chuyển nhật ký. Cảm ơn vì đã mang mà lên.
Brent Keller

Câu trả lời:


2

Tôi nghĩ rằng việc cung cấp bản sao cơ sở dữ liệu đầy đủ không phải là một ý tưởng tốt vì điều này sẽ trở nên đau đớn khi cơ sở dữ liệu phát triển. Chúng tôi có cùng thiết lập nhưng không có tùy chọn filestream. Chúng tôi sử dụng powershell để tạo các kịch bản lược đồ db và gửi nó cho các nhà phát triển mỗi đêm. Nhà phát triển sử dụng tập lệnh đó để tạo vỏ DB trên máy riêng của họ (Chúng tôi có các dev db riêng biệt với dữ liệu mà họ có thể sử dụng để truy vấn và tải dữ liệu cụ thể cho ứng dụng của họ). Shell db này được sử dụng để phát triển và kiểm tra mã db đơn vị bằng SSDT. Để gỡ lỗi các vấn đề trực tiếp, chúng tôi đã sao chép log db trực tiếp trên máy chủ dự phòng, phần lớn chỉ chậm 10 phút. Chúng tôi hầu như không có bất kỳ vấn đề nào với thiết lập này nhưng tất cả phụ thuộc vào từng kịch bản. chúc may mắn


Chúng tôi đã duy trì lược đồ của chúng tôi một cách tự động. Có một bản sao gỡ lỗi của cơ sở dữ liệu prod là một ý tưởng thú vị có thể phục vụ chúng ta đủ tốt. Chúng tôi có thể vẫn kéo xuống các bản sao lưu định kỳ nhưng đây có thể là một cách tiếp cận tốt cho chúng tôi nếu việc vận chuyển gỗ trở nên rắc rối.
Brent Keller

Chúng tôi cuối cùng chỉ sử dụng một bản sao của prod db trên máy chủ và kết nối môi trường dev của chúng tôi với điều đó khi chúng tôi cần gỡ lỗi một cái gì đó mà chúng tôi không thể sao chép cục bộ.
Brent Keller

4

Tôi quản lý môi trường DB cho một số công ty viễn thông cấp 1 và dữ liệu / môi trường của chúng tôi được phân phối trên toàn thế giới, có nhiều cách bạn có thể đạt được những gì bạn đang tìm kiếm nhưng nó phụ thuộc vào điểm đau của bạn.

Câu hỏi :

- Các cơ sở dữ liệu lớn đến mức nào, các nút bao xa (hoặc quan trọng hơn là độ trễ giữa chúng là bao nhiêu) và bạn có bao nhiêu băng thông?

-Bạn tạo ra bao nhiêu hoạt động nhật ký giao dịch?

-Làm thế nào để bạn muốn khôi phục?

-Bạn có cho phép nén dữ liệu trên các bản sao lưu không?

Một số bài học kinh nghiệm

-Một điều tôi nhận thấy với việc sao chép dữ liệu trên toàn thế giới là giao thức Windows CIFS hoàn toàn hút khi thực hiện việc này. Nó rất kém hiệu quả.

Chúng tôi đã kết thúc bằng cách sử dụng HTTPS và đưa ra yêu cầu GET. Đó là sao lưu nhanh hơn gấp 10 lần sao lưu từ châu Á đến Los Angeles.

Sử dụng các tùy chọn Đa luồng trong Robocopy hoặc các chương trình sao chép khác rất hữu ích nếu bạn chia nhỏ bản sao lưu thành nhiều tệp.

Một số tùy chọn:

2 giải pháp Linux đáng ngạc nhiên

  • Một giải pháp tôi thực sự thích là RSYNC với các máy chủ Linux ở mỗi đầu và gắn thư mục sao lưu. Điều này thực sự tốt khi các bản sao lưu được tự động đồng bộ hóa bằng giao thức hiệu quả cho các mạng WAN. Nếu bạn không muốn đồng bộ TẤT CẢ các bản sao lưu của mình, hãy gắn một ổ đĩa khác trên máy chủ linux thực sự gắn vào một cửa sổ chia sẻ mà bạn sẽ đặt các bản sao lưu vào. RSYNC sẽ chăm sóc nó từ đó và thực hiện nhanh hơn CIFS . Các giao thức Linux tốt hơn nhiều cho việc sao chép tệp đường dài so với Windows CIFS dựa trên kinh nghiệm của tôi. Tôi đã nói chuyện với một số CCIE và họ cũng nói như vậy.

  • Bạn cũng có thể xem Trình tối ưu hóa mạng VM VM (Trình tối ưu hóa mạng WAN của Google hoặc 'Bing' hoặc cụ thể hơn, ví dụ: Trình tối ưu hóa mạng băng thông cao có độ trễ cao hoặc băng thông cao có độ trễ thấp, bất kể môi trường của bạn là gì)

Nhật ký giao dịch SQL Vận chuyển bằng FTP không đáng sợ chút nào. Tôi đã có một nhà phát triển .Net giúp nó chạy nhanh, mặc dù tôi rất ấn tượng và được anh ta thuê ở một công ty khác mà tôi làm việc. Vấn đề là bạn có thể gửi nhiều dữ liệu hơn trong khoảng thời gian 24 giờ nếu có rất nhiều CẬP NHẬT nhưng không được bảo vệ bằng cách sử dụng nhật ký vận chuyển, thay vì chỉ sao lưu các bản sao lưu.

Sao chép cấp độ khối hệ thống tệp SAN : Không chắc bạn có phần cứng hỗ trợ việc này không, nhưng nhiều SAN tầm trung cho phép bạn sao chép dữ liệu trực tiếp sang các dữ liệu khác. Nếu là của bạn, đây là một tùy chọn tuyệt vời vì nó có 0 máy chủ trên không, trừ khi đường ống mạng của bạn bị giới hạn trong trường hợp bạn gặp vấn đề khác.

Sao chép giao dịch vào cơ sở dữ liệu trung tâm : Bạn có thể tạo sơ đồ sao chép trong đó bạn có bản sao dữ liệu cập nhật. Sau đó, bạn có thể lấy bản sao lưu của mình từ bản sao đó để không phải sao chép toàn bộ bản sao lưu trên toàn bộ dây.

Hãy cho chúng tôi biết một số điểm đau của bạn và chúng tôi có thể đi qua các lựa chọn khác.

Ngoài ra hãy chắc chắn đọc MS giấy trắng tuyệt vời này nếu bạn đi với bản sao:

Hiệu suất tái tạo địa lý đạt được với Microsoft SQL Server 2008 Chạy trên Windows Server 2008


Cảm ơn đã đặt ra tất cả các tùy chọn này. Chúng tôi không có SAN để tùy chọn sao chép không có trên bàn. Ngay bây giờ tôi nghĩ rằng tôi đang xem xét việc cung cấp dịch vụ vận chuyển nhật ký có sẵn và viết một số tập lệnh để nhà phát triển lấy bất kỳ nhật ký nào họ không có qua FTP và khôi phục chúng. Điều này là tự động và có thể là nút ấn hoặc theo lịch trình. Bạn có một điểm tốt về nhật ký giao dịch có thể là nhiều dữ liệu hơn các bản sao lưu đầy đủ, vì vậy có thể tự động hóa với các bản sao lưu đầy đủ thực sự là cách tốt nhất. Bất kỳ đề nghị khác đều được chào đón mặc dù.
Brent Keller

Brent, cung cấp cho chúng tôi thêm một số thông tin khi bạn có cơ hội liên quan đến phần câu hỏi của câu trả lời. Chúng tôi sẽ có thể cung cấp cho bạn nhiều trợ giúp hơn có khả năng. Ngoài ra, Sao chép giao dịch SQL không yêu cầu SAN. Chúc may mắn. - Ali Razeghi 1 giờ trước
Ali Razeghi

Ali, tôi đã thêm thông tin ở cuối câu hỏi hy vọng sẽ cung cấp thêm thông tin chi tiết cho tình huống của chúng tôi.
Brent Keller

Cảm ơn Brent, tôi chưa sử dụng Filestream để sao chép, nhưng tôi chưa sử dụng nó trong prod, tuy nhiên, kích thước có vẻ không lớn lắm, tôi khuyên bạn nên thử các giao thức khác nhau được liệt kê trừ khi bạn biết chắc chắn ống rất bão hòa hoặc chỉ là quá nguy hiểm thời gian chậm. Ít nhất là theo cách này bạn sẽ biết chắc chắn khi nào bạn sẽ gặp vấn đề về khả năng mở rộng.
Ali Razeghi
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.