インストーラアップグレード
ThingWorx Foundation インストーラを使用して ThingWorx Foundation 8.5.0 以降をインストールした場合、インストーラを使用して ThingWorx Foundation をアップグレードできます (メンテナンスリリースのアップグレードも可能です)。各 ThingWorx バージョンでサポートされているアップグレードマトリックスへのリンクについては、ThingWorx のアップグレードを参照してください。
 |
ThingWorx 9.4 以降では、ThingWorx 8.5 または ThingWorx 9.0 から ThingWorx 9.4.0 に直接アップグレードできません。ThingWorx 8.5 または ThingWorx 9.0 から ThingWorx 9.4.0 以降にアップグレードするには、中間バージョンにアップグレードしてから、ThingWorx 9.4.0 以降にアップグレードする必要があります。ThingWorx は、最新の ThingWorx 9.3.x を中間アップグレードパスとして使用することをお勧めします。
|
|
|
ThingWorx 9.2 と PostgreSQL 13 にアップグレードする場合、アップグレードプロセスの最後の手順として PostgreSQL をアップグレードする必要があります。
|
|
|
アップグレードを実行するユーザーは、アプリケーションの最初のインストールを実行したユーザーと同じでなければなりません。
|
A.) 必要条件
• Java の要件 (インストーラによってインストールの一環として Java がパッケージ化またはインストールされることはありません)。
◦ ThingWorx を最初にインストールしたユーザーがアップグレードを実行する必要があります。初回インストール時に、インストーラによって ThingWorxFoundation.xml ファイルが生成されます。このファイルにはインストール関連情報が含まれており、アップグレードの際にこの情報が必要となります。このファイルは、インストールを実行したユーザーのユーザープロファイルの下にあります。たとえば、C:\Users\Administrator\.ptc_cci 内にあります。
◦ ThingWorx Foundation 9.2 には Java 11 が必要ですが、Java 8 もインストールされている必要があります。インストーラを実行する前に、Java 8 および 11 のサポートされているバージョンがインストールされていることを確認します。Java 11 を PATH 環境変数に追加します。
◦ Java 8 で ThingWorx 9.0 以下を実行しているときに ThingWorx 9.2 にアップグレードする場合、Java 11 を事前にインストールする必要がありますが、ThingWorx を新しい jvm に切り替えないでください。JAVA_HOME は Java 8 フォルダに設定されたままにする必要があります。両方の Java ディレクトリが PATH 環境変数に含まれ、PATH 変数で java8/bin が java11/bin の前にリストされている必要があります。ThingWorx 9.2 では Java 8 がサポートされていないので、9.2 へのアップグレード中に、使用する Java のバージョンも Java 11 に切り替えられます。
◦ ThingWorx 9.1 を実行している場合、Java 8 と Java 11 がサポートされているので、上記のアドバイスに従うか (両方をインストールし、両方をパスに含める)、アップグレードを開始する前に ThingWorx 9.1 のインスタンスを Java 11 にマイグレーションできます。
• データベースをバックアップします。インストーラーはアップグレードプロセス中にデータベースバックアップを実行しません。
• 以下のオペレーティングシステムとデータベースのいずれかの組み合わせを使用する必要があります。
◦ Windows と PostgreSQL
◦ Windows と Microsoft SQL Server
◦ Red Hat Enterprise Linux と PostgreSQL
◦ Red Hat Enterprise Linux と Microsoft SQL Server
バージョン情報については、システム要件を参照してください。
• データテーブルでカスタムインデックスフィールドの値が不足している場合、アップグレードは失敗します。アップグレードプロセスを開始する前に、すべてのカスタムインデックスフィールドに値が設定されていることを確認してください。
B.) ThingWorx Upgrade Ready ユーティリティの実行
ThingWorx Foundation 8.5.3 以前がインストールされている場合、最初に ThingWorx Upgrade-Ready ユーティリティを実行する必要があります。これは > > > > > から入手できます。
ThingWorx Upgrade-Ready ユーティリティによって、ThingWorx Foundation および ThingWorx Flow (インストールされている場合) の自動アップグレードをサポートするために必要な XML ファイルが作成されます。システム上の ThingWorx Foundation および ThingWorx Flow (インストールされている場合) の場所を尋ねるプロンプトが表示され、選択したインストールが設定されます。これにより、ユーザープロファイルに ThingWorxFoundation.xml ファイルと、ThingWorx Flow がインストールされている場合には ThingWorxFlow.xml ファイルが作成されます。これらのファイルは、ユーザープロファイルの .ptc_ccif フォルダに保存されます (たとえば、Windows: C:\Users\Administrator\.ptc_ccif、Linux: ~/.ptc_ccif/)。
インストーラを使用して ThingWorx 8.5.4 以降をインストールした場合、必要な XML ファイルはインストールの一部としてすでに作成されています。したがって、ThingWorx Upgrade-Ready ユーティリティを実行する必要はありません。
トラブルシューティング
• インストーラを使用して ThingWorx Foundation 8.5.3 以前のバージョンをインストールした後でそれ以降の 8.5.x バージョンに手動でアップグレードしており、ThingWorx Upgrade Ready ユーティリティを実行することで 9.x にアップグレードする準備を行う場合、以下の操作を行います。
◦ ThingWorx Upgrade-Ready ユーティリティを実行します。
◦ ユーザープロファイル内の ThingWorxFoundation.xml ファイルで <applicationVersion> プロパティの値が現在のバージョンであることを確認します。
• ThingWorx Upgrade-Ready ユーティリティの実行中に問題が発生し、ThingWorxFoundation.xml ファイルを手動で作成または編集する必要がある場合、アップグレードのパスに基づいて以下の例を更新して使用できます。
<?xml version="1.0" encoding='utf-8'?>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
C.) アップグレード
1. 上記のセクションで説明されている必要条件が満たされていることを確認します。
2. オンプレミスインストール用の最新の ThingWorx Foundation インストーラファイルを、support.ptc.com の「ソフトウェアのダウンロード」 > 「ソフトウェアアップデートのご注文またはダウンロード」 > 「ThingWorx Foundation」 > 「Release x.x」 > 「ThingWorx PostgreSQL」または「ThingWorx Mssql」からダウンロードして取得します。
3. 以下のような既存のインストール情報が表示されます。
◦ インストールディレクトリ
◦ ポート
◦ SSL コンフィギュレーション設定
◦ SSO コンフィギュレーション設定
4. PTC ライセンス契約が表示されます。アップグレードを続行するには、契約の条項に同意する必要があります。
5. ThingWorx Foundation 管理者のパスワードを入力するか、SSO が設定されている場合、アプリケーションキーを入力する必要があります。
6. インストールのコンフィギュレーション情報を確認できます。
7. インストーラによってアップグレードが実行されます。
以上で、拡張機能とアプリケーションを互換性のあるバージョンにアップグレードできるようになりました。
D.) タイムゾーンデータのマイグレーション
| | ThingWorx 9.4.0 以降にアップデートするとき、タイムゾーンデータをマイグレーションする必要はありません。ThingWorx 8.5 または ThingWorx 9.0 から ThingWorx 9.4 への直接アップグレードはサポートされていません。タイムゾーンのマイグレーションは、中間バージョンへのマイグレーションプロセス中に行われます。 |
以下のいずれかに当てはまる場合、このセクションの重要なデータマイグレーション手順を実行する必要があります。
• ThingWorx 8.5.x がインストールされており、インストーラを使用して ThingWorx 9.0.x または 9.1 にアップグレードしている。
• ThingWorx 9.0.x がインストールされており、インストーラを使用して ThingWorx 9.0.3 以降にアップグレードしている。
このデータマイグレーションを実行するには、以下の操作を行います。
1. アップグレードが成功した後ただちに、ThingWorx と Apache Tomcat を停止します。
2. お使いのオペレーティングシステムに基づいて、以下の手順を使用してタイムゾーンパラメータ -Duser.timezone=UTC を手動で設定します。
Windows でのタイムゾーンの設定
1. ThingWorx-Foundation サービスを停止します。
2. 管理者として CMD を実行します。
3. ThingWorx Foundation のインストールディレクトリの下の Tomcat /bin ディレクトリに移動します。
例: cd C:\Program Files (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin。
4. 以下を実行することで、ThingWorx-Foundation サービスコンフィギュレーションを編集して GUI アプリケーションを開きます。
tomcat9w.exe //ES//ThingWorx-Foundation
5. GUI アプリケーションの「Java」タブに移動します。
a. 「Java Options」に、-Duser.timezone=UTC を追加します。
b. 「Apply」を選択します。
6. 「OK」を選択して GUI を閉じます。
7. tomcat9.exe を使用してサービスパラメータを更新します。
8. 管理者として CMD を実行し、以下を実行します。
tomcat9.exe //US//ThingWorx-Foundation
Linux でのタイムゾーンの設定
1. systemctl stop ThingWorx-Foundation.service を使用して ThingWorx-Foundation サービスを停止します。
2. /etc/systemd/system/ThingWorx-Foundation.service.backup に ThingWorx-Foundation.service をバックアップします。
3. ThingWorx-Foundation.service の JVM オプションを変更することで、サービスコンフィギュレーションを編集します。
a. CATALINA_OPTS に、-Duser.timezone=UTC を追加します。
4. 次を実行します。systemctl daemon-reload
スクリプトの実行
• 9.3.x 以降のバージョンへのインストーラアップグレード
1. データベース固有のすべてのタイムゾーン名のリストを取得します。これを行うには、データベースに手動で接続し、以下のクエリーを実行することで、データベースで現在サポートされているすべてのタイムゾーン名のリストを取得します。
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | 後で参照するためこのリストを保管しておきます。 |
2. 既存のすべての ThingWorx データが現在関連付けられているタイムゾーンの名前を調べます ("移行元" タイムゾーン)。
▪ 上記の「ThingWorx サーバーのタイムゾーンの設定」セクションでメモしたタイムゾーン値を用意します。
▪ この値は、既存のすべての ThingWorx データが現在関連付けられているタイムゾーンです。
▪ この値は JVM またはオペレーティングシステムに固有であり、(手順 1 でクエリーした) データベース固有のリスト内のいずれのタイムゾーン名とも完全には一致しないことがあります。
▪ データベースからクエリーしたタイムゾーンのリストを手動で調べて、「ThingWorx サーバーのタイムゾーンの設定」セクションの値に最も適したタイムゾーン名を特定します。
▪ 見つかった最も適したタイムゾーン名が、以降の手順で必要となる "移行元" タイムゾーンになります ("移行先" タイムゾーンと対になります)。
3. 既存のすべての ThingWorx データのマイグレーション先のタイムゾーン ("移行先" タイムゾーン) を調べます。
▪ 上記の「ThingWorx サーバーのタイムゾーンの設定」セクションで、Tomcat の -Duser.timezone コンフィギュレーション設定を UTC に設定しました。これは既存のすべての ThingWorx データにおける移行先のタイムゾーンです。ただし、この値は JVM に固有であり、(手順 1 でクエリーした) データベースのリスト内のいずれのタイムゾーン名とも完全には一致しないことがあります。
▪ データベースからクエリーしたタイムゾーンのリストを手動で調べて、UTC 値に最も適したタイムゾーン名を特定します。
▪ 見つかった最も適したタイムゾーン名が、以降の手順で必要となる "移行先" タイムゾーンになります ("移行元" タイムゾーンと対になります)。
| | "移行元" タイムゾーンと "移行先" タイムゾーンの名前が同じであっても構いません。 |
4. BigInt/Timezone スキーマスクリプトを実行して、すべてのデータテーブルデータ、ストリームデータ、値ストリームデータのマイグレーションを準備します。
update_bigint_timezone_schema_postgres.ps1
| | このスクリプトを引数なしで実行すると、その使用方法に関する文が出力されます。 Usage: update_bigint_timezone_schema_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. -y Suppress all non-required prompts, such as "Are you sure?" |
| | このスクリプトでは一部のデータが直接マイグレーションされますが、データテーブルデータ、ストリームデータ、値ストリームデータはマイグレーションされません。代わりに、このスクリプトでは、後でマイグレーションできるように、すべてのデータテーブルデータ、ストリームデータ、および値ストリームデータのバックアップが作成されます。パフォーマンス上の理由から、このスクリプトによって、既存のデータテーブル、ストリームテーブル、および値ストリームテーブル内のデータのバックアップコピーが実際に作成されることはありません。代わりに、このスクリプトでは、既存のテーブルの名前が "foo" から "foo_backup" に変更されます。これにより、大量のデータをコピーするという時間がかかるプロセスが回避されます。これらの既存のテーブルの名前が変更されると (独自のバックアップテーブルになると)、元の名前で新しいテーブルが作成されます。これらの新しいテーブルは空であり、元のテーブルと同じ目的を果たします (元のテーブルと同じ名前になるので)。 |
5. 前の手順が完了した後、必要に応じてプラットフォームを再起動できます。ただし、データテーブルデータ、ストリームデータ、値ストリームデータはまだマイグレーションされていないことに注意してください。このため、データのマイグレーションが行われるまで、そのデータに対するクエリーで返される結果セットが小さくなる可能性があります。
6. BigInt/Timezone データスクリプトを実行して、すべてのデータテーブルデータ、ストリームデータ、または値ストリームデータをマイグレーションします。
update_bigint_timezone_data_postgres.ps1
| | このスクリプトを引数なしで実行すると、その使用方法に関する文が出力されます。 Usage: update_bigint_timezone_data_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> --chunk_size <chunk_size> ( --update_data_table | --update_stream | --update_value_stream ) [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. --chunk_size chunk_size The number of records to update per transaction. Must be greater than 0. --update_data_table Update "data_table" information. Cannot be specified with any other "--update_..." flag. --update_stream Update "stream" information. Cannot be specified with any other "--update_..." flag. --update_value_stream Update "data_table" information. Cannot be specified with any other "--update_..." flag. -y Suppress all non-required prompts, such as "Are you sure?" |
| | • 上記の使用方法に関する文によれば、"--update..." オプションは一度に 1 つだけ指定できます。このため、すべてのデータテーブルデータ、ストリームデータ、および値ストリームデータをマイグレーションするには、このスクリプトを 3 回 (各データセットについて 1 回) 実行する必要があります。これらのデータセットは互いに独立しているので、あるデータセットのマイグレーションを別のデータセットのマイグレーションと並行して実行できます。たとえば、3 つのコマンドウィンドウを別個に開いている場合、1 つ目のウィンドウでデータテーブルのマイグレーション、2 つ目のウィンドウでストリームのマイグレーション、3 つ目のウィンドウで値ストリームのマイグレーションを同時に実行できます。ただし、複数のプロセスを使用して 1 つのデータセットを同時にマイグレーションしないでください。たとえば、2 つの同時プロセスを使用して値ストリームデータをマイグレーションしないでください。これは未定義の操作であり、データが破損します。 • 一般的な環境で推奨される chunk_size は 10000 です。 • すべてのデータのマイグレーションが完了する前にプラットフォームを再起動できるので、データのマイグレーションは最も新しいデータから最も古いデータの順に行われます。これは意図した動作であり、そのデータに対するクエリーで最も関連性の高いデータから先に受信できるようになります。 • データセットのサイズは、すべてのデータのマイグレーションにかかる時間に大きな影響を与える可能性があります。たとえば、数十億行をマイグレーションする場合、そのデータのマイグレーションが完了するまでに数日かかることがあります。 |
7. すべての BigInt/Timezone データマイグレーションが完了し、マイグレーションされたすべての BigInt/Timezone データを手動で確認および検証した後、BigInt/Timezone クリーンアップスクリプトを実行して、BigInt/Timezone スキーマスクリプトによって作成されたテンポラリデータベース成果物をすべてクリーンアップします。
cleanup_bigint_timezone_data_update_postgres.ps1
| | このスクリプトを引数なしで実行すると、その使用方法に関する文が出力されます。 Usage: cleanup_bigint_timezone_data_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
| | このスクリプトではアップグレードプロセス中に作成されたテンポラリデータベースオブジェクトの一部のクリーンアップは実行されますが、前の手順で作成されたバックアップテーブルは削除されず、これらのバックアップテーブル内のデータは修正されません。これは意図的な処理であり、データが誤って削除されることがないようにするためのものです。これらのバックアップテーブルを削除する場合、手動で削除する必要があります。 |
8. すべてのデータのマイグレーションが完了し、確認および検証した後で、メインのクリーンアップスクリプトを実行します。
すべての BigInt/Timezone データのマイグレーションが完了し、確認および検証した後で、このスクリプトを実行して、メイン ThingWorx 更新スクリプトによって作成されたテンポラリデータベース成果物をすべてクリーンアップします。
cleanup_update_postgres.ps1
| | このスクリプトを引数なしで実行すると、その使用方法に関する文が出力されます。 Usage: cleanup_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
• 9.0.x、9.1.x、9.2.x へのインストーラアップグレード
タイムゾーンを設定した後、<インストール場所>/schema/update に移動し、お使いのオペレーティングシステムとデータベースの組み合わせに適したスクリプト (たとえば、Windows の場合は以下に示す .bat ファイル、RHEL インストールの場合は .sh ファイル) を以下の順序で実行します。
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
これらのスクリプトは以下のようなパラメータをとります。
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
これらのパラメータと必要な入力の詳細については、手動インプレースアップグレード: Windows または手動インプレースアップグレード: Linux を参照してください。
データベースユーザーのパスワードを入力するよう求められるので、-u または -l パラメータで渡します。
| | StreamDataUpdate および ValueStreamDataUpdate スクリプト (thingworxPostgresStreamDataUpdate.bat や thingworxPostgresValueStreamDataUpdate.bat など) は非同期で実行するように設計されています。これらのスクリプトは、ThingWorx インスタンスの動作中にデータをマイグレーションできるように、中断した場所をピックアップしてバッチ処理するように設計されています。これらのスクリプトは、データのボリュームによっては、実行に長い時間がかかることがあります。 |
DataTableDataUpdate スクリプト (例: thingworxPostgresDataTableDataUpdate.bat) では、実行中に次のメッセージが表示されます: Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server。
DataTableDataUpdate スクリプトによってこのメッセージが表示された後、ThingWorx インスタンスを再起動し、残りのデータマイグレーションスクリプトに進むことができます。残りのスクリプトは ThingWorx の動作中に実行でき、ストリームと値ストリームのデータのマイグレーションを完了します。
マイグレーションが完了した後で、クリーンアップスクリプト ("thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh" など) を実行して、migration_log テーブルとマイグレーション関数をクリーンアップする必要があります。
E.) クリーンアップスクリプトの実行 (9.2+ の場合)
ThingWorx 9.2.x 以降にアップグレードする場合、クリーンアップスクリプトを実行して、アップグレードプロセス中に作成されたテンポラリテーブルを除去する必要があります。
<インストールディレクトリ>/schema/update にある thingworx<データベース名>DBCleanupPermissionTempTableUpdate.bat (Windows) または thingworx<データベース名>DBCleanupPermissionTempTableUpdate.sh (Linux) クリーンアップスクリプトを実行します。
これらのスクリプトは以下のようなパラメータをとります。
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
データベースユーザーのパスワードを入力するよう求められるので、-u または -l パラメータで渡します。
F.) 追加のオプションのクリーンアップ (9.3+ の場合)
ThingWorx 9.2.x 以前からアップグレードしているときに、アクセストークンを暗号化したシングルサインオンを有効にしている場合、オプションのクリーンアップ手順を実行できます。9.3 より前のリリースでは、アクセストークンをデータベースに永続化する前に、KeyCzar ツールを使用してアクセストークンを暗号化します。KeyCzar を使用する場合、ThingWorx インストールディレクトリの ThingworxPlatform\ssoSecurityConfig フォルダに symmetric フォルダを作成する必要があります。
KeyCzar ツールは廃止予定になっています。ThingWorx 9.3 以降では、代わりに Tink を使用してアクセストークンを暗号化します。Tink では symmetric フォルダや ThingWorx sso-settings.json ファイル内の keyczarKeyFolderPath パラメータは必要ありません。これらのファイルと設定はそのままにしておくことができ、ThingWorx 9.3 以降ではこれらは単に無視されます。ただし、これらを除去する場合、アップグレード手順が完了するまで待たなければなりません。
G.) (オプション) PostgreSQL 13 へのアップグレード
ThingWorx 9.2.0 以降では、古いバージョンの PostgreSQL から PostgreSQL 13 へのアップグレードはオプションです。
1. データベースをバックアップします。ThingWorx をアップグレードした後でデータベースをバックアップするので、これは 2 回目に実行するバックアップです。
2. PostgreSQL 13 をダウンロードします。
3. PostgreSQL ドキュメンテーションを参照として使用して PostgreSQL 13 にアップグレードします。
H.) トラブルシューティング
• 次のエラーが発生してアップグレードが失敗した場合は、以下の手順に従います。このエラーは、カスタムインデックス値が 64 文字以上の場合に発生します。
Unable to Invoke Service Reindex on Data Table : com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated in table 'thingworx.thingworx.data_table_indexes', column 'mskey'. Truncated value: '<with_actual_field_Value_from_mskey_field>'.
a. thingworxMssqlSchemaUpdate<以前のバージョン>-to-<現在のバージョン>.bat/.sh または以下の SQL スクリプトを実行します。
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
このスクリプトを実行すると、mskey 列が長くなってインデックスが更新されます。
b. Tomcat を起動します。
• ThingWorx 8.5.3 以前のバージョンの既存のインストールがあるが、インストーラによってこれが検出されなかった場合、ThingWorx Upgrade-Ready ユーティリティを実行します。
• インストーラによってアップグレードを完了できない場合、以下の手順を実行します。
1. インストールディレクトリ内の /Installer/logs にあるログファイルを確認します。
2. アップグレード前のインストールに戻します。
a. データベースをバックアップに復元します。
b. ThingWorx-Foundation サービスを開始します。
• インストーラが正常に実行された場合、ThingWorx Foundation はアップグレードされました。ただし、ThingWorx Foundation インストール場所の名前が最新でない場合があります。Composer の > で ThingWorx のバージョンを確認できます。
• オペレーティングシステムが RHEL 8.2 で ThingWorx 8.5.7 からアップグレードしている場合、最初に Chef Infra Client を手動でアンインストールして、インストーラがサポートされているバージョンの Chef をプロビジョニングして使用できるようにする必要があります。Chef をアンインストールするには、以下の手順を実行します。
a. Chef Infra Client インストーラのパッケージ名を見つけるため、コマンド $ rpm -qa chef を実行します。
出力は chef-14.10.9-1.el7.x86_64.rpm のようになります。
b. 上記の出力からパッケージ名をコピーします。
c. コピーしたパッケージ名を指定して、コマンド $ sudo yum remove <copied_package_name> を実行します。
例: $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm
d. /opt ディレクトリに移動し、インストールディレクトリを削除することで ($ sudo rm -rf /opt/chef) すべての Chef Infra Client ファイルを除去します。