p4 pull

このコマンドを使用して、Helixサーバのマスターサーバのメタデータやバージョン化ファイルを 取得してレプリカサーバに複製したり、保留中の転送処理に関するステータス情報を 表示したりすることができます。ただし、コミットサーバでレプリカからプルする場合は、 特殊な構文を使用する必要があります。ほとんどの場合、サーバの複製には p4 pullよりもp4 replicateの方が適切です。

レプリカでコミットサーバからプルする場合の構文

p4 [g-opts] pull [-J prefix] [-i interval] [-b interval] [-T excluded_tables] [-P serverid]
p4 [g-opts] pull -u [-i interval -b interval --batch=number --min-size=number --max-size=number --trigger]
p4 [g-opts] pull -l [-s | -j [-J prefix]]
p4 [g-opts] pull -d -f file -r revisionp4 [g-opts] pull -L [-i interval]
p4 [g-opts] pull -R [file] p4 pull -T

コミットサーバでレプリカからプルする場合の構文

p4 pull -u -t target [-i interval -b interval]

説明

p4 pullコマンドには、以下のような構文のパターン(バリアント)があります。

説明

p4 [g-opts] pull [-J prefix] [-i interval] [-b interval] [-T excluded_tables] [-P serverid]

1番目のバリアントは、P4TARGETで指定されたターゲットサーバから ジャーナルレコードを取得します。

p4 [g-opts] pull -u [-i interval -b interval --batch=number --min-size=number --max-size=number --trigger]

2番目のバリアントは、P4TARGETで指定されたターゲットサーバから ファイルの内容を取得します。

p4 [g-opts] pull -l [-s | -j [-J prefix]]

3番目のバリアントは、スケジュールされたファイル転送に関する情報を表示します。

p4 [g-opts] pull -d -f file -r revision

4番目のバリアントは、スケジュールされたファイル転送をキャンセルします。

p4 [g-opts] pull -L [-i interval]

5番目のバリアントは、ジャーナルレコードを、ターゲットサーバのジャーナルファイルからではなく、 ローカルのジャーナルファイル(p4 journalcopyコマンドで作成)から取得します。 その後、これらのレコードはレプリカサーバのデータベースに書き込まれます。 フェイルオーバー用のスタンバイレプリカで使用

p4 [g-opts] pull -R

失敗したすべての転送処理をもう一度実行します

p4 [g-opts] pull -R file

指定されたファイルの失敗した転送処理をもう一度実行します

テスト目的以外でp4 pullがコマンドラインから実行されることは ほとんどありません。代わりにstartup.N構成可能変数を設定し、 レプリカサーバが起動するたびに p4 pullプロセスが起動するようにしてください。

注意

マスターサーバまたはレプリカサーバのどちらかを停止すると、 レプリカサーバはステートファイルという小さいテキストファイルの中に 最新のジャーナルの位置を記録します。デフォルトでは、ステートファイルは stateという名前でレプリカサーバのルートディレクトリに格納されます。 statefileで構成可能変数p4 configureを設定することにより、 別のファイル名を指定できます。

ジャーナルおよびファイル内容の取得

p4 pullコマンドは、P4TARGETにより指定されたターゲットサーバから ジャーナルレコードまたはファイル内容のどちらかを取得するよう、 現在のレプリカサーバに指示します。 レプリカサーバの中には、ジャーナルレコードとファイル内容の両方は必要ないものもあります。 例えば、オフラインのチェックポイント設定に使用するレプリカサーバでは、 ファイルの内容を転送する必要はありません。

メタデータとファイルコンテンツの両方を複製するには、 2つのp4 pullコマンドを同時に実行する必要があります。 この場合、p4 pullを(-uオプションを付けずに)1回実行してマスターサーバのメタデータを複製し、 さらにp4 pullを(-uオプションを付けて)1回以上実行してサーバの バージョンファイルを複製します。

  • -iオプションは、次の更新までのポーリング間隔(単位は秒)を指定します。 -iが指定されない場合、p4 pullはポーリング間隔を1として実行した後に終了します。
  • -bオプションは、pull実行の失敗後に待機する時間を指定します。 -bが指定されていない場合、p4 pullは60秒ごとに再試行されます。
  • -uオプションを使用して、ファイルコンテンツを取得する必要があることを指定します。 このオプションが指定されない場合は、ジャーナルレコードのみが取得されます。
  • --batchオプションを使用して、1回の要求でプルスレッドが処理するファイルの数を指定します。 通常、デフォルト値の1で十分です。 長い遅延が発生する構成の場合は、このフラグに大きな値を設定すると、サイズの小さな ファイルを大量に処理する際に、アーカイブの転送速度が上がる可能性があります。 (このオプションの使用には、バージョン15.2以上のマスターとレプリカの両方が必要です)

-Tオプションは、複製しないテーブルを除外します。 例えばビルドファームサーバの場合、db.haveテーブル、db.workingテーブル、 db.resolveテーブルを複製する必要はありません。

待ち状態のファイル転送処理を削除するには、p4 pull -d -f file -r revを使用します。 このコマンドは、マスターに回復不可能なエラーがあるために待ち状態のファイル転送が 繰り返し失敗する場合に有効です。

注意

rpl.compress構成可能変数を設定して、p4 pullを使用して転送された ジャーナルレコードのデータを圧縮することができます。

ステータス情報を得る

待ち状態のファイル内容転送のリストを表示するには、 -lオプションを使用します。-lとともに-sが指定されると、スケジュールされた ファイル転送の概要が表示されます。追加の行で、少なくとも1つの作業中の転送を含む 最も古いチェンジリスト番号を指定します。 これは、レプリカサーバにアーカイブ内容の転送のラグがどれくらあるかのヒントになります。

オペレータは、p4 journalcopy -lp4 pull -l -jp4 pull -l -sコマンドを実行することができます。 オペレータはこれらのコマンドを使用して、複製状況を確認することができます。

File transfers: n active/m total, bytes: nnn active/mmmmm total.
Oldest change with at least one pending file transfer: n

例えば、以下が出力されたとします。

File transfers: 1 active/63 total, bytes: 745 active/23684 total.

これは、63のアーカイブファイルの転送が作業中で、そのうちの1つが現在アクティブになっており、 転送が現在アクティブに進行中している745の転送には23,684バイトが 必要であることを示しています。

-lとともに-jが指定されると、現在のレプリカとそのマスターに関する カレントジャーナルの状態、ステートファイルの最終更新時刻、およびサーバの ローカル時刻とタイムゾーンが報告されます。 以下に例を示します。

Current replica journal state is: Journal jjj, Sequence: sssss.
Current master journal state is: Journal jjj, Sequence: sssss.
The statefile was last modified at: 2012/01/10 14:23:23.
The Server time is currently: 2012/01/10 14:23:23 -0800 PST

jjjの値はジャーナル番号を指定します。 sssssは、そのジャーナルのオフセットを指定します。

オプション

-b interval

取得の失敗後に再試行するためのポーリング間隔を秒数で指定します。 このオプションが指定されていない場合、pullは60秒後に再試行されます。

-u

ジャーナルレコードの代わりにアーカイブファイルを転送します。このオプションを省略すると、 このコマンドはジャーナルレコードを取得します。1つのレプリカサーバで、p4 pull -uコマンドを繰り返し実行することができます。

--batch number

このオプションを使用して、1回の要求でプルスレッドが処理するファイルの数を指定します。 長い遅延が発生する構成の場合は、このフラグにデフォルト値よりも 大きな値を設定すると、サイズの小さなファイルを大量に処理する際に、 アーカイブの転送速度が上がる可能性があります。

デフォルト: 1

--min-size number

 

--min-size--max-sizeオプション。

  • 次を併用する必要があります: -u--batch
  • pullコマンドで使用して、異なるサイズのファイルに、異なるプルスレッドを作成します。

これらのオプションで呼ばれたプルスレッドは、これらのオプションで指定したデータサイズの 範囲のファイルをプルします。デフォルトのサイズ単位はバイトですが、「2K」のように、K、M、G、Tなどの 修飾子も使用することができます。最大および最小サイズの例を参照してください。

--max-size number

 

-d-f file-r rev

作業中のファイル内容転送を中止します。ただし、filerevは、 ディポファイルおよび特定のリビジョンを示します。

注意

これは、通常のHelixサーバファイルと リビジョンデータではなく、 アーカイブファイルとリビジョンになります。 p4 pull -lコマンドを使用して、正しいファイル名とリビジョンを取得します。

-i interval

ファイル内容を取得するポーリング間隔を秒数で指定します。 最も短い間隔は1秒です。このオプションを省略すると、 コマンドは1回のみ実行されて終了します。

間隔を0に設定すると、マスターサーバは新しいデーが 入手可能になるとすぐレプリカに通知をします。このようにして、 レプリカサーバは新しいデータを遅延無く取得することができます。

-J prefix

ローテートされたジャーナルファイルのプレフィックスを指定します。 構成可能変数journalPrefixをオーバーライドします。

マスターサーバがデフォルトではないローテートされたジャーナルの位置を 使用している場合、これによりマスターサーバのジャーナルファイルの位置を 指定することができます。

-l

転送がスケジュールされているファイルのリストを表示します。

このオプションをlbr.replication=cache設定を保持するエッジサーバまたは ビルドサーバで使用する場合、ファイル転送が並行して実行されるため、 複数エントリが表示される可能性があります。

p4 pull -l(およびp4 pull -ls)は、コミットサーバで実行可能で、エッジサーバへの送信による逆方向のレプリケーションを監視します。

-l -j

レプリカとマスターにおけるカレントジャーナルの状態を表示します。

マスターにおけるジャーナルローテーションの処理中、 p4 pull -l -jの出力には3行が書き出される可能性があります。 それらは、レプリカジャーナルの現在の状態を表す行、 対応するマスター上のジャーナルの状態を表す行、そしてマスター上の 新しいジャーナルを表す行(ここからのデータはレプリカにはまだ到達していない)です。

-l -s

待ち状態のファイル内容転送の概要を表示します。 このリストが予想外に長いまたは増加している場合は、 追加でp4 pull -uコマンドの実行を検討してください。

-L

通常p4 journalcopyコマンドにより作成されるローカルのジャーナルファイルから、 ジャーナルレコードを取得します。

-P serverid

指定サーバのp4 serverフォームの ArchiveDataFilter:フィールド、 ClientDataFilter:フィールド、 RevisionDataFilter:フィールドに従って、 serveridからデータをフィルタします。

以前のリリースでは、このオプションはフィルタ仕様で設定されたフィルタを確認していました。 この確認はもう必要ではありません。このオプションは、以前のリリースの サポート継続のために保持されました。 これは、複数のサーバでフィルタ構成を共有する場合にも便利です。 この場合、serveridは、 フィルタ条件を共有するサーバを参照します。

注意

Helixサーバの以前のリリースとの互換性のため、 p4 exportで使用されている同じシンタックスを使用して、 フィルタパターンを直接指定することができますが、 サーバを指定してp4 serverフォームのフィールドを 使用することを強く推奨します。 なぜなら、p4 pull引数に整合性がないまたは衝突がある、 複数の-P filterpatternコマンドを使用するレプリカサーバの 動作は不確定であるためです。

-R

p4 pull -R file: 指定されたファイルの失敗した転送処理をもう一度実行します

p4 pull -R: 失敗したすべての転送処理をもう一度実行します

注意

-d オプションを指定すると、保留中または失敗したファイル転送を個別に削除できますが、 -Rオプションを指定すると、転送処理の失敗回数がリセットされ、 後続のプル操作で転送処理を実行できるようになります。

-T excluded_tables

レプリカサーバのジャーナルレコードから除外するデータベーステーブル (db.havedb.workingなど)のリストを供給します。 サーバルートディレクトリのデータベースファイルに適用される命名規則に従い、 テーブル名の先頭には「db.」を指定する必要があります。

複数のテーブルを指定するには、リストを二重引用符で囲み、 テーブル名をスペースで区切ります。テーブル名は、カンマで区切ることもできます。 例えば、-T db.have,db.working-T "db.have db.working"のようになります。

--trigger

--triggerオプションは、トリガ内からの代替的なファイル転送のメカニズムを 使用してファイルを転送するプルアーカイブトリガと併用します。 このオプションを使用できるのはマルチサーバ環境の場合だけで、 RCSストレージで使用することはできません。pull.trigger.dir構成可能変数の値を、一時ファイルを書き込む場所に設定する必要があります。 また、lbr.replica.notransfer構成可能変数の値を「=1」に設定して、 オンデマンドでのファイル転送を禁止することをお勧めします。

-t target

コミットサーバでp4 pull -lを実行しても、エッジサーバからアーカイブをプルできない場合は、以下のコマンドを手動で実行します。

p4 pull -u -t target

各項目の意味は以下のとおりです。

  • -uを指定すると、アーカイブ転送機能が有効になります。
  • targetを使用して、エッジサーバのサーバ仕様のExternalAddressフィールドを指定します。「p4 server」を参照してください。

g-opts

グローバルオプション」を参照してください。

使用上の注意点

ファイル引数でリビジョン指定子を使用できるか? ファイル引数でリビジョン範囲を使用できるか? 最低限必要なアクセスレベル

適用外

適用外

  • super
  • オペレータに対して、-ljオプションと-lsオプションを指定することができます(「p4 user」の「ユーザのタイプ」を参照)。

複製環境で稼働するようにHelixサーバを設定する方法については、 『Helix Coreサーバ管理者ガイド』の 「複製」を参照してください。

最大サイズと最小サイズを指定する場合の例

>startup.2=pull -u -i 1  --batch=1000 --min-size=1 --max-size=2047
startup.3=pull -u -i 1  --batch=5 --min-size=2048 --max-size=4096
startup.4=pull -u -i 1  --batch=5 --min-size=4097

関連コマンド

起動時にp4 pullコマンドを連続実行するように Helixサーバを構成する

p4 configure

あるサーバから別のサーバにメタデータを複製する

p4 replicate

ジャーナルレコードまたはチェックポイントレコードを未加工のフォームで表示する

p4 export

ジャーナルデータをレプリカサーバのローカルファイルシステムにコピーする

p4 journalcopy