Linux 手動升級
手動就地升級至 9.3.x 及更新版本：Linux
 |
從 ThingWorx 9.4.0 開始，客戶無法直接從 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.x：Linux。
|
|
目前，H2 不支援大整數/時區資料庫移轉指令集。這些移轉指令集針對其他支援的資料庫提供詳細說明。如果目前使用的是 H2 資料庫，且需要時區修正，則必須移轉至支援的資料庫，例如 PostgreSQL 或 MS SQL。如果您的應用程式在未進行時區修正的情況下也能正常運作，您可在 H2 上升級至最新的 ThingWorx 版本。請注意，您將會跳過設定 ThingWorx 伺服器時區部份，如所述。
|
A.) 升級之前
1. 如果您的 OS 是 RHEL，請在執行 ThingWorx 升級之前，核對是否已升級至支援的版本。如需詳細資訊，請參閱 系統需求。
| | ThingWorx 9.1 僅在 RHEL 8.2 上受支援。 |
2. 在開始升級之前，建議您先執行下列操作：
◦ 資料庫傾印
◦ 備份 ThingworxStorage 與 ThingworxPlatform 資料夾中的所有資料。
◦ 備份 Tomcat_home 資料夾。這包括 bin、conf、lib、temp、webapps 與 work 資料夾。
3. 如果您使用除 ThingWorx 平台之外的 ThingWorx 應用程式：
a. 確認 ThingWorx 應用程式版本支援您要升級至的 ThingWorx 版本。請參閱 ThingWorx 應用程式升級支援一覽表。
b. 您必須先執行一些步驟，然後才能升級平台。請先參閱升級 ThingWorx 應用程式，再繼續進行下一步。
4. 如果您也已安裝 Navigate，請於 ThingWorx Navigate 相容性一覽表中驗證相容性。
5. 在 PTC 軟體下載中下載最新版本的 ThingWorx。
| | 在目前使用者擁有寫入權限的資料夾中下載並解壓縮 ThingWorx 內容。當更新指令集在流程中建立某些檔案時，需要寫入權限。 |
6. 核對您是否執行所需版本的 Tomcat 與 Java。請參閱適用於版本需求的系統需求。
| | 如果您必須升級 Java 版本，請在升級 Java 之前先執行 ThingWorx 升級。 |
7. 如果您升級 MSSQL、Azure SQL 或 H2，且資料表格中遺失任何自訂索引欄位值，升級將會失敗。在開始升級流程之前，核對所有自訂索引欄位都有值。
| | 如果您無法執行此操作，升級將會失敗，且您必須再次部署較舊版本 (如果進行了結構描述更新，您必須回復/還原資料庫)，並新增遺失的索引值，或從資料表中移除自訂索引，然後再執行升級。 |
8. 將下列項目新增至 Apache Tomcat Java 選項：
-Dlog4j2.formatMsgNoLookups=true
B.) 匯出串流與值串流資料 (僅限 InfluxDB)
| | 使用 InfluxDB v2 時，欲升級至 ThingWorx 9.3.9 及更高版本或 ThingWorx 9.4.0 及更高版本，需匯出儲存在 InfluxDB 中的資料，並將其匯入 ThingWorx 9.3.9 或 ThingWorx 9.4.0。但 ThingWorx 9.3.0 至 9.3.7 的已知問題會中斷 Influx 資料匯出。在 ThingWorx 9.3.0 至 ThingWorx 9.3.7 中，無法從 InfluxDB v2 中匯出資料。此問題在 ThingWorx 9.3.8 中已修正。因此，欲更新至 ThingWorx 9.3.9 及更高版本，或更新至 ThingWorx 9.4.0 及更高版本，必須先升級至 ThingWorx 9.3.8。升級至 ThingWorx 9.3.8 後，可升級至 ThingWorx 9.3.9 或 ThingWorx 9.4.0。請遵循下列指示升級 InfluxDB。無需遵循下列步驟從 Thingworx 9.3.7 或較低版本升級至 ThingWorx 9.3.8。 如果要使用 InfluxDB 1.x 將 ThingWorx 升級至 ThingWorx 9.3.9 及更高版本，或升級至 ThingWorx 9.4.0 及更高版本，請遵循下列步驟。無需升級至 ThingWorx 9.3.8，因為 InfluxDB 1.x 匯出運行正常。 如果要使用 InfluxDB 1.7.x 將 ThingWorx (ThingWorx 8.5.x 或 9.0.x) 升級至 InfluxDB 1.8.x (ThingWorx 9.1.x 或 9.2.x)，請遵循下列步驟。 |
1. 從 InfluxDB MS SQL/PostgreSQL 匯出資料：
a. 以管理員身分登入 ThingWorx。
b. 按一下「匯入/匯出」>「匯出」。
c. 可使用下列選項：
▪ 針對「匯出選項」，選取「至檔案」。
▪ 針對「匯出類型」，選取「資料集合」。
▪ 針對「集合」，選取「串流」。
▪ 按一下「匯出」。
d. 針對值串流資料重複步驟 a-c。
e. 將從系統存放庫建立之串流與值串流資料的已匯出資料夾移至安全位置作為備份。
C.) 停止並刪除 ThingWorx Web 應用程式
1. 停止 Tomcat。
2. 強烈建議您先備份下列兩個資料夾再繼續：
◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx
◦ /ThingworxStorage
| | 欲保留現有安裝中的 SSO 組態，請在完成升級後將 SSOSecurityContextFilter 參數新增至重新建立的 web.xml 檔案。 |
3. 如果您目前的 Tomcat 版本較舊，不受目標 ThingWorx 版本支援，請更新至支援的 Tomcat 版本。
4. 欲保留現有安裝中的 SSO 組態，請備份 <Tomcat 安裝目錄>\webapps\Thingworx\WEB-INF 資料夾中的 web.xml 檔案。
5. 備份並刪除 /ThingworxStorage/esapi 目錄中的 validation.properties 檔案。
| | validation.properties 檔案會在啟動 ThingWorx 時建立。如果您要保留所做的任何變更，請將檔案儲存在 ThingworxStorage 目錄外，然後繼續移除 esapi 目錄。在啟動時，ThingWorx 會重新建立該檔案，而且您可以將自訂 regex 新增回自動產生的 validation.properties 檔案中。 如需其他資訊，請參考此主題。 |
6. 轉至 /Apache Software Foundation/Tomcat x.x/webapps 中的 Tomcat 安裝，然後刪除 Thingworx.war 檔案與 Thingworx 資料夾。
D.) 設定 ThingWorx 伺服器時區
如果您是在 H2 上升級，請略過此部份。
1. 針對所有其他資料庫，檢查時區組態設定的 Tomcat Java 選項。如果已針對 UTC (-Duser.timezone=UTC) 配置此設定，請略過此處的其餘步驟，並轉至您的資料庫的「更新架構並移轉資料」部份。
2. 如果未針對 UTC 配置此設定，請決定目前的時區值以供稍後使用：
◦ 如果將此設定配置為 UTC 以外的時區，請記下該時區值以供稍後使用。
◦ 如果尚未在 Tomcat 中配置此設定，請決定安裝 Tomcat 的作業系統的時區值。
3. 記下上述其中一個時區值及其來源 (Tomcat 或作業系統) 之後，請將該資訊放在一旁，但保持其可存取，因為稍後需要用到。
4. 將此組態設定設為 UTC:
-Duser.timezone=UTC
E.) 更新結構描述並移轉資料 (僅限 PostgreSQL)
| | 以下所參考的所有指令集位於 ThingWorx 軟體下載的 update 資料夾內。 |
| | 以下參考的所有指令集都需要資料庫存取權。如果定義了 PGPASSWORD 環境變數，則指令集將使用其值作為資料庫密碼。否則，指令集將會提示您輸入資料庫密碼。如需詳細資訊，請參閱 Postgres 官方文件集。 |
1. 執行主要更新指令集以執行 ThingWorx 結構描述移轉：
update_postgres.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： update_postgres.sh -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_model] [--update_property] [--update_system] ) [-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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". --update_system Update only System information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
執行 ThingWorx 伺服器時區指令集
| | 只有在從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至新 ThingWorx 版本時，才需要執行 ThingWorx 時區指令集。ThingWorx 9.4.0 及更高版本不支援從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 直接升級。客戶必須升級至中繼 ThingWorx 版本，例如 ThingWorx 9.3。從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至 ThingWorx 9.3.x 時，請執行下列指令集。ThingWorx 建議使用最新版本的 ThingWorx 9.3.x 作為中繼版本。 |
如果未在〈設定 ThingWorx 伺服器時區〉一節的步驟 1 中設定 -Duser.timezone=UTC，或者從 ThingWorx 8.5.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.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_schema_postgres.sh -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.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_data_postgres.sh -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…" 選項。因此，欲移轉所有資料表、串流及值串流資料，必須執行三次指令集 (每個資料集一次)。由於這些資料集彼此之間相互獨立，因此可將一個資料集的移轉與另一個資料集的移轉並存執行。例如，如果開啟三個單獨的指令視窗，則可以在第一個視窗中執行資料表移轉、在第二個視窗中執行串流移轉，在第三個視窗中執行值串流移轉，三者同時進行。但是，請勿嘗試使用一個以上的流程來同時移轉某一指定資料集。例如，請勿嘗試使用兩個同步流程來移轉值串流資料。此操作未經過定義，將導致資料損毀。 • 對於典型環境，建議的 chunk_size 為 10000。 • 由於平台可以在完成所有資料移轉之前重新啟動，因此資料的移轉會從最新資料轉移至最舊資料。這是預期行為，可讓該資料的任何查詢首先接收最相關的資料。 • 資料集的大小可能會對移轉所有資料所花費的時間產生巨大影響。例如，如果要移轉的列多達數十億，則資料移轉可能需要幾天才能完成。 |
7. 完成所有 BigInt/Timezone 資料移轉，且手動核對及驗證所有已移轉的 BigInt/Timezone 資料之後，執行 BigInt/Timezone 清理指令集以清除由 BigInt/Timezone 結構描述指令集建立的任何暫時資料庫加工品：
cleanup_bigint_timezone_data_update_postgres.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_bigint_timezone_data_update_postgres.sh -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.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_update_postgres.sh -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?" |
F.) 更新結構描述並移轉資料 (僅限 MSSQL)
| | 以下所參考的所有指令集位於 ThingWorx 軟體下載的 update 資料夾內。 |
| | 以下參考的所有指令集都需要資料庫存取權。如果定義了 SQLCMDPASSWORD 環境變數，則指令集將使用其值作為資料庫密碼。否則，指令集將會提示您輸入資料庫密碼。如需詳細資訊，請參閱 MSSQL 官方文件集。 |
1. 執行主要更新指令集以執行 ThingWorx 結構描述移轉：
update_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_mssql.sh -h <host> -p <port> -d <database> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_grants] [--update_model] [--update_property] ) [-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. -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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_grants Update only Grants information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
執行 ThingWorx 伺服器時區指令集
| | 只有在從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至新 ThingWorx 版本時，才需要執行 ThingWorx 時區指令集。ThingWorx 9.4.0 及更高版本不支援從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 直接升級。客戶必須升級至中繼 ThingWorx 版本，例如 ThingWorx 9.3。從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至 ThingWorx 9.3.x 時，請執行下列指令集。ThingWorx 建議使用最新版本的 ThingWorx 9.3.x 作為中繼版本。 |
如果未在〈設定 ThingWorx 伺服器時區〉一節的步驟 1 中設定 -Duser.timezone=UTC，或者從 ThingWorx 8.5.x 或更早版本升級，則只需要執行本節中的步驟。
1. 取得所有資料庫特定時區名稱的清單。欲執行此操作，請手動連線至資料庫並執行此查詢，以取得資料庫目前支援的所有時區名稱的清單：
SELECT name, current_utc_offset, is_currently_dst FROM sys.time_zone_info 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_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_schema_mssql.sh -h <host> -p <port> -d <database> -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. -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?"
|
5. 完成上一步之後，必要時可能會重新啟動平台。但是，請注意，資料表、串流與值串流資料尚未移轉。因此，在資料移轉發生之前，若針對該資料執行查詢，接收的結果集可能會減少。
6. 執行 BigInt/Timezone 資料指令集可移轉任何資料表、串流或值串流資料：
update_bigint_timezone_data_msssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_data_mssql.sh -h <host> -p <port> -d <database> -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. -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…" 選項。因此，欲移轉所有資料表、串流及值串流資料，必須執行三次指令集 (每個資料集一次)。由於這些資料集彼此之間相互獨立，因此可將一個資料集的移轉與另一個資料集的移轉並存執行。例如，如果開啟三個單獨的指令視窗，則可以在第一個視窗中執行資料表移轉、在第二個視窗中執行串流移轉，在第三個視窗中執行值串流移轉，三者同時進行。但是，請勿嘗試使用一個以上的流程來同時移轉某一指定資料集。例如，請勿嘗試使用兩個同步流程來移轉值串流資料。此操作未經過定義，將導致資料損毀。 • 對於典型環境，建議的 chunk_size 為 10000。 • 由於平台可以在完成所有資料移轉之前重新啟動，因此資料的移轉會從最新資料轉移至最舊資料。這是預期行為，可讓該資料的任何查詢首先接收最相關的資料。 • 資料集的大小可能會對移轉所有資料所花費的時間產生巨大影響。例如，如果要移轉的列多達數十億，則資料移轉可能需要幾天才能完成。 |
7. 完成所有 BigInt/Timezone 資料移轉，且手動核對及驗證所有已移轉的 BigInt/Timezone 資料之後，執行 BigInt/Timezone 清理指令集以清除由 BigInt/Timezone 結構描述指令集建立的任何暫時資料庫加工品：
cleanup_bigint_timezone_data_update_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_bigint_timezone_data_update_mssql.sh -h <host> -p <port> -d <database> -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. -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_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_update_mssql.sh -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 connect to. -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?" |
G.) 更新結構描述並移轉資料 (僅限 Azure SQL)
| | 以下所參考的所有指令集位於 ThingWorx 軟體下載的 update 資料夾內。 |
| | 以下參考的所有指令集都需要資料庫存取權。如果定義了 SQLCMDPASSWORD 環境變數，則指令集將使用其值作為資料庫密碼。否則，指令集將會提示您輸入資料庫密碼。如需詳細資訊，請參閱 MSSQL 官方文件集。 |
1. 執行主要更新指令集以執行 ThingWorx 結構描述移轉：
update_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_mssql.sh -h <host> -p <port> -d <database> -u <user> [--managed_instance <name>] ( --update_all | [--update_data] [--update_grants] [--update_model] [--update_property] ) [-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. -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. --update_all Update all information (i.e. Data, Model, Property, etc). Same as specifying all other "--update_..." flags. --update_data Update only Data information. Can be specified with any other "--update_..." flags, except "--update_all". --update_grants Update only Grants information. Can be specified with any other "--update_..." flags, except "--update_all". --update_model Update only Model information. Can be specified with any other "--update_..." flags, except "--update_all". --update_property Update only Property information. Can be specified with any other "--update_..." flags, except "--update_all". -y Suppress all non-required prompts, such as "Are you sure?" |
執行 ThingWorx 伺服器時區指令集
| | 只有在從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至新 ThingWorx 版本時，才需要執行 ThingWorx 時區指令集。ThingWorx 9.4.0 及更高版本不支援從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 直接升級。客戶必須升級至中繼 ThingWorx 版本，例如 ThingWorx 9.3。從 ThingWorx 8.5 或 ThingWorx 9.0.0、9.0.1 或 9.0.2 升級至 ThingWorx 9.3.x 時，請執行下列指令集。ThingWorx 建議使用最新版本的 ThingWorx 9.3.x 作為中繼版本。 |
如果未在〈設定 ThingWorx 伺服器時區〉一節的步驟 1 中設定 -Duser.timezone=UTC，或者從 ThingWorx 8.5.x 或更早版本升級，則只需要執行本節中的步驟。
1. 取得所有資料庫特定時區名稱的清單。欲執行此操作，請手動連線至資料庫並執行此查詢，以取得資料庫目前支援的所有時區名稱的清單：
SELECT name, current_utc_offset, is_currently_dst FROM sys.time_zone_info 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_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_schema_mssql.sh -h <host> -p <port> -d <database> -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. -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?"
|
5. 完成上一步之後，必要時可能會重新啟動平台。但是，請注意，資料表、串流與值串流資料尚未移轉。因此，在資料移轉發生之前，若針對該資料執行查詢，接收的結果集可能會減少。
6. 執行 BigInt/Timezone 資料指令集可移轉任何資料表、串流或值串流資料：
update_bigint_timezone_data_msssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: update_bigint_timezone_data_mssql.sh -h <host> -p <port> -d <database> -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. -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…" 選項。因此，欲移轉所有資料表、串流及值串流資料，必須執行三次指令集 (每個資料集一次)。由於這些資料集彼此之間相互獨立，因此可將一個資料集的移轉與另一個資料集的移轉並存執行。例如，如果開啟三個單獨的指令視窗，則可以在第一個視窗中執行資料表移轉、在第二個視窗中執行串流移轉，在第三個視窗中執行值串流移轉，三者同時進行。但是，請勿嘗試使用一個以上的流程來同時移轉某一指定資料集。例如，請勿嘗試使用兩個同步流程來移轉值串流資料。此操作未經過定義，將導致資料損毀。 • 對於典型環境，建議的 chunk_size 為 10000。 • 由於平台可以在完成所有資料移轉之前重新啟動，因此資料的移轉會從最新資料轉移至最舊資料。這是預期行為，可讓該資料的任何查詢首先接收最相關的資料。 • 資料集的大小可能會對移轉所有資料所花費的時間產生巨大影響。例如，如果要移轉的列多達數十億，則資料移轉可能需要幾天才能完成。 |
7. 完成所有 BigInt/Timezone 資料移轉，且手動核對及驗證所有已移轉的 BigInt/Timezone 資料之後，執行 BigInt/Timezone 清理指令集以清除由 BigInt/Timezone 結構描述指令集建立的任何暫時資料庫加工品：
cleanup_bigint_timezone_data_update_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_bigint_timezone_data_update_mssql.sh -h <host> -p <port> -d <database> -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. -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_mssql.sh
| | 執行此指令集而不使用引數會列印其使用陳述式： Usage: cleanup_update_mssql.sh -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 connect to. -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?" |
H.) 升級至 Java 11
| | ThingWorx 9.2.0 及更新版本需要 Java 11。如需詳細資訊，請參閱 系統需求。 |
1. 如果您要升級至 Java 11，需要執行下列步驟：如果已安裝 Java 11，請跳過此部份。
b. 在 Linux 中安裝 jEnv：
i. 對 jEnv 存放庫執行 Git clone：
git clone https://github.com/jenv/jenv.git ~/.jenv
ii. 將 jEnv 新增至您的 $PATH：
echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile
iii. 初始化 jEnv：
echo 'eval "$(jenv init -)"' >> ~/.bash_profile
iv. 更新在 ~/.bash_profile 中進行的變更：
source ~/.bash_profile
v. 設定 JAVA_HOME 環境變數：
jenv enable-plugin export
vi. 重新啟動目前 shell 工作階段：
exec $SHELL -l
vii. 執行下列指令，jEnv 即會根據目前的使用中 Java 環境，自動設定 JAVA_HOME 變數：
jenv doctor
c. 新增 Java 環境：
i. 新增任何環境。所有 Java 安裝都位於 /usr/lib/jvm/。使用 jenv add 指令。範例如下：
jenv add /usr/lib/jvm/java-11-amazon-corretto
jenv add /usr/lib/jvm/jdk-11.0.7
ii. 檢查 jenv 的所有可用 Java 版本：
jenv versions
iii. 設定全域 Java 環境：
jenv global <version>
iv. 設定 shell 特定 Java 環境：
jenv shell <version>
v. 確認 jenv 所設定的目前版本：
jenv versions
vi. 更新 Tomcat Java 設定中的路徑。
I.) 部署 ThingWorx war 檔案並重新啟動
1. 複製新的 Thingworx.war 檔案，然後將其置於 Tomcat 安裝的下列位置：/Apache Software Foundation/Tomcat x.x/webapps。
2. 啟用延伸功能匯入。依預設，延伸功能匯入針對所有使用者皆為禁用。將下列內容新增到 platform-settings.json 檔案中。新增下列 ExtensionPackageImportPolicy 參數或將其更新為 true 以允許匯入延伸功能。
"ExtensionPackageImportPolicy": {
"importEnabled": <true or false>,
"allowJarResources": <true or false>,
"allowJavascriptResources": <true or false>,
"allowCSSResources": <true or false>,
"allowJSONResources": <true or false>,
"allowWebAppResources": <true or false>,
"allowEntities": <true or false>,
"allowExtensibleEntities": <true or false>
},
"importEnabled": <true or false>,
"allowJarResources": <true or false>,
"allowJavascriptResources": <true or false>,
"allowCSSResources": <true or false>,
"allowJSONResources": <true or false>,
"allowWebAppResources": <true or false>,
"allowEntities": <true or false>,
"allowExtensibleEntities": <true or false>
},
3. 如果您使用 H2 作為 ThingWorx 的資料庫，必須將使用者名稱與密碼新增至 platform-settings.json 檔案。
},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},
4. 啟動 Tomcat。
5. 欲還原 SSO 組態：
a. 從備份 web.xml 檔案中複製 SSOSecurityContextFilter 區塊。
b. 在新建立的 web.xm 檔案中，將 SSOSecurityContextFilter 區塊貼上到最後一個 AuthenticationFilter 區塊之後。
6. 欲啟動 ThingWorx，請在 web 瀏覽器中轉至 <伺服器名稱>\Thingworx。使用下列登入資訊：
◦ 登入名稱：Administrator
◦ 密碼：<來源伺服器管理員密碼>
J.) 匯入串流與值串流資料 (僅限 InfluxDB)
| | 如果要執行升級并匯出儲存在 InfluxDB 中的資料，然後再將其匯入新的 ThingWorx 版本，請執行本節中的步驟。請參閱 B 節決定是否需要執行匯出-匯入升級。 |
1. 為 InfluxDB 建立新持續性提供者，或提供現有持續性提供者的新連線資訊。
2. 將串流與值串流資料匯入至伺服器。針對串流與值串流資料執行下列步驟。
a. 以管理員身分登入 ThingWorx 9.x。
b. 按一下「匯入/匯出」>「匯入」。
c. 可使用下列選項：
i. 針對「匯入選項」，選取「從檔案」。
ii. 針對「匯入類型」，選取「資料」。
iii. 針對「匯入來源」，選取「檔案存放庫」。
iv. 針對「檔案存放庫」，選取「系統」。
v. 針對「路徑」，提供有效的「系統存放庫」路徑。
K.) 升級其他元件
• 如果您使用「整合連接器」，必須取得並安裝最新版本的 Integration Runtime。如需詳細資訊，請參閱整合連接器的 Integration Runtime 服務的初始設定。
• 如果您是從 8.x 升級到 9.x，且有 Java 延伸功能，請參閱將 Java 延伸功能從 8.x 移轉至 9.x。
• 如果您要使用 ThingWorx Analytics 作為解決方案的一部份，則可以使用兩個安裝程式來處理元件升級：
◦ Analytics Server - 安裝或升級 Analytics Server 與 Analytics Extension
◦ Platform Analytics - 安裝或升級 Descriptive Analytics 與 Property Tranforms
如需有關升級程序的詳細資訊，請參閱 ThingWorx Analytics 升級、修改、修復。
L.) 適用於 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 及更高版本將直接略過它們。但是，如果您決定移除上述檔案，則必須等到升級程式完成之後執行。
M.) 疑難排解
• 如果由於缺少自訂索引欄位值而導致升級失敗，您必須再次部署舊版本 (如果進行了結構描述更新，您必須回滾/恢復資料庫) 並新增遺失的索引值，或從資料表中移除自訂索引，然後再執行升級。
在啟動 ThingWorx 平台之後，請檢查平台的應用程式記錄檔。如果您使用 MSSQL、PostgreSQL 或 H2，可能會看到下列內容衝突錯誤訊息。
應用程式記錄檔錯誤 | 解決方案 |
|---|---|
Error in copying permissions: Problems migrating database | MSSQL 升級時常見此移轉錯誤，並會顯示是否有配置了執行時間權限的任何已移轉服務、內容或事件名稱，且其名稱是否包含超過 256 個字元。欲修正此錯誤，請將所有服務、內容和事件名稱限制為少於 256 個字元。 |
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] Thing: <Name of Thing>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem. | 作為新增至 ThingWorx 平台 8.4 之「物件存在」功能的一部份，已將下列內容新增至「可報告的物形式」，並會將其作為實行此形式之物件存在評估的一部份使用： • isReporting • reportingLastChange • reportingLastEvaluation 如果上述其中一個內容名稱之前存在於物件、物範本或物形式中，當平台啟動時，會在應用程式記錄檔中顯示下列錯誤。欲解決此問題，必須移除每個受影響實體上發生衝突的內容，且任何關聯實體已更新來適應此變更 (例如「混搭」或「服務」)。若沒有此更新，關聯物件無法正確顯示其報告狀況，且無法更新/儲存。正確更新這些實體之後，會顯示平台特定的報告內容，並將其用於評估裝置是否已連線且正在進行通訊。 |
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ThingTempate: <Name of ThingTemplate>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem. | |
[L: ERROR] [O: c.t.p.m.BaseReportingMigrator] [I: ] [U: SuperUser] [S: ] [T: localhost-startStop-1] ThingShape: <Name of ThingShape>, has a property which conflicts with one of the following system properties: isReporting,reportingLastChange,reportingLastEvaluation. Please refer to the ThingWorx Platform 8.4 documentation on how to resolve this problem. |