0

いくつかのドメインを含む 4 つの Web サーバーのクラスターがあり、そのうちの 1 つには非常に多くのビデオが含まれています。また、通常はファイルを同期/アップロードし、そこからbashスクリプトを介して他のWebサーバーにすべて再同期する「ステージング」サーバーもあります。

私たちが抱えている問題は、これのかなりの部分が手動であることです。週末にコンテンツ編集者の 1 人が動画を差し替えたり、新しい動画をアップロードしたりしたい場合は、月曜日まで待つ必要があります。ファイルを別の場所にアップロードする方が簡単であるなどの理由でファイルをアップロードすることがわかっています。

スタッフ メンバーが大きなファイルをステージング サーバーにアップロードし、それらを他のサーバーで同期できるようにするソリューションが必要です。うまくいけば、他の誰もプロセスに関与することはありません。

ajaxファイルマネージャーを見てきました。sftp経由でアップロード ファイルマネージャーを使用してファイルをスーパーシンクボタンに移動します

4

2 に答える 2

0

なんらかの自動化されたプロセス (たとえば cron を使用) で同期を実行してみませんか?

「ドロップ ボックス」ディレクトリ (または複数のディレクトリ) を監視する cron ジョブを作成すると、スクリプトを実行してレプリケーションを実行できます。

または、アップロード後にファイルをより適切にルーティングするために、ユーザーにメタデータを含むファイルを送信させることもできます。

簡単に言えば、ユーザーにどこに行くかを「選択」させてはいけません。むしろ、「それが何のためにあるのか」をユーザーに伝えてもらい、スクリプトがどこに行くのか、どのようにそこに移動するのかをスクリプトに「認識」させます。

これは、perl CGI などを使用しただけでも、かなり単純な Web アプリケーションです。また、バックエンドの配管も簡単です。

コメント返し中…

CGI へのアップロードを実行する Web アプリを使用している場合、通常、ファイルが完全にアップロードされるまで、リクエストの「制御」すら取得できません。種類は、使用するサーバー側の技術によって異なります。いずれにせよ、ファイルが完全にアップロードされると、Web アプリで簡単に「知る」ことができます。その後、同期プロセスはメタデータのみに依存して実際にファイルで作業を行うことができ、ファイルを適切なステージング領域に移動するまでメタデータを作成しません。

FTP または scp を使用してファイルをステージング ディレクトリにコピーするだけの場合、解決策には 2 つのプロセスがあります。1 つ目は着信ディレクトリを監視し、2 つ目は実際にファイルをコピーします。

最初のプロセスは次のようになります。

cd /your/upload/dir
ls -l > /tmp/newfiles
comm -12 /tmp/lastfiles /tmp/newfiles > /tmp/samefiles
filelist=`awk '{print $9}' /tmp/samefiles`
mv $filelist /your/copy/dir
mv /tmp/newfiles /tmp/lastfiles

これは次のように機能します。

  • 着信アップロード ディレクトリ内の現在のファイルのリストを取得します。
  • comm(1) を使用して、プロセスが最後に実行されてから変更されていないファイルを取得します。
  • awk(1) を使用して、変更されていないファイル名を取得します。
  • mv(1) を使用して、ファイルを「ステージング」ディレクトリに移動します。
  • 最後に、ファイルの現在のリストを取得し、次の実行の最後のリストにします。

ここでの魔法は comm(1) です。'comm -12 filea fileb' は、2 つのファイル間で同じ行を含むファイルを提供します。新しいファイルが入ってくると、そのサイズはアップロードされるにつれて変化するため、次の分に「ls -l」を実行すると、その行は新しい行と一致しません-サイズは（最小限）異なります. そのため、comm は、日付、ファイル名、およびサイズが変更されていないファイルのみを検索します。そのリストを取得したら、残りは非常に簡単です。

このプロセスが行う唯一の前提は、ファイル名にスペースが含まれていないことだけです (したがって、awk はリストからファイル名を取得するために簡単に機能します)。スペースを許可する場合は、「ls -l」行をファイル名に変換するための、もう少し巧妙なメカニズムが必要になります。

また、「mv $filelist /your/copy/dir」はファイル名にスペースがないことを前提としているため、これも変更する必要があります (awk スクリプトにロールインして、system() 呼び出しを行うことができます。多分）。

2 番目のプロセスも簡単です。

cd /your/copy/dir
for i in *
do
    sync $i
    mv $i /your/file/youve/copied/dir
done

繰り返しますが、ここでは「ファイル名にスペースがないことを前提としています」。このプロセスは、Does The Right Thing というあなたが作成した同期シェル スクリプトに依存しています。それは読者の演習として残されています。

同期が完了すると、ファイルは別のディレクトリに移動されます。そこに表示されるファイルはすべて、適切に「同期」されています。ファイルを単純に削除することもできますが、私はそうしない傾向があります。おそらく、そのディレクトリを「1週間以上経過したファイルを削除する」プログラムに入れます。これにより、問題が発生した場合でも、元のファイルを回復できる場所に保持できます。

これは非常にシンプルですが、堅牢でもあります。

最初のプロセスがアップロードよりも「遅く」実行される限り (つまり、2 回続けて実行すると、ファイル サイズが少なくとも変化することが保証されます)、実行時間は 1 分ごと、1 時間ごとにすることができます。 、 毎日、何でも。少なくとも、安全に再起動でき、自己回復します。

2 番目のプロセスの暗い面は、同期プロセスがスケジュール cron よりも長くかかる場合です。毎分実行し、実行に 1 分以上かかる場合は、2 つのプロセスが同じファイルをコピーすることになります。

同期プロセスが「安全」である場合、ファイルを 2 回コピーするだけで終わります...無駄ですが、通常は無害です。

このような手法を使用して、コピー スクリプトが一度に複数実行されないようにすることで、これを軽減できます。

それがその肉です。組み合わせて使用​​することもできます (Web アプリを使用してメタデータをアップロードし、cron を介して自動的に実行される同期プロセスを使用します)。

また、/your/copy/dir 内のすべてのファイルを一覧表示する単純な Web ページを作成して、ファイルがまだ同期されているかどうかを確認できるようにすることもできます。ファイルがこのディレクトリにある場合、同期はまだ完了していません。

于 2009-08-29T00:57:39.427 に答える
0

アップロード専用のディレクトリに物を入れます。次に、rsync を使用して別のサーバーにコピーします。後でファイルをどこかに移動する心配はありません。Rsync は、ファイル サイズ + 変更時間を使用して、ドロップボックスから他のサーバーにファイルをコピーする必要があるかどうかを判断します。

あなたのスクリプトは

#!/bin/bash

servers="monkey cow turtle"

for s in $servers
do
    rsync -r /path/to/dropbox $s:/place/to/putit
done

手動で開始するか、cron で実行できます。PIDファイルを作成/チェックして、それ自体の1つだけが実行されるようにしたり、必要に応じてサーバーへの同期を並行して開始したりできます。スクリプトが最初に実行されたときにファイルが「途中でアップロード」された場合、ファイルは完了します2 回目は自動的に。

于 2009-09-04T21:36:17.507 に答える