Helix Coreサーバ管理者ガイド (2020.1)

 

スタンバイサーバと転送スタンバイサーバ

バージョン2019.1のHelix Coreサーバ2019.1では、スタンバイサーバ(または転送スタンバイサーバ)の複製機能が改善され、読み取り専用レプリカサーバを使用する場合の利便性が高くなりました。以下に、具体的なメリットを示します。

  • マスターサーバで障害が発生しても、トランザクションが失われることはありません。
  • p4 pullコマンドを実行する際に、データベースをロックする必要がなくなりました。
  • p4 pullコマンドがスリープ状態になる前に、すべてのジャーナルレコードがプルされます。

スタンバイサーバにより、pullコマンドのプロセスがp4 journalcopyコマンドとp4 pull -Lコマンドに分割されます。

p4 journalcopyスレッドにより、以下の処理が実行されます。

  • 番号付きのローカルジャーナルファイルにジャーナルレコードを書き込む。 この処理の結果として、いずれのデータベーステーブルもロックされません。
  • サーバのルートディレクトリであるstatejcopyディレクトリ内のファイルを使用して、ソースサーバジャーナル内で最後に読み込まれた位置をトラッキングする。
  • スタンバイサーバ上のstatejcopyファイルを更新する。

スタンバイサーバを除くレプリカサーバでは、プルスレッドによってstateファイルが更新されます。

スタンバイレプリカの概要を以下に示します。

  • スタンバイレプリカは、マスタージャーナルの完全なコピーです。
  • スタンバイレプリカは、カレントジャーナルの場合であっても、必ず番号付きジャーナルとして表示されます(例: journal.41)。

スタンバイサーバの作成

前提条件として、チェックポイントの取得元となるサーバが必要になります。 スタンバイサーバを作成するには、マスターサーバのチェックポイントを使用する必要があります。 チェックポイントが作成されていないマスターサーバのレプリカをスタンバイサーバに変換することはできません。 ここでは、新しく作成するスタンバイサーバのマスターサーバとして、コミットサーバを使用します。

コミットサーバの準備

  1. コミットサーバで、必要に応じてサービスユーザを追加し、そのサービスユーザのTypeserviceに割り当てます。 サービスユーザ名として、Perforceで使用される任意の有効なユーザ名を指定することができます。 (「サービスユーザ」を参照してください)

    p4 user -f serviceuser
    [...]
    Type: Service

  2. ユーザ仕様を保存してエディタを終了します。
  3. serviceグループを作成し、serviceuserをそのグループに追加して、Timeoutフィールドの値をunlimitedに設定します。
    p4 group service
    [...]
    Timeout: unlimited
    [...]

    Users:
    serviceuser
  4. グループ仕様を保存してエディタを終了します。これにより、ユーザが保存されます。
  5. サーバ仕様フォームを使用してスタンバイサーバの設定を定義します。 以下に例を示します。
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に変更してかまいません。 詳細については、「フェイルオーバー」を参照してください。

コミットサーバのチェックポイントを取得します。このチェックポイントを使用して、コミットスタンバイサーバを作成します。

スタンバイサーバの準備

  1. コミットスタンバイサーバのP4ROOTディレクトリにserver.idファイルを作成します。このファイルに、コミットスタンバイサーバのサーバID (commit-standby)が保存されます。 スタンバイサーバのルートディレクトリに移動して以下のコマンドを入力します。

    echo commit-standby > server.id

  2. 以下のコマンドを実行して、サービスユーザをスタンバイサーバが稼働しているマシンからコミットサーバにログインさせます。

    p4 -E P4TICKETS={/path/to/p4tickets-file} -u {serviceuser-name} -p {commit-server:port} login

  3. コミットスタンバイレプリカサーバを起動します。

  4. 以下のコマンドを実行して、サーバのステータスを確認します。

    p4 -p {standbyserver:port} -Ztag info

  5. serverServicesがstandbyに設定されているかどうか、replicaにコミットサーバのサーバIDとポート番号が表示されているかどうかを確認します。

    p4 -ztag info
    [...]
    ... ServerID commit-standby
    [...]
    ... replica commit-server:1666

スタンバイサーバのモニタリング

  1. 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

  2. p4 journalcopy -lコマンドを使用して、レプリカサーバ上で検出された現在のコピー位置を確認します。

    p4 journalcopy -l
    Current replica persisted journal state is: Journal 1234, Sequence 8779.

  3. 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ファイルが維持されます(このファイルは、レプリカサーバのルートディレクトリに保管されています)。

複製ライセンスの取得

スタンバイサーバは、レプリカサーバのライセンスがなくても稼働させることができますが、スタンバイサーバをスタンバイサービスサーバ(コミットサーバ)として起動しようとすると、ライセンスエラーが発生します。 フェイルオーバーの発生時にこのエラーを防ぐには、フェイルオーバーの計画時にサーバ複製リクエストを送信してください。