Helix Coreサーバ管理者ガイド: マルチサイト展開 (2019.1)

移行のシナリオ

このセクションでは、いくつかの移行シナリオにおける手順について説明します。必要な資料が見つからない場合は、電子メールでsupport@perforce.comに問い合わせてください。

マスターサーバをコミットサーバとして設定する

シナリオ: すでにマスターサーバがあります。マスターサーバをコミットサーバに変換して、引き続きクライアントのサポートを行いながら、エッジサーバと連携できるようにします。

まだサーバIDが存在しない場合、マスターサーバのサーバIDを選択し、p4 serveridを使用して保存します。
マスターサーバのサーバ仕様を設定するか、すでにサーバ仕様が存在する場合は既存の仕様を編集し、Services: commit-serverを設定します。

転送レプリカをエッジサーバに変換する

シナリオ: すでにマスターサーバと転送レプリカがあります。マスターサーバをコミットサーバに変換して、転送レプリカをエッジサーバに変換します。

現在のマスターサーバと転送レプリカの設定によっては、これらの手順の一部が省略できる場合があります。

転送レプリカのすべてのユーザに、現在の作業をサブミット、保留、または元に戻させ、現在のワークスペースを削除させます。
転送レプリカを停止します。
まだサーバIDが存在しない場合、マスターサーバのサーバIDを選択し、p4 serveridを使用して保存します。
マスターサーバのサーバ仕様を定義するか、すでにサーバ仕様が存在する場合は既存の仕様を編集し、Services: commit-serverを設定します。
p4 serverを使用して転送レプリカのサーバ仕様を更新して、Services: edge-serverを設定します。
次のいずれかの方法により、使用中の集中サーバのデータでレプリカサーバを更新します。
- チェックポイントを使用します。
  1. 集中サーバのチェックポイントを取出し、以下のテーブルをフィルタリングして表示します。db.have、db.working、db.resolve、db.locks、db.revsh、db.workingx、db.resolvex。
```
$ p4d -K "db.have,db.working,db.resolve,db.locks,db.revsh,db.workingx,db.resolvex"
      -jd my_filtered_checkpoint_file
```
    ヒント
    フィルタリングされたジャーナルダンプファイルを生成する場合は、『Helix Coreサーバ管理者ガイド: 基本』の「Helix Coreサーバリファレンス」で-kオプションと-Kオプションを確認してください。
  2. チェックポイントをレプリカに復元します。
  3. ただし、レプリカのステートファイルの削除は必須ではありません。
- 複製を使用します。
  1. レプリカを、別のポートで起動します。これにより、ローカルユーザが使用するのを防ぎます。
  2. マスターから更新をプルするのを待ちます。
  3. レプリカを停止し、以下のテーブルを削除します。db.have、db.working、db.resolve、db.locks、db.revsh、db.workingx、db.resolvex。
レプリカを起動すると、エッジサーバになります。
旧転送レプリカのユーザに、新規エッジサーバの利用を開始させます。
- 新規クライアントワークスペースを作成し、それらを同期します。

これで、新規エッジサーバのセットアップと実行が完了しました。

ビルドサーバをエッジサーバに変換する

シナリオ: すでにマスターサーバとビルドサーバがあります。マスターサーバをコミットサーバに変換して、ビルドサーバをエッジサーバに変換します。

ビルドサーバには、すでにローカルにバインドされたクライアントがあり、エッジサーバへの変換後も引き続きこのクライアントを使用できるとすれば、大変魅力的なことです。詳細は以下のとおりです。

ビルドサーバでは、ローカルにバインドされたクライアントはそれぞれのhaveデータとviewデータをdb.have.rpとdb.view.rpに格納します。
エッジサーバでは、ローカルにバインドされたクライアントはそれぞれのhaveデータとviewデータをdb.haveとdb.viewに格納します。

したがって、以下の手順でビルドサーバをエッジサーバに変換することができます。

Services: commit-serverを設定して、マスターのサーバIDとサーバ仕様を定義します。
ビルドサーバのサーバ仕様を編集して、Services: build-serverをServices: edge-serverに変更します。

ビルドサーバをシャットダウンして、以下を実行します。

$ rm db.have db.view db.locks db.working db.resolve db.revsh db.workingx db.resolvex
$ mv db.have.rp db.have
$ mv db.view.rp db.view

サーバを起動すると、エッジサーバになり、ローカルにバインドされたクライアントはすべて引き続き使用することができます。

注意

上記の手順3はdb.viewテーブルを破棄しますが、さまざまなオプションがあります。

db.viewを保持し、db.view.rpを破棄します。
前から存在するすべてのビルドクライアントがエッジサーバによって破棄されるため、エッジサーバでビルドクライアントを作成する必要があります。
db.view.rpを保持し、db.viewを破棄します。
エッジサーバは以前から存在するビルドクライアントにアクセスできるようになりますが、ビルドファームで以前にアクセス可能だったその他のクライアントにはアクセスできなくなります。
db.viewとdb.view.rpの両方を保持します。
ビルドクライアントを含め、すべてのクライアントで同じアクセス権を保持する場合は、テクニカルサポートにお問い合わせください。

コミットサーバまたはリモートエッジサーバからローカルエッジサーバにワークスペースを移行する

シナリオ: コミットサーバまたはリモートエッジサーバにワークスペースがあり、それをローカルエッジサーバに移行します。

現在の作業はサブミットされていない、もしくは保留済みでない可能性があります。
ワークスペース移行先のローカルエッジサーバに対して、次のコマンドを実行します。protocol:host:portは、ワークスペース移行元のコミットサーバまたはリモートエッジサーバを参照します。
```
$ p4 reload -c workspace -p protocol:host:port
```

の検索では、個の結果が出ました。