このガイドでは、CData Virtuality Server のアップグレードに必要な手順を説明し、すべての設定を新しいバージョンに移行します。手順は多く、時間のかかるものもありますが、サーバーのダウンタイムはアップグレードのプロセスよりもはるかに短くなります!

以下のプロセスは、CData Virtuality の新バージョンが旧バージョンではなく同じサーバーにインストールされることを前提としています(アップグレードがテストされたソース CData Virtuality Server の最低バージョンは 2.0.51です)。

複雑なインストールでは、生産的なサーバーのダウンタイムを最小限に抑えるため、CData Virtuality Server を新しいサーバーインスタンスにインストールし、アップグレードが完了したらインスタンスを入れ替えることをお勧めします。このオプションについては、このガイドでは説明しませんが、サポートチームにお問い合わせください!

いくつかのステップは一般的で必須であり、いくつかのステップはインストールに特定の機能がある場合にのみ必要です(インストールにそれらの機能があるかどうかを確認するには、以下のPre-update Checksセクションを参照してください):

  • 非エンベデッド構成データベースを使用します;
  • LDAP認証を使用します;
  • 旧サーバーの設定にはカスタマイズがありました。

プロセスは複雑に見えるかもしれませんが、私たちのサポートチームがあなたのためにここにいます!アップグレードの予定時期をサポートエンジニアにお知らせいただき、何か問題が発生した場合やガイドに不明な点がある場合は、サポートエンジニアにご連絡ください。

プランニングの便宜のため、すべてのステップをダウンタイム前、ダウンタイム中、ダウンタイム後の3段階に分けています。

Pre-requisites

CData Virtuality Server をアップグレードするために必要なものは以下のとおりです:

  • 新バージョンのCData Virtuality Server リリースパッケージ(サポートチームにお問い合わせください;)
  • What's New ドキュメント(サポートチームがリリースパッケージと一緒に提供します);
  • CData Virtuality Server 管理者アカウントの認証情報(アップグレードを実行するには管理者権限が必要です;)
  • また、古いバージョンから設定をエクスポートするには、ファサード(特別に設計されたクエリのセット)が必要な場合もあります。Facadeファイルが必要かどうかを確認し、バージョンに合ったファイルを入手するには、CData Virtuality Upgrade Utility (Exporter)のドキュメントを参照し、サポートチームにお問い合わせください。

Pre-update Checks

Configuration Database Type

CData Virtuality Server にはPostgreSQL データベースがバンドルされています。ただし、インストールが外部データベースを使用している可能性があります。dvserver/bin/フォルダ内のdvconfig.conf.props(.bat)ファイルを開くことで、インストールで使用するデータベースを確認できます。ポート54322を持つデータベースが構成されている場合、それは組み込みのものであり、そうでない場合は外部のものです。

バージョン2.4からは、組み込みデータベースをデフォルトとして使用することをお勧めします。しかし、外部のPostgreSQLデータベースを使用することも引き続き可能です。

LDAP Authentication

どの認証タイプが使用されているかを確認する手順は次のとおりです:

SELECT * FROM (CALL "SYSADMIN.getAuthMechanism"()) a;;

History and Log Tables

すべての履歴テーブルとログテーブル(SYSLOGスキーマのすべて)は、アップグレード後にリセットされます。古いログを保持したい場合は、履歴テーブルをAnalytical StorageのテーブルにReplicationしてバックアップします。

System Tablesの「Logs and History」セクションに履歴テーブルの詳細情報があります。

Customized Settings

サーバーにパッチが適用されている場合、パッチによってはアップグレードに追加の手順が必要になることがあります。アップグレードを行う前に、サポートチームにご相談ください。

Upgrade Process

  1. Before Downtime

    1. What's Newドキュメントをチェックし、変更点を確認してください(変更点は赤色でハイライトされています)。現在のバージョンを調べ、最新のものと比較してください。 CData Virtuality Synchronization Tool を使用している場合、JDBC ドライバーが変更されると、両方のシステムが更新されるまで同期が停止することがありますのでご注意ください。
    2. このステップは、NetSuite、SAP ADS、SAP HANA、Teradata、または Vertica を使用している場合にのみ適用されます。

      ライセンスの制約により、一部のドライバーはリリースパッケージでは配布されません。そのようなドライバーのリストをチェックし、必要なドライバーをダウンロードして、配置してください。詳細はour documentation on JDBC driversをご覧ください。
    3. 失敗したデータソース、接続、接続、ビュー、プロシージャ、推奨最適化(RecOpts)、ジョブをチェックし、DWH テーブル(例:dwh.update_log_failed_objects)にエクスポートします。このチェックの出力は、アップグレード後の検証に使用されるため、これは重要です - 新しいオブジェクトが壊れていないかどうかを識別するためです。
      これを行うには、CData Virtuality Server のバージョンに応じて、以下のコマンドのいずれかを使用します:

      1. 2.1.19以下:

        SELECT name, translator AS details, 'DataSource' AS type
        FROM "SYSADMIN.DataSources"
        WHERE failed = true
        UNION
        SELECT name, properties AS details, 'Connection' AS type
        FROM "SYSADMIN.Connections"
        WHERE failed = true
        UNION
        SELECT name, failureReason AS details, 'View' AS type
        FROM "SYSADMIN.ViewDefinitions"
        WHERE state <> 'READY'
        UNION
        SELECT name, failureReason AS details, 'Proc' AS type
        FROM "SYSADMIN.ProcDefinitions"
        WHERE state <> 'READY'
        UNION
        SELECT "MatchDescriptor" AS name, 'sourceState: ' || "sourceState" || ', sourceStateComment: ' || "sourceStateComment" || ', ' || "dwhStateComment" || ', lastReplicationState: ' || "lastReplicationState" || ', lastReplicationStateComment: ' || "lastReplicationStateComment" AS details, 'RecOpt' AS type
        FROM "SYSADMIN.RecommendedOptimizations"
        WHERE "sourceState" <> 'OK' OR "dwhState" <> 'OK' OR "lastReplicationState" <> 'OK'
        UNION
        SELECT "description" AS name, 'jobType: ' || "jobType" || ', lastExecutionStatus: ' || lastExecutionStatus || ', lastExecutionFailureReason: ' || "lastExecutionFailureReason" AS details, 'Job' AS type
        FROM "SYSADMIN.ScheduleJobs"
        WHERE "lastExecutionStatus" <> 'SUCCESS'
        ORDER BY type;;
      2. 2.1.19以上:

        SELECT * FROM SYSADMIN.FailedObjects;;
    4. 新しいCData Virtuality Server リリースをダウンロードし、一時ディレクトリに解凍します。Windows 上で動作する CData Virtuality Server をzip アーカイブを使用してアップグレードする場合、解凍する前にアーカイブファイルのブロックを解除してください(ファイルのプロパティを右クリックし、コンテキストメニューから「Unblock」を選択)。
    5. <新しいCData Virtuality Server リリースフォルダ>/dvserver/bin/cli-export-1.0 に移動し、export.sh(Linux の場合)またはexport.bat(Windows の場合)を実行します。これにより、エクスポート用のCLI ファイルとSQL ファイルが生成されます。
      以下は両オペレーティングシステムの呼び出しです:

      1. Linux用:

        ./export.sh --username <account with admin permissons> --password <password> --host localhost --export-jboss-settings true --use-model-file true --use-maintenance-mode true [--dv-facade-file <path to facade file>]


      2. Windows用:

        export.bat --username <account with admin permissons> --password <password> --host localhost --export-jboss-settings true --use-model-file true --use-maintenance-mode true [--dv-facade-file <path to facade file>]

        コマンド実行後、ファイルが作成され、空でないことを確認してください。エクスポートが生成されない場合は、続行する前に弊社サポートチームまでご連絡ください。

    6. この手順は、2.3.3 以下の古いバージョンのData Virtuality Server を使用している場合にのみ適用されます。

      JBossの設定を取得し、バッファ、同時実行、JDBC、ODBC(これらがカスタマイズされている場合は)とログインモジュール(LDAP認証が使用されている場合は)のCLIファイルにエクスポートします。 
      このコマンドは次のとおりです:

      BEGIN
      DECLARE string result;
      DECLARE string smtpCli='';
      DECLARE string bufferCli='';
      DECLARE string concurrencyCli='';
      DECLARE string jdbcdbcCli='';
      DECLARE string loginCli='';
       
      --Buffer Service settings
      bufferCli='connect';
      LOOP ON (SELECT a.setting
      FROM TEXTTABLE('"buffer-service-connector-batch-size"
      "buffer-service-inline-lobs"
      "buffer-service-max-buffer-space"
      "buffer-service-max-file-size"
      "buffer-service-max-open-files"
      "buffer-service-max-processing-kb"
      "buffer-service-max-reserve-kb"
      "buffer-service-max-storage-object-size"
      "buffer-service-memory-buffer-off-heap"
      "buffer-service-memory-buffer-space"
      "buffer-service-processor-batch-size"
      "buffer-service-use-disk"'
      COLUMNS setting string )as a) as cur
      BEGIN
      result = SELECT reply FROM ((EXEC "SYSADMIN.executeCli"(
      "script" => '/subsystem=teiid:read-attribute(name=' || cur.setting || ')'
      ))as a);
      result = '/subsystem=teiid:write-attribute(name='||cur.setting || ',value="' ||
      (SELECT XPATHVALUE(JSONTOXML('setting', REPLACE(REPLACE(result,'=>',':'),'L','')),'setting/result')) || '")';
      bufferCli = bufferCli || '
      ' || result;
      END
      --Concurrency settings
      concurrencyCli='connect';
      LOOP ON (SELECT a.setting
      FROM TEXTTABLE('"max-active-plans",
      "max-threads"
      "time-slice-in-millseconds"
      "thread-count-for-source-concurrency"'
      COLUMNS setting string )as a) as cur
      BEGIN
      result = SELECT reply FROM ((EXEC "SYSADMIN.executeCli"(
      "script" => '/subsystem=teiid:read-attribute(name=' || cur.setting || ')'
      ))as a);
      result = '/subsystem=teiid:write-attribute(name='||cur.setting || ',value="' ||
      (SELECT XPATHVALUE(JSONTOXML('setting', REPLACE(result,'=>',':')),'setting/result')) || '")';
      concurrencyCli = concurrencyCli || '
      ' || result;
      END
      --JDBC and ODBC settings
      jdbcdbcCli='connect';
      LOOP ON (SELECT a.setting
      FROM TEXTTABLE('"jdbc"
      "jdbc-ssl"
      "odbc"
      "odbc-ssl"'
      COLUMNS setting string )as a) as cur
      BEGIN
      result = SELECT reply FROM ((EXEC "SYSADMIN.executeCli"(
      "script" => '/subsystem=teiid/transport=' || cur.setting || ':read-resource'
      ))as a);
      result=REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(result,'>',''),'{',''),'}',''),' ',''),'"outcome"="success",','');
      result=REPLACE(REPLACE(REPLACE(REPLACE(result,'"result"=',''),'"',''),CHAR(10),''),CHAR(13),'');
      --result=SUBSTRING(result,0,LOCATE(',response-headers',result)-1);
      result = '/subsystem=teiid/transport=' || cur.setting || ':remove' || '
      /subsystem=teiid/transport=' || cur.setting || ':add(' || result || ')';
      jdbcdbcCli = jdbcdbcCli || '
      ' || result;
      END
      --Login Module settings
      loginCli='connect';
      result = SELECT reply FROM (EXEC "SYSADMIN.executeCli"(
      "script" => '/subsystem=security/security-domain=teiid-security/authentication=classic:read-attribute(name=login-modules)'))as a;
      result = REPLACE(REPLACE(result,CHAR(10),''),CHAR(13),'');
      result = REPLACE(result,' ','');
      declare integer startIndex = LOCATE('[',result);
      result = select SUBSTRING(result,startIndex,LENGTH(result)-startIndex);
      result = '/subsystem=security/security-domain=teiid-security/authentication=classic:write-attribute(name=login-modules, value=' || result;
      loginCli = loginCli || '
      ' || result;
      SELECT bufferCli as Buffer, concurrencyCli as Concurrency, jdbcdbcCli as JdbcOdbc, loginCli as Login;
      END;;
    7. LDAP認証を使用する場合は、dvconfigからデフォルトの管理者ロールを取得します。これを行うには、dvconfigに接続します:

      1. config db への接続(パスワードは"dvconfig"): <CData Virtuality インストールフォルダ>/ dvserver/pgsql/bin/psql -h localhost -p 54322 -U dvconfig dvconfig(Linux の場合)または<CData Virtuality Installation Folder>\ DVServer\pgsql\bin\psql.exe -h localhost -p 54322 -U dvconfig(Windows の場合);

      2. SELECTステートメントを実行します:

        1. ソースバージョン2.3.xおよび2.4.1用:

          SELECT * FROM <dv configuration schema>.dv__ldap_permissions WHERE id = 1;
        2. ソースバージョン2.4.2の場合:

          SELECT * FROM <dv configuration schema>.dv__ldap_permissions WHERE deleteonrestart=true;


          <dv configuration schema> は、組み込み構成データベース用のpublicです。非エンベデッドConfigの場合、通常はdvconfigですが、コンフィギュレーションごとに異なる場合があります。dvconfig.conf.props(.bat)またはstandalone.conf.props(.bat)を参照して、システムの Configuration を確認してください。

    8. このステップは、組み込みでない設定データベースを引き続き使用する場合にのみ適用されます。

      max_connectionsが >= 100 に設定されているか確認し、データウェアハウスが同じ PostgreSQL インスタンス上にある場合は 200 に設定してください。
    9. このステップは、組み込みでない設定データベースを引き続き使用する場合にのみ適用されます。

      古いdvserver-standalone.xmlファイルに従って、CData Virtuality ですでに使用されているユーザーの下で、PostgreSQL インスタンスに設定用の新しいデータベース を作成します(通常のパターンはdv_r<release>_config、例えば dv_r2039_config です)。
    10. 新しいリリースフォルダ<新しいCData Virtuality Server リリースフォルダ>/dvserver/standalone/data/datavirtualityからlicense.licファイルを削除します(更新された CData Virtuality Server でも有効なライセンスがすでにあるため、必要ありません)。
    11. このステップは、組み込みでない設定データベースを引き続き使用する場合にのみ適用されます。

      古いdvconfig.conf.props(.bat)ファイルをコピーし、ファイル内のデータベース(例: dv_r231_config )を変更します。探すべき設定は Ddv.dvconfig.db=
    12. standalone.conf.props(.bat) ファイルを旧サーバーから新サーバーにコピーし、config db 設定があれば削除します。
    13. standalone.conf(.bat) ファイルに、以前のバージョンからの追加設定を追加します(古いanalytic_storage_on_different_host_dv の値を確認します)。
    14. 旧サーバーが非標準の SSL 証明書をインポートしていた場合、これらの証明書を新サーバーにも追加する必要があります。証明書ストアファイルの名前は<CData Virtuality インストールフォルダ>/dvserver/JDK/lib/security/cacerts です。そのためのオプションは2つあります:
      1. オリジナルの証明書ファイルのコピーをお持ちの場合は、 documentation;の説明に従って証明書ストアにインポートしてください。
      2. 旧リリースからcacerts という名前のバンドルされている Java keystore ファイルをコピーします(既存のcacertsファイルをまずバックアップしてください)。2.4以下のバージョンでは、<CData Virtuality インストールフォルダ>/dvserver/JDK/jre/lib/security/cacertsフォルダにあり、2.4では、<CData Virtuality インストールフォルダ>/dvserver/JDK/lib/security/cacerts にあります。ファイルを<CData Virtuality インストールフォルダ> /dvserver/JDK/lib/security/ フォルダ 内に コピーしてください。2番目のアプローチでは、新しいJavaバージョンに付属する更新された証明書の一部が使用されないため、可能であれば1番目のアプローチを使用することをお勧めします。
    15. 組み込みJDK、組み込みPostgresデータベース、WildFly設定など、DVコンポーネントにカスタムまたは上記以外の変更がある場合は、これらの設定を新しいシステムに転送します。
    16. dvserver フォルダと子アイテムのPermission を変更します(比較のため、古いリリースフォルダのPermission と照合します)。これはLinuxでは必須です(chown -R datavirtuality:datavirtuality dvserverを使用できます)。Windowsでは、特別な要件がない限り、通常は必要ありません。
    17. アップグレードでは、監査ログ情報は保持されません。必要に応じて、監査テーブルの内容はアップグレード中に転送されないため、古いサーバーから監査ログテーブルを別のデータベースにエクスポートします。監査テーブルは CData Virtuality Server のSYSLOG スキーマにあります。将来のために保存する必要のある情報を含むTablesをエクスポートまたはコピーしてください。 
  2. During Downtime

    1. CData Virtuality Server をシャットダウンします。
    2. 組み込みPostgreSQLデータベース(プロセスは<CData Virtuality インストールフォルダ>/dvserver/pgsql/bin/postgres(Linuxの場合)、postgres.exe(Windowsの場合))が、古いサーバーのシャットダウン後に停止していることを確認します。
      そうでない場合は、 <CData Virtuality インストールフォルダ>/dvserver/pgsql/embeddedPg_stop.bat または <CData Virtuality インストールフォルダ>/dvserver/pgsql/embeddedPg_stop.sh を使用して手動でシャットダウンします。その後、PostgreSQLデータベースがまだ実行されている場合は、  Linuxではkill kill -9  コマンドを、Windowsではtaskkill コマンドを使用してください。 
    3. 古いサーバーのフォルダの名前を変更し(例えば、バージョン番号を名前に追加する)、新しいサーバーを最終的な場所に移動します。
    4. CData Virtuality Server を起動します。

    5. 標準認証を使用している場合:この時点で、CData Virtuality Server は標準的な認証情報(admin/admin)で設定されています。先に進む前に管理者パスワードを変更してください。
    6. LDAP 認証を使用している場合config db に接続します(パスワードは"dvconfig"): <CData Virtuality インストールフォルダ>/dvserver/pgsql/bin/psql -h localhost -p 54322 -U dvconfig dvconfig

    7. コマンドラインからCLIファイル経由でJBoss設定をインポートします。これが必要なファイルです:

      <Data Virtuality Installation Folder>/dvserver/bin/jboss-cli.sh --file=<...>/yyyy-mm-dd-hh_mm_ss_dv_jboss_config_buffer.cli
      <Data Virtuality Installation Folder>/dvserver/bin/jboss-cli.sh --file=<...>/yyyy-mm-dd-hh_mm_ss_dv_jboss_config_concurrency.cli
      <Data Virtuality Installation Folder>/dvserver/bin/jboss-cli.sh --file=<...>/yyyy-mm-dd-hh_mm_ss_dv_jboss_config_jdbc_odbc.cli
      <Data Virtuality Installation Folder>/dvserver/bin/jboss-cli.sh --file=<...>/yyyy-mm-dd-hh_mm_ss_dv_jboss_config_login_module.cli
    8. LDAP 認証を使用している場合dvserver-standalone.xmlファイルを編集します。正しいログインモジュールを検索し、<defaultAdminGroup>要素を追加します。値はステップ2.6で読み込んだRoleでなければなりません。
      詳しくはLDAP authenticationをご覧ください。

    9. CData Virtuality Server を再起動します。
    10. DSQL(CData Virtuality command-line client)でデータソースをインポートします。必要なファイルはyyyy-MM-dd_hh_mm_ss_dv-export-datasources.sql、以下はインポートの呼び出し例です:

      1. Linux用:

        ./dsql.sh -u <account with admin permissions> -p <password> -h localhost --sourcefile <path to SQL file>


      2. Windows用:

        ./dsql.bat username=<account with admin permissions> password=<password> host=localhost sourcefile=<path to SQL file>
    11. DSQLを使用したスキーマ、ビュー、およびプロシージャのリストア(ファイルyyyy-MM-dd_hh_mm_ss_dv-export-views-and-procedures.sql)。
    12. CData Virtuality Server のバージョンが2.4.15 より古い場合:
      1. yyyy-MM-dd_hh_mm_ss_dv-export-etc.sql ファイルをテキストエディタで開きます。
      2. そしてEXEC SYSADMIN.setDefaultOptionValue("opt" => 'ALLOW_CARTESIAN', "val" => '...') OPTION $NOFAIL.
        コマンドを検索します。
      3. valINTERNAL またはEXPLICIT の場合は、そのコマンドをコメントアウトするか削除してください。
    13. DSQL(ファイルyyyy-MM-dd_hh_mm_ss_dv-export-etc.sql)を使用して、最適化、ジョブ、スケジュールをリストアします。
    14. システムジョブ(ジョブタイプが "Backup"、"Cleanup"、"Performance "のすべてのジョブ)のスケジュールに重複がないか確認してください。システムジョブのスケジュールが重複している場合は、削除します。 
    15. このコマンドを使用してパフォーマンス・カウンターをDELETEします:

      EXEC "SYSLOG.clearPerformanceLogs"();;

      これでダウンタイムは終わり、事実上アップグレードも終了です。残りのステップは、すべてがうまく機能していることを確認するためのさまざまなチェックと、いくつかの後片付けです。

  3. After Downtime

    1. バックアップ・ジョブが実行され、バックアップSQLファイルが生成されることを確認します。また、バックアップSQLファイルがdvserver ディレクトリに直接保存されていないことを確認してください。例えば、<CData Virtuality Installation Folder>/dvserver/backups ではなく、/home/<username>/backups、C:\Backups、またはCData Virtuality フォルダ外の同様の場所)。バージョン2.3.13以降、CData Virtuality Server にはデフォルトのバックアップシステムジョブがあります。このジョブを構成し(SQLを使用)、以前のバックアップ・ジョブを無効にします。 
    2. サーバーがダウンしたために実行されなかったジョブを手動で実行します(ジョブの数が妥当な場合はすべて)。
    3. 新しいCData Virtuality Studio をインストールします。
    4. CData Virtuality Studio でサーバーに接続します。
    5. 必要に応じて、失敗したオブジェクトをUPDATE前の状態と比較し、データソース(モジュラー・コネクタ展開)、プロシージャ、ビュー、ジョブ、およびOptimizationの順に修復します。

以上です!LDAP認証を使用している場合、または古いサーバーに特定のカスタム変更があった場合は、追加の手順が必要です:

  • LDAP 認証を使用していない場合は、管理者パスワードをデフォルトのものから変更します;
  • 組み込み Web サーバーの HTTPS を構成するために旧サーバーにカスタマイズが適用されている場合は、それらを新サーバーに移行します;
  • カスタマイズがdefault portsに適用されている場合は、それらを新しいサーバーに移行します;
  • 匿名SSLモードが1ウェイまたは2ウェイSSLに変更されている場合は、それらの設定を新しいサーバーに移行します;
  • カスタマイズがproxy configurationに対して適用されている場合は、それらを新しいサーバーに移行します。

Rollback

このセクションでは、アップグレードを元に戻す方法を説明しますが、先に進む前に、ロールバックは最後の手段であるべきであることを指摘しておきたいと思います。アップグレード中に何か問題が発生した場合は、サポートチームまでご連絡ください!

とはいえ、これがロールバックの実行方法です:

  1. サーバーが起動している場合は停止します。
  2. 組み込みPostgreSQLデータベース(プロセスは<CData Virtuality インストールフォルダ>/dvserver/pgsql/bin/postgres(Linux の場合)、postgres.exe(Windows の場合))が、古いサーバーのシャットダウン後に停止していることを確認します。
    そうでない場合は、 <CData Virtuality インストールフォルダ>/dvserver/pgsql/embeddedPg_stop.bat または <CData Virtuality インストールフォルダ>/dvserver/pgsql/embeddedPg_stop.sh を使用して手動でシャットダウンします。その後、PostgreSQLデータベースがまだ実行されている場合は、  Linuxではkill kill -9  コマンドを、Windowsではtaskkill コマンドを使用してください。 
  3. dvserver フォルダの名前をdvserver_<newRelease>_<date> に変更します(例:dvserver_241_2021-03-01)。
  4. Linux上でこのコマンドを実行するか、Windowsエクスプローラーで同様の操作を行って、古いdvserverフォルダを解凍します:

    cd /opt/datavirtuality
    unzip dvserver.zip
  5. CData Virtuality Server を起動します。