web-dev-qa-db-ja.com

非常に大きなフォルダー構造の同期

イントラネットには、約4,000のフォルダーに分割された約800,000のファイルを含むフォルダー構造があります。これをDMZ内のマシンの小さなクラスターに同期させる必要があります。構造の深さは非常に浅いです（2レベルを超えることはありません）。

ほとんどのファイルが変更されることはなく、毎日数千の更新ファイルと1〜2千の新しいファイルがあります。データは、ソースデータが削除された場所で維持されている履歴レポートデータです（つまり、これらは、ソースデータが古く、アーカイブして削除するのに十分な最終レポートです）。妥当な時間枠で発生する可能性があるため、1日1回の同期で十分です。レポートは夜間に生成され、スケジュールされたタスクとして朝一番に同期されます。

当然のことながら、定期的に変更されるファイルはほとんどないため、インクリメンタルコピーの恩恵を受けることができます。 Rsyncを試してみましたが、「ファイルリストの作成」操作を完了するだけで8〜12時間かかる場合があります。 rsyncの能力を急速に上回っていることは明らかです（12時間の時間枠は長すぎます）。

RepliWebと呼ばれる別のツールを使用して構造を同期しており、約45分で増分転送を行うことができます。ただし、制限を超えたようです。ファイルが削除されていないときに削除として表示されるようになりました（内部メモリ構造が使い果たされた可能性がありますが、わかりません）。

他の誰かがこの種の大規模な同期プロジェクトに遭遇しましたか？このような大規模なファイル構造を同期のために処理するために設計されたものはありますか？

backuprsyncsynchronizationunison
14
MightyE

ファイルシステムの最終変更のタイムスタンプを信頼できる場合は、RsyncとUNIX/Linuxの「find」ユーティリティを組み合わせることで、速度を上げることができます。 'find'は、過去1日の最終変更時刻を示すすべてのファイルのリストを作成し、ファイル/ディレクトリの短縮されたリストのみをRsyncにパイプすることができます。これは、Rsyncで送信者のすべての単一ファイルのメタデータをリモートサーバーと比較するよりもはるかに高速です。

つまり、次のコマンドは、過去24時間に変更されたファイルとディレクトリのリストに対してのみRsyncを実行します（Rsyncは、他のファイル/ディレクトリをチェックする必要はありません）。

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

'find'コマンドに慣れていない場合は、特定のディレクトリサブツリーを再帰的に検索し、指定した基準を満たすファイルやディレクトリを探します。たとえば、次のコマンド：

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

現在のディレクトリ（ "。"）から開始し、すべてのサブディレクトリを再帰的に検索します。

  • 任意のディレクトリ（ "-type d"）、
  • ".svn"（ "-name '.svn'"）という名前
  • 過去24時間にメタデータが変更された（ "-ctime -0"）。

これらの基準に一致するすべてのフルパス名（ "-print"）を標準出力に出力します。オプション「-name」、「-type」、および「-ctime」は「テスト」と呼ばれ、オプション「-print」は「アクション」と呼ばれます。 「find」のmanページには、テストとアクションの完全なリストがあります。

本当に賢くなりたい場合は、「-ctime」の代わりに「find」コマンドの「-cnewer」テストを使用して、このプロセスの耐障害性と柔軟性を高めることができます。 '-cnewer'は、ツリー内の各ファイル/ディレクトリのメタデータが参照ファイルよりも最近変更されたかどうかをテストします。 'touch'を使用して、次の実行の参照ファイルを各実行の開始時の 'find ... |の直前に作成します。 rsync ... 'コマンドが実行されます。基本的な実装は次のとおりです。

#!/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

このスクリプトは、前回の実行日時を自動的に認識し、前回の実行以降に変更されたファイルのみを転送します。これはより複雑ですが、ダウンタイムまたはその他のエラーが原因で24時間を超えてジョブの実行に失敗した可能性がある状況から保護します。

9
Ryan B. Lynch

nison を試してください。変更リスト（ファイルリストの作成）をローカルサーバーごとに保持し、デルタの計算時間を短縮して、送信される量を減らすことで、この問題を解決するように特別に設計されていますその後ワイヤーを渡って。

7
Dave Cheney

http://oss.linbit.com/csync2/ はこの種のことのために設計されているので、試してみます。

3
Justin

Rsyncで-zスイッチを使用している場合は、それなしで実行してみてください。なんらかの理由で、これによりファイルの初期列挙でさえ速度が上がることがわかりました。

2
Chris Thorpe

圧縮されていないrsyncコマンドから-zを取り除くと、「受信ファイルリスト」が非常に速くなり、約500 GBを転送する必要がありました。 -zスイッチで1日かかる前に。

2
ryand32