Di chuyển các kho lưu trữ Subversion trên các máy chủ

Question

Chúng tôi đang trong quá trình di chuyển máy chủ và một trong các mục cuối cùng đang di chuyển trên các kho lưu trữ svn.

Có khoảng 10 hợp đồng biểu diễn của nhiều kho svn khác nhau. Chúng được tạo bằng lệnh này: svnadmin create --fs-type fsfs

Máy chủ A (bản gốc) có svn 1.4 trong khi Máy chủ B (đích) có svn 1.6. Ý tưởng của tôi là sử dụng rsync để di chuyển toàn bộ kho lưu trữ (tất cả chúng nằm trong 1 thư mục trên máy chủ), nhưng tôi lo rằng một số thứ có thể không được di chuyển hoặc tôi cần thiết bị chuyển mạch đặc biệt cho rsync cho điều này làm việc.

Hầu hết các hướng dẫn trực tuyến chỉ nói về việc di chuyển 1 kho lưu trữ tại một thời điểm, ví dụ sử dụng svnadmin hotcopy, nhưng tôi cần phải di chuyển khoảng 100 hoặc hơn tất cả cùng nhau. Đây có phải là cách đi đúng đắn không?

Answer 1

FSFS của Subversion khá ổn định khi thực hiện các bản sao và chuyển động, thậm chí trên các hệ điều hành khác nhau. Mặc dù mliebelt là chính xác về việc thực hiện nó thông qua tải lại dump, phải mất độ tuổi để di chuyển 10 GB!

Đó là lý do tôi muốn giới thiệu các thủ tục sau đây:

1. Sao chép kho qua hệ thống tập tin đến máy chủ mới.
   ví dụ: $ scp -r /var/repos/ user@newServer:repos/

2. Thực hiện $ svnadmin upgrade để cập nhật trên kho lưu trữ 1.6 (tùy chọn này nhưng bạn nên sử dụng 1,5/1,6 tính năng như theo dõi hợp nhất, kiểm tra thưa thớt, v.v.)

3. Thực hiện $ svnadmin verify trên mỗi kho lưu trữ để xác minh tất cả các bản chỉnh sửa đều được (Bạn có thể thực hiện việc này trên máy chủ đang chạy).

Bằng phương pháp này bạn cần có lẽ là từ 10 đến 100 lần ít thời gian:

ví dụ để bán một kho lưu trữ thường mất khoảng 1 GB mỗi giờ (phần lớn phụ thuộc vào tốc độ HD), tệp kết xuất lớn hơn nhiều so với các kho lưu trữ (trong SVN 1.4!) Vì vậy, bạn phải di chuyển tệp lớn hơn sang tệp mới máy chủ và làm có một tải-dump mà cũng mất khoảng 1 giờ/GB. So sánh điều này với bản sao hệ thống tập tin thường chỉ bị giới hạn bởi kết nối mạng (100 mbit khoảng 10 MB/giây) hoặc HD (khoảng 100 MB/giây), nếu bạn có GBit-LAN.

Answer 2

Trước hết, tôi không phải là quản trị viên Subversion, nhưng tôi làm việc rất nhiều với họ. Vì vậy, không tin tưởng lời nói của tôi chỉ, kiểm tra các nguồn khác là tốt.

Kinh nghiệm của tôi trong 5 năm qua là:

• Để di chuyển kho Subversion, bạn nên sử dụng các công cụ quản trị Subversion dump và load. Chúng được viết chỉ cho công việc đó.
• dump và load kiểm tra thêm rằng mọi thứ đều ổn. Bằng cách sử dụng chúng, bạn sẽ nhận được thêm "bảo hiểm" mà mọi thứ đã được chuyển.
• Chúng tôi chưa bao giờ di chuyển qua 2 phiên bản chính, nhưng đã chuyển từ một phiên bản chính sang phiên bản tiếp theo. Bạn nên ít nhất là kiểm tra, di chuyển từ 1.4.x đến 1.6.x được hỗ trợ. Thường thì phiên bản máy chủ mới hỗ trợ phiên bản trước đó trực tiếp và hỗ trợ di chuyển. Vì vậy, có lẽ bạn phải thực hiện di chuyển cho mỗi kho lưu trữ hai lần.
• Bạn có thể làm việc trên các kho lưu trữ cũ miễn là chúng đang di chuyển, bởi vì lật đổ cho phép bạn thêm các phiên bản mới hơn sau này.
• Bởi vì tất cả có thể được thực hiện bằng dòng lệnh, bạn có thể tự động hóa hầu hết, và quản trị viên cấp dưới chỉ phải kiểm tra xem mọi thứ đã hoạt động tốt chưa.

Vì vậy, có, tôi khuyên bạn nên di chuyển một kho lưu trữ sau mỗi khác.

Answer 3

Để biết thêm thông tin về svnadmin dump và svnadmin load cho svn 1.6 xem here. Nó cung cấp một số cuộc thảo luận trên dump và load, cũng như các tùy chọn như --deltas, --incremental và các tùy chọn khác.

Ngoài ra, được cảnh báo rằng nếu bạn làm một bản sao thẳng và nâng cấp svnadmin bạn tiết kiệm thời gian, nhưng trạng thái lưu trữ có thể không tối ưu. Từ svnadmin giúp đỡ:

svnadmin help upgrade

sử dụng: svnadmin nâng cấp REPOS_PATH

Nâng cấp kho tọa lạc tại REPOS_PATH đến mới nhất hỗ trợ phiên bản giản đồ.

Chức năng này được cung cấp để thuận tiện cho kho lưu trữ quản trị viên muốn sử dụng chức năng Subversion mới mà không phải thực hiện một kho lưu trữ đầy đủ có khả năng tốn kém và hoạt động tải. Do đó, nâng cấp chỉ thực hiện số tiền tối thiểu là công việc cần thiết để thực hiện việc này trong khi vẫn duy trì tính toàn vẹn của của kho lưu trữ. Nó không đảm bảo trạng thái lưu trữ tối ưu nhất làm bãi chứa và tải tiếp theo sẽ.