マスターサーバの設定
レプリカの動作を定義するには、p4 configure setコマンドを使用して、マスターサーバのdb.configファイルに構成情報を入力する必要があります。最初にマスターサーバを設定してください。マスターサーバの設定が、後でレプリカサーバに複製されます。
マスターサーバを設定するには、スーパーユーザとしてHelixサーバにログインし、以下の手順を実行します。
-
master:11111をマスターサーバとして使用するようにReplica1という名前のサーバを設定し、メタデータとバージョンファイルを取得するには、以下のコマンドを実行します。$ p4 -p master:11111 configure set Replica1#P4TARGET=master:11111
Helixサーバが以下の応答を表示します。
For server Replica1, configuration variable 'P4TARGET' set to 'master:11111'
注意同じようにみえる複数のサーバを操作する場合の混乱を避けるには、
-uオプションを使用してスーパーユーザのアカウントを指定し、次に-pオプションを使用して、マスターのHelixサーバのホストとポートを明示的に指定します。説明を簡潔にするため、この例ではこれらのオプションを省略しています。実稼働環境のコマンドラインで、ホストとポートを指定してください。
-
指定のファイル名を使用してレプリカサーバのログファイルを保存するように
Replica1サーバを設定します。固有のログ名を指定すると、デバッグやパフォーマンス測定用のデータを収集する際の問題を回避することができます。$ p4 configure set Replica1#P4LOG=replica1Log.txt
-
Replica1serverの構成可能変数を1に設定します。これは、サーバ起動オプションの-vserver=1を指定した場合と同じ結果になります。$ p4 configure set Replica1#server=1
-
プロセスの監視を有効にするには、
Replica1のmonitorの構成可能変数を1に設定します。$ p4 configure set Replica1#monitor=1
-
Replica1の複製プロセスを処理するには、以下に示す3つのstartup.Nコマンドを設定します(スペースで区切られた複数の値を受け渡す場合は、その値のセット全体を二重引用符で囲む必要があります)。以下に示す最初の起動プロセスにより、ジャーナルデータだけを1秒間隔でポーリングするように
p4 pullが設定されます。$ p4 configure set "Replica1#startup.1=pull -i 1"
次の2つの設定では、起動時に2つの
p4 pullスレッドを生成するようにサーバが設定されます。各スレッドは、アーカイブデータの転送を1秒間隔でポーリングします。$ p4 configure set "Replica1#startup.2=pull -u -i 1" $ p4 configure set "Replica1#startup.3=pull -u -i 1"
各
p4 pull -uコマンドにより、アーカイブデータを複製するための個別のスレッドが作成されます。アーカイブデータの転送がメタデータの複製よりも遅れ始めた場合、負荷の高いサーバではより多くのスレッドが必要になることがあります。追加のp4 pull -uプロセスが必要かどうかを判断するには、rdb.lbrテーブルの内容を確認します。このテーブルには、マスターのHelixサーバからレプリカサーバに転送されたアーカイブデータが記録されます。レプリカの稼働中にこのテーブルの内容を表示するには、以下のコマンドを実行します。
$ p4 -p replica:22222 pull -l
同様に、アクティブなファイル転送の数や作業中のファイル転送の数だけを確認する場合は、
p4 -p replica:22222 pull -l -sコマンドを実行します。p4 pull -l -sコマンドで、作業中の転送数が多いことがわかった場合、p4 pull -u startupコマンドを追加して問題を解決することを検討します。n特定のファイル転送が繰り返し失敗する場合は(マスター上で回復不能なエラーが発生していることが原因として考えられます)、
p4 pull -d -fコマンドを使用して、作業中の転送をキャンセルすることができます。このコマンドのfileとrevは、それぞれファイル番号とリビジョン番号を示します。file-rrev -
以下のように、構成可能変数の
db.replication(メタデータへのアクセス)とlbr.replication(ディポファイルへのアクセス)を読み取り専用に設定します。$ p4 configure set Replica1#db.replication=readonly $ p4 configure set Replica1#lbr.replication=readonly
このレプリカサーバはウォームスタンバイサーバ(フェイルオーバーサーバ)として使用されるため、マスターサーバのメタデータとバージョン付きディポファイルのライブラリの両方が複製されます。レプリカが稼働している場合、そのレプリカのユーザは、メタデータとサーバのディポファイルのライブラリの両方にアクセスするコマンドを実行することができます。
-
以下のコマンドを使用して、サービスユーザを作成します。
$ p4 user -f service
serviceユーザの仕様が、デフォルトのエディタで開きます。以下の行を、ユーザ仕様に追加します。Type: service
ユーザ仕様を保存し、デフォルトのエディタを終了します。
デフォルトでは、標準ユーザと同じ12時間のログインタイムアウトがサービスユーザに対して設定されます。サービスユーザのチケットがタイムアウトにならないようにするには、長いタイムアウト値が設定されたグループをマスターサーバ上で作成します。以下の例では、
Timeout:フィールドの値を20億秒(約63年)に設定しています。$ p4 group service_group
Users: service Timeout: 2000000000
詳細については、Helix Coreサーバ管理者ガイド: 基本の「サービスユーザのチケットとタイムアウト」を参照してください。
-
プロテクションテーブルで、サービスユーザのプロテクションを
superに設定します。(サービスユーザの権限を参照してください)。すべてのHelixサーバについて、セキュリティレベルを1以上に設定することをお勧めします(可能であれば3に設定することで、サービスユーザは強固なパスワードの入力が必要になります。理想としては4に設定し、許可されているサービスユーザだけが、複製処理やリモートディポトランザクションを実行できるようにします)。$ p4 configure set security=4 $ p4 passwd
-
serviceUserのReplica1構成可能変数をserviceに設定します。$ p4 configure set Replica1#serviceUser=service
この手順により、レプリカサーバがマスターサーバに対して
serviceユーザとして認証されます。これは、-u serviceオプションを指定してp4dコマンドを実行した場合と同じ結果になります。 -
レプリカサーバを実行しているユーザがホームディレクトリを持っていない場合や、デフォルトの
.p4ticketsファイルが通常保存されるディレクトリへの書き込みをレプリカのHelixサーバプロセスが実行できない場合は、レプリカのHelixサーバのルートディレクトリ内の書き込み可能チケットファイルを指すようにレプリカのP4TICKETSの値を設定します。$ p4 configure set "Replica1#P4TICKETS=/p4/replica/.p4tickets"
次の手順
