Helix Coreサーバ管理者ガイド: 基本 (2019.1)

2013.3以降のバージョンから2019.1へのアップグレード(分散環境)

2019.1へのアップグレード手順は、以前のリリースとは異なります。

注意

新しいdb.storageテーブルがdb.archmapを置換して、サーバ上のアーカイブファイルのリンク数を表示します。これにより、+Snタイプファイルが遅延コピーでき、ディスクスペースを節約することができます。また、アップグレードにより、特に重要な反映履歴のあるサーバ上では、p4 obliterateのパフォーマンスも向上します。

これらの手順は、分散環境下にあるユーザを対象にしています。該当しない場合は、「2013.3以降のバージョンから2019.1へのアップグレード(単一サーバ)」を参照してください。

注意
  • プロキシまたはブローカは、最新のバイナリを入手する場合にのみ必要です。
  • すべてのサーバやレプリカに対して、p4d -xuを実行する必要があります。
  • オフラインのdb.*ファイルに対しては、p4d -xuを実行する必要はありません。

前提条件

重要

Helixサーバを新しいバージョンにアップグレードするには、Helixサーバのライセンスファイルが有効である必要があります。

  1. 時間:
      アップグレードの
    • フェーズ1では、サーバを数分間停止する必要があります。
    • アップグレードの
    • フェーズ2では、バックグラウンドで動作するため、ユーザは作業することができます。このフェーズには数時間かかる場合があります。db.storageテーブルが作成され、その内容が外部サーバに複製されている間は、パフォーマンスが低下する場合があります。
      • 200 GBを超えるdb.revテーブルがある環境では、完了までに数時間かかる場合があります。

      • 小規模な環境では、数分で完了します。
  2. 使用可能なディスク領域は、db.revテーブルのサイズと同等以上である必要があります。(ジャーナルファイルは新しいdb.storageテーブルのサイズまで増大する可能性があります。通常、ジャーナルは独立したパーティション上にあります。)
  3. アップグレードされた新しいテーブルを他のサーバにコピーする処理は、ジャーナルの複製によって行われるため、ジャーナル作成が有効になっていることを確認します。
  4. 1回のアップグレードセッションですべてのサーバをアップグレードする準備をします。
重要
  • 一部のサーバを他のサーバと異なるバージョンにすることはできなくなりました。
  • アップグレード中に問題が発生した場合に復旧できるよう、チェックポイントを作成することをお勧めします。(「チェックポイントファイル」を参照してください。)エンドユーザがアクティブでないときにチェックポイントを作成することをお勧めします。
  • すべてのサーバがメンテナンスのために数分停止し、その後数時間パフォーマンスが低下する可能性があり、以下のコマンドがブロックされることをユーザに知らせます。

アップグレードの手順

以下の手順を実行して、次のように置き換えます

  • [P4ROOT]を、P4ROOTディレクトリのパスに置き換えます
  • [P4JOURNAL]を、ジャーナルファイルのディレクトリパスと名前に置き換えます

コミットエッジの場合は、「最も内側のサーバ」はコミットサーバで、外部サーバはエッジサーバです。標準サーバおよびその標準サーバのレプリカの場合は、「最も内側のサーバ」は標準サーバです。

  • アップグレード処理は最も外側のサーバから最も内側のサーバに向かって進行します。
  • 再起動は最も内側のサーバから最も外側のサーバに向かって進行します。

最も外側のサーバ上での処理

  1. p4 admin stopを実行してサーバをシャットダウンします
  2. システムにp4dバイナリの19.1バージョンをインストールします
  3. p4d -r [P4ROOT] -J [P4JOURNAL] -xuを実行します
  4. この一連のメッセージが完全に表示されるまで待機します。最初のメッセージの後に一時停止する場合があります。
    2019.1: building db.storage from db.rev, db.revsh and db.revtx
    [一時停止]
    2019.1: Adding default namespace to Extension configurations
    ...upgrades done
  5. サーバがダウンした状態のままにします。

最も外側のサーバと最も内側のサーバ間のサーバの処理

  1. p4 admin stopを実行してサーバをシャットダウンします

  2. システムにp4dバイナリの19.1バージョンをインストールします
  3. p4d -r [P4ROOT] -J [P4JOURNAL] -xuを実行します
  4. この一連のメッセージが完全に表示されるまで待機します。最初のメッセージの後に一時停止する場合があります。
    2019.1: building db.storage from db.rev, db.revsh and db.revtx
    [一時停止]
    2019.1: Adding default namespace to Extension configurations
    ...upgrades done
  5. サーバがダウンした状態のままにします。

最も内側のサーバでの処理

フェーズ1

  1. p4 admin stopを実行してサーバをシャットダウンします

  2. システムにp4dバイナリの19.1バージョンをインストールします
  3. p4d -r [P4ROOT] -J [P4JOURNAL] -xuを実行します
  4. この一連のメッセージが完全に表示されるまで待機します。最初のメッセージの後に一時停止する場合があります。
    2019.1: building db.storage from db.rev, db.revsh and db.revtx
    [一時停止]
    2019.1: Adding default namespace to Extension configurations
    ...upgrades done
  5. 最も内側のサーバを起動すると、Helixサーバ schemaの新しいテーブルであるdb.storageテーブルを構築するためのプロセスをバックグラウンドで開始します。

  6. 最も内側のサーバと最も外側のサーバ間のサーバを起動します。
  7. 最も外側のサーバを起動します。
  8. 作業が再開できるようになったことをユーザに知らせます。

フェーズ2

  1. バックグラウンドアップグレードプロセスが完了したことを知るには、最も内側のサーバでp4 storage -wを実行します。
  2. p4 storage -wが次のメッセージを返すまで待機します。「The storage upgrade process is complete」。
  3. 進行状況を監視するには、別のコマンドライン端末上で、ls -l db.storageを時々実行して、タイムスタンプまたはファイルサイズが増加していることを確認します。