スタンバイサーバと転送スタンバイサーバ
バージョン2019.1のHelix Coreサーバ2019.1では、スタンバイサーバ(または転送スタンバイサーバ)の複製機能が改善され、読み取り専用レプリカサーバを使用する場合の利便性が高くなりました。以下に、具体的なメリットを示します。
- マスターサーバで障害が発生しても、トランザクションが失われることはありません。
- p4 pullコマンドを実行する際に、データベースをロックする必要がなくなりました。
p4 pull
コマンドがスリープ状態になる前に、すべてのジャーナルレコードがプルされます。
スタンバイサーバにより、pullコマンドのプロセスがp4 journalcopyコマンドとp4 pull -Lコマンドに分割されます。
p4 journalcopy
スレッドにより、以下の処理が実行されます。
- 番号付きのローカルジャーナルファイルにジャーナルレコードを書き込む。 この処理の結果として、いずれのデータベーステーブルもロックされません。
- サーバのルートディレクトリである
statejcopy
ディレクトリ内のファイルを使用して、ソースサーバジャーナル内で最後に読み込まれた位置をトラッキングする。 - スタンバイサーバ上の
statejcopy
ファイルを更新する。
スタンバイサーバを除くレプリカサーバでは、プルスレッドによってstate
ファイルが更新されます。
スタンバイレプリカの概要を以下に示します。
- スタンバイレプリカは、マスタージャーナルの完全なコピーです。
- スタンバイレプリカは、カレントジャーナルの場合であっても、必ず番号付きジャーナルとして表示されます(例:
journal.41
)。
スタンバイサーバの作成
前提条件として、チェックポイントの取得元となるサーバが必要になります。 スタンバイサーバを作成するには、マスターサーバのチェックポイントを使用する必要があります。 チェックポイントが作成されていないマスターサーバのレプリカをスタンバイサーバに変換することはできません。 ここでは、新しく作成するスタンバイサーバのマスターサーバとして、コミットサーバを使用します。
コミットサーバの準備
- コミットサーバで、必要に応じてサービスユーザを追加し、そのサービスユーザの
Type
をservice
に割り当てます。 サービスユーザ名として、Perforceで使用される任意の有効なユーザ名を指定することができます。 (「サービスユーザ」を参照してください)p4 user -f serviceuser
[...]
Type: Service - ユーザ仕様を保存してエディタを終了します。
service
グループを作成し、serviceuser
をそのグループに追加して、Timeout
フィールドの値をunlimited
に設定します。p4 group service
[...]
Timeout: unlimited
[...]Users:
serviceuser
- グループ仕様を保存してエディタを終了します。これにより、ユーザが保存されます。
- サーバ仕様フォームを使用してスタンバイサーバの設定を定義します。 以下に例を示します。
ServerID: commit-standby Type: server Address: {standbyserver host}:{port number} Services: standby Options: nomandatory ReplicatingFrom: {commit-server-ID} Description: Standby server for {commit-server-ID}. DistributedConfig: any#auth.default.method=ldap any#auth.ldap.order.1=popeye any#auth.ldap.userautocreate=1 any#db.monitor.shared=8192 ... any#server.allowpush=2 P4TARGET={server:port} P4TICKETS={/path/to/p4tickets-file} P4LOG={/path/to/logfile} db.replication=readonly lbr.replication=readonly journalPrefix={/path/to/rotated/journal/commit-standby} monitor=1 rpl.journalcopy.location=1 serviceUser={serviceuser-name} startup.1=journalcopy -i 1 startup.2=pull -L -i 1 startup.3=pull -u -i 1
注意次のセクションについて説明します:
DistributedConfig:
- 太字と{斜体}で記載されている値は、サーバ固有の値です。
- 先頭に「
any#
」が指定されている項目は、コミットサーバ上ですでに設定されている構成可能変数です。これらの変数は、すべてのサーバに適用されます。 これらの項目を上記のフォーム内で変更することはできません。- スタンバイサーバが起動して最新の状態になるまで、
Options:
フィールドの値をnomandatory
に設定しておく必要があります。 スタンバイサーバが起動して最新の状態になったら、このフィールドの値をmandatory
に変更してかまいません。 詳細については、「フェイルオーバー」を参照してください。
コミットサーバのチェックポイントを取得します。このチェックポイントを使用して、コミットスタンバイサーバを作成します。
スタンバイサーバの準備
- コミットスタンバイサーバのP4ROOTディレクトリに
server.id
ファイルを作成します。このファイルに、コミットスタンバイサーバのサーバID (commit-standby
)が保存されます。 スタンバイサーバのルートディレクトリに移動して以下のコマンドを入力します。echo commit-standby > server.id
- 以下のコマンドを実行して、サービスユーザをスタンバイサーバが稼働しているマシンからコミットサーバにログインさせます。
p4 -E P4TICKETS={/path/to/p4tickets-file} -u {serviceuser-name} -p {commit-server:port} login
-
コミットスタンバイレプリカサーバを起動します。
- 以下のコマンドを実行して、サーバのステータスを確認します。
p4 -p {standbyserver:port} -Ztag info
serverServices
がstandbyに設定されているかどうか、replica
にコミットサーバのサーバIDとポート番号が表示されているかどうかを確認します。p4 -ztag info
[...]
... ServerID commit-standby
[...]
... replica commit-server:1666
スタンバイサーバのモニタリング
- p4 servers -Jコマンドを使用して、すべてのスタンバイレプリカサーバの複製ステータスを確認します。 例えば、以下のように表示されれば、スタンバイサーバの準備が完全に整ったことになります。
p4 servers -J
commit-standby '2019/09/20 12:49:16' standby 1234/8779 1234/8779 wadL/1 1
詳細な出力情報を表示する場合は、
-Ztag
オプションを指定します。p4 -Ztag servers -J
... ServerID commit-standby
... Updated 2019/09/20 12:49:16
... ServerType standby
... ServerOptions nomandatory
... PersistedJournal 1234
... PersistedSequence 8779
... AppliedJournal 1234
... AppliedSequence 8779
... JAFlags wadL/1
... IsAlive 1 -
p4 journalcopy -lコマンドを使用して、レプリカサーバ上で検出された現在のコピー位置を確認します。
p4 journalcopy -l
Current replica persisted journal state is: Journal 1234, Sequence 8779. -
p4 pull -ljコマンドを使用して、レプリカサーバのメタデータの複製状況を確認します。
p4 pull -lj
Current replica journal state is: Journal 1, Sequence 8779.
Current master journal state is: Journal 1, Sequence 8779.
The statefile was last modified at: 2019/09/20 12:49:16.
The replica server time is currently: 2019/09/20 13:20:11 -0700 PDTこのコマンドを実行すると、ローカルファイルのジャーナルが適用され、レプリカサーバの
state
ファイルが維持されます(このファイルは、レプリカサーバのルートディレクトリに保管されています)。
複製ライセンスの取得
スタンバイサーバは、レプリカサーバのライセンスがなくても稼働させることができますが、スタンバイサーバをスタンバイサービスサーバ(コミットサーバ)として起動しようとすると、ライセンスエラーが発生します。 フェイルオーバーの発生時にこのエラーを防ぐには、フェイルオーバーの計画時にサーバ複製リクエストを送信してください。