svnadmin ダンプとロードを使用して、新しい Subversion サーバーに移行するリポジトリがあります。以下の手順で概説するように、私はこれを2回行っています。
- repoX はリビジョン 100 です
- svnadmin dump repoX > repoX.dump を実行します
- 新しいサーバーで svnadmin create repoX を実行します
- 新しいサーバーで svnadmin load repoX < repoX.dump を実行します
これはこれまでのところすべて機能しており、svnadmin verify はすべて問題ないと言っています。次に、新しいレポを最新の状態にしようとします (これは最終カットオフの前で、この段階ではまだテスト中です)。
- 次に、svnadmin dump repoX -r 101:head --incremental > repoX.dump を実行します。
- 新しいサーバーでもう一度 svnadmin load repoX < repoX.dump を実行します
次に、repoX の一部のパスが存在しないというエラーが表示されます。そこで、次を使用して増分ダンプを再試行しました。
- svnadmin dump repoX -r 100:head --incremental > repoX.dump
今回は動作し、正常に確認されました。
ただし....他のリポジトリ、たとえば repoY があります。2 番目のメカニズム (最初のダンプでリビジョン 100 に移動し、リビジョン 100 から更新されたダンプを取得する) を試すと、ディレクトリが既に存在するという別のエラーが表示されます。ある方法で動作するリポジトリもあれば、別の方法で動作するリポジトリもあり、同じ方法で実行するとすべてが動作しません。
したがって、私が知りたいのは、リビジョン 100 (たとえば) へのダンプから正しいメカニズムであり、2 回目のスイープで残りのリポジトリをヘッドにダンプすることです。私は午前中、読書、読書、読書をして過ごしましたが、それができることを知っていても、自分がしていることの例を見つけることさえできません.
50 のリポジトリにまたがる 150 GB 相当のデータについて話しているため、1 つのダンプ ファイルを切り捨てることはできません。これは物理的に一晩でダンプ、転送、ロードすることはできません。このメカニズムにより、最終的なカットオーバーの前にデータの 95% を移動できるようになりますが、私の理論には欠陥があるようです。
さらに情報が必要な場合は、お尋ねください。
大丈夫。テスト領域でプロセス全体を再度開始しましたが、問題なく動作しているように見えました。今日もテストを続けますが、この段階ではうまくいっているようです。これらのエラーを引き起こすために最初に何をしたかは誰にもわかりません。