Đồng bộ hóa cấu trúc thư mục rất lớn

Chúng tôi có cấu trúc thư mục trên mạng nội bộ của chúng tôi chứa khoảng 800.000 tệp được chia thành khoảng 4.000 thư mục. Chúng tôi cần đồng bộ hóa điều này với một cụm máy nhỏ trong DMZ của chúng tôi. Độ sâu của cấu trúc rất nông (nó không bao giờ vượt quá hai cấp độ sâu).

Hầu hết các tệp không bao giờ thay đổi, mỗi ngày có một vài nghìn tệp được cập nhật và 1-2 nghìn tệp mới. Dữ liệu là dữ liệu báo cáo lịch sử được duy trì trong đó dữ liệu nguồn đã bị xóa (tức là đây là các báo cáo được hoàn thiện mà dữ liệu nguồn đã đủ cũ để chúng tôi lưu trữ và xóa dữ liệu đó). Đồng bộ hóa một lần mỗi ngày là đủ để nó có thể xảy ra trong một khung thời gian hợp lý. Báo cáo được tạo qua đêm và chúng tôi đồng bộ hóa điều đầu tiên vào buổi sáng như một nhiệm vụ theo lịch trình.

Rõ ràng vì rất ít các tập tin thay đổi một cách thường xuyên, chúng tôi có thể hưởng lợi rất nhiều từ bản sao tăng dần. Chúng tôi đã thử Rupync, nhưng có thể mất đến tám đến mười hai giờ chỉ để hoàn thành thao tác "danh sách tệp xây dựng". Rõ ràng là chúng tôi đang nhanh chóng vượt xa khả năng của rsync (khung thời gian 12 giờ là quá dài).

Chúng tôi đã sử dụng một công cụ khác có tên RepliWeb để đồng bộ hóa các cấu trúc và nó có thể thực hiện chuyển khoản gia tăng trong khoảng 45 phút. Tuy nhiên, dường như chúng tôi đã vượt quá giới hạn, nó đã bắt đầu thấy các tệp hiển thị dưới dạng xóa khi chúng không hoạt động (có thể một số cấu trúc bộ nhớ trong đã cạn kiệt, chúng tôi không chắc chắn).

Có ai khác chạy vào một dự án đồng bộ hóa quy mô lớn của loại này? Có một cái gì đó được thiết kế để xử lý các cấu trúc tệp lớn như thế này để đồng bộ hóa?

Nếu bạn có thể tin tưởng vào dấu thời gian được sửa đổi lần cuối của hệ thống tệp, bạn có thể tăng tốc mọi thứ bằng cách kết hợp Rsync với tiện ích 'find' UNIX / Linux. 'find' có thể tập hợp một danh sách tất cả các tệp hiển thị thời gian được sửa đổi lần cuối trong ngày hôm qua, sau đó chuyển CHỈ danh sách các tệp / thư mục được rút ngắn thành Rupync. Điều này nhanh hơn nhiều so với việc Rupync so sánh siêu dữ liệu của mỗi tệp trên người gửi so với máy chủ từ xa.

Nói tóm lại, lệnh sau sẽ thực thi CHỈ CÓ trên danh sách các tệp và thư mục đã thay đổi trong 24 giờ qua: (Rupync sẽ KHÔNG bận tâm kiểm tra bất kỳ tệp / thư mục nào khác.)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

Trong trường hợp bạn không quen với lệnh 'find', nó sẽ đệ quy thông qua một cây con thư mục cụ thể, tìm kiếm các tệp và / hoặc thư mục đáp ứng bất kỳ tiêu chí nào bạn chỉ định. Ví dụ: lệnh này:

find . -name '\.svn' -type d -ctime -0 -print

sẽ bắt đầu trong thư mục hiện tại (".") và lặp lại qua tất cả các thư mục con, tìm kiếm:

• bất kỳ thư mục nào ("-type d"),
• được đặt tên là ".svn" ("-name '.svn'"),
• với siêu dữ liệu được sửa đổi trong 24 giờ qua ("-ctime -0").

Nó in tên đường dẫn đầy đủ ("-print") của bất kỳ thứ gì phù hợp với các tiêu chí đó trên đầu ra tiêu chuẩn. Các tùy chọn '-name', '-type' và '-ctime' được gọi là "tests" và tùy chọn '-print' được gọi là "hành động". Trang hướng dẫn 'tìm' có một danh sách đầy đủ các bài kiểm tra và hành động.

Nếu bạn muốn thực sự khéo léo, bạn có thể sử dụng thử nghiệm 'tìm kiếm' lệnh 'tìm kiếm', thay vì 'thời gian' để làm cho quá trình này trở nên dễ chịu và linh hoạt hơn. '-cnewer' kiểm tra xem mỗi tệp / thư mục trong cây có siêu dữ liệu được sửa đổi gần đây hơn một số tệp tham chiếu hay không. Sử dụng 'touch' để tạo tệp tham chiếu của NEXT chạy vào đầu mỗi lần chạy, ngay trước khi 'find ... | Lệnh rsync ... 'thực thi. Đây là cách thực hiện cơ bản:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

Kịch bản lệnh này tự động biết khi nào nó được chạy lần cuối và nó chỉ chuyển các tệp được sửa đổi kể từ lần chạy cuối cùng. Mặc dù điều này phức tạp hơn, nhưng nó bảo vệ bạn trước các tình huống mà bạn có thể đã bỏ lỡ khi chạy công việc trong hơn 24 giờ, do thời gian chết hoặc một số lỗi khác.

Hãy thử unison , nó được thiết kế đặc biệt để giải quyết vấn đề này bằng cách giữ các danh sách thay đổi (danh sách tệp xây dựng), cục bộ cho từng máy chủ, tăng tốc thời gian để tính toán delta và giảm số lượng được gửi qua dây sau đó.

http://oss.linbit.com/csync2/ được thiết kế cho loại điều này, tôi sẽ thử.

Nếu bạn đang sử dụng công tắc -z trên rsync, hãy thử chạy mà không có nó. Vì một số lý do, tôi đã thấy điều này tăng tốc ngay cả việc liệt kê các tập tin ban đầu.

Việc rút -z ra khỏi lệnh rsync không nén được khiến "danh sách tệp nhận" đi nhanh hơn rất nhiều và chúng tôi phải chuyển khoảng 500 GB. Trước khi nó mất một ngày với công tắc -z.