Ручное обновление на месте до 9.0.x, 9.1.x и n.x: Linux

Установка и обновление > Обновление ThingWorx > Обновление вручную > Обновление Linux вручную > Ручное обновление на месте до 9.0.x, 9.1.x и n.x: Linux

Чтобы определить путь обновления, см. таблицу обновления. Шаги, приведенные ниже, предназначены только для обновления на месте. Для обновления переноса см. Перенос вручную для ThingWorx 9.x: Linux.

В настоящее время отсутствует поддержка сценариев миграции больших баз данных целых чисел/часовых поясов для H2. Эти сценарии переноса подробно описаны для других поддерживаемых баз данных. При наличии существующей базы данных H2 и необходимости коррекции часового пояса необходимо выполнить миграцию в поддерживаемую базу данных, например PostgreSQL или MS SQL. Если приложение будет работать без коррекции часового пояса, можно выполнить обновление до последней версии ThingWorx с H2. Обратите внимание, что, как отмечено, будет пропущен раздел Задание часового пояса сервера ThingWorx.

A. Перед обновлением

1. Если ваша ОС - RHEL, перед выполнением обновления ThingWorx убедитесь, что выполнено обновление до поддерживаемой версии. Дополнительные сведения см. в разделе Требования к системе.

ThingWorx 9.1 поддерживается только в версии RHEL 8.2.

2. Перед началом обновления рекомендуется выполнить следующие действия:

◦ Дамп базы данных

◦ Создайте резервную копию всех данных в папках ThingworxStorage и ThingworxPlatform.

◦ Создайте резервную копию папки Tomcat_home. Это включает папки bin, conf, lib, temp, webapps и work.

3. При использовании ThingWorx Apps в дополнение к ThingWorx Platform:

a. Убедитесь, что версия ThingWorx, до которой выполняется обновление, поддерживается версией ThingWorx Apps. См. раздел ThingWorx Apps Upgrade Support Matrix (Матрица поддержки обновления ThingWorx Apps) (на английском языке).

b. Перед обновлением платформы необходимо выполнить следующие шаги. Перед переходом к следующему шагу см. раздел Обновление ThingWorx Apps.

4. Если уже установлен Navigate, проверьте совместимость в таблице совместимости ThingWorx Navigate.

5. Получите последнюю версию ThingWorx на сайте загрузки программного обеспечения PTC.

Загрузите содержимое ThingWorx и извлеките его в папку, в которой текущий пользователь имеет разрешения на запись. Разрешения на запись требуются, поскольку сценарии обновления создают в процессе некоторые файлы.

6. Убедитесь, что выполняются требуемые версии Tomcat и Java. Требования к версии см. в разделе Системные требования.

Если необходимо обновить версию Java, выполните обновление ThingWorx перед обновлением Java.

7. При обновлении MSSQL, Azure SQL или H2 обновление завершится неудачно, если какое-нибудь значение пользовательского поля индекса отсутствует в таблице данных. Перед началом процесса обновления убедитесь, что все поля пользовательских индексов имеют значения.

Без этого обновление завершится неудачно, и потребуется снова развернуть старую версию (если были сделаны обновления схемы, необходимо откатить и восстановить базу данных) и добавить недостающие значения индекса или удалить пользовательские индексы из таблицы данных и затем выполнить обновление.

8. Добавьте в опции Java Apache Tomcat следующее:

-Dlog4j2.formatMsgNoLookups=true

B. Экспорт данных потоков данных и потоков значений (только для InfluxDB)

Шаги, описанные в этом разделе, требуются только при обновлении ThingWorx с InfluxDB 1.7.x (для ThingWorx 8.5.x или 9.0.x) до InfluxDB 1.8.x (для ThingWorx 9.1.x или 9.2.x).

1. Экспортируйте данные из InfluxDB 1.7.x/MS SQL/PostgreSQL:

a. Войдите в ThingWorx в качестве администратора.

b. Щелкните Импорт/экспорт > Экспорт.

c. Используйте указанные ниже возможности.

▪ В поле Опция экспорта выберите В файл.

▪ В поле Тип экспорта выберите Набор данных.

▪ В поле Набор выберите Потоки.

▪ Щелкните Экспорт.

d. Повторите шаги A - C для данных потока значений.

e. Переместите экспортированную папку для данных потоков и потоков значений из системного репозитория в безопасное расположение в качестве резервной копии.

C. Остановка и удаление веб-приложения ThingWorx

1. Остановите Tomcat.

2. Настоятельно рекомендуется перед продолжением создать резервные копии двух следующих папок:

◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx

◦ /ThingworxStorage

3. Если текущая версия Tomcat является старой и не поддерживается в целевой версии ThingWorx, выполните обновление до поддерживаемой версии Tomcat.

4. Чтобы сохранить конфигурации SSO из имеющейся установки, создайте резервную копию файла web.xml из папки <каталог установки Tomcat>\webapps\Thingworx\WEB-INF.

5. Создайте резервную копию и удалите файл validation.properties из каталога /ThingworxStorage/esapi.

Файл validation.properties создается при запуске ThingWorx. Если нужно сохранить все внесенные изменения, сохраните файл вне каталога ThingworxStorage, а затем продолжайте удаление каталога esapi. При запуске ThingWorx повторно создаст файл, и можно будет добавить пользовательские регулярные выражения в файл validation.properties, который был создан автоматически.

Дополнительные сведения см. в этом разделе.

6. Перейдите к установке Tomcat в папке \Apache Software Foundation\Tomcat x.x\webapps и удалите файл Thingworx.war, а затем папку Thingworx.

D. Задание часового пояса сервера ThingWorx

Пропустите этот шаг при обновлении с H2. Для всех остальных баз данных добавьте следующий параметр в опции Tomcat Java, чтобы задать часовой пояс сервера ThingWorx:

-Duser.timezone=UTC

E. Обновление схемы и перенос данных (только для PostgreSQL)

Только шаг 1 в этом разделе требуется для всех обновлений.

Выполните шаги, приведенные в остальной части этого раздела, при обновлении ThingWorx 8.4.x или 8.5.x --> 9.0.x, 9.1.x или 9.2.x.

Пропустите шаги, приведенные в остальной части этого раздела, при обновлении ThingWorx 9.0.x --> 9.1.x или 9.1.x --> 9.2.x.

1. Выполните следующие сценарии, расположенные в папке update в каталоге загрузки программного обеспечения ThingWorx (начиная с версии, из которой выполняется обновление):

thingworxPostgresSchemaUpdate8.4-to-8.5.sh

thingworxPostgresSchemaUpdate8.5-to-9.0.sh

thingworxPostgresSchemaUpdate9.1-to-9.2.sh

Не требуется запускать сценарий thingworxPostgresSchemaUpdate9.0-to-9.1.sh, поскольку в выпуске 9.1 схема не обновляется. Хотя сценарий включается в папку update для полноты, он пуст и предназначен только для пользователей с автоматизированными процессами обновления.

Шаги, описанные в остальной части этого раздела, следует выполнять только при обновлении от ThingWorx 8.4.x или 8.5.x до 9.0.x, 9.1.x или 9.2.x. Пропустите шаги, приведенные в остальной части этого раздела, если обновление выполняется от ThingWorx 9.0.x до 9.1.x или 9.2.x.

2. Запустите сценарий настройки длинных целых и часовых поясов, чтобы подготовить базу данных к переносу:

Если ThingWorx уже выполняется с форматом UTC, необходимо выполнить перенос для изменений значений "длинное целое", но параметры sourceTZ и targetTZ (доступные в некоторых сценариях в шагах ниже) могут быть предоставлены как значение UTC.

thingworxPostgresDBSetupBigIntTimezoneDataUpdate.sh

3. Чтобы найти все поддерживаемые часовые пояса, используйте следующую команду:

select pg_timezone_names()

При указании часовых поясов для сценариев переноса данных имена часовых поясов должны точно соответствовать одному из формальных имен, отображаемых сценарием pg_timezone_names().

4. Выполните сценарий переноса модели, чтобы перенести все данные модели:

Перед выполнением сценария откройте сценарий в текстовом редакторе, чтобы убедиться, что его значения среды по умолчанию (такие как сервер, порт, часовой пояс и т. д.) являются правильными и достаточными для вашей среды. Если какие-то значения по умолчанию, определенные в сценарии, не подходят для вашей среды, переопределите значения по умолчанию при выполнении сценария, указав один или несколько аргументов командной строки.

thingworxPostgresModelTablesDataUpdate.sh

Использование:

thingworxPostgresModelTablesDataUpdate.sh [-h <server>] [-p <port>] [-d <Thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>]

Пример:

thingworxPostgresModelTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

5. Выполните каждый из следующих сценариев переноса схемы, чтобы создать резервные копии для всех таблиц данных, данных потоков и потоков значений.

В целях повышения производительности эти сценарии фактически не создают копии исходных данных в этих таблицах. Эти сценарии заменяют для существующих таблиц <имя-исходной-таблицы> на <имя-исходной-таблицы>_backup. Это позволяет не тратить много времени на фактическое копирование данных. После переименования существующих таблиц (которые становятся резервными копиями таблиц) создаются новые таблицы с исходными именами. Эти новые таблицы являются пустыми и служат той же цели, что и исходные таблицы (поскольку они имеют те же имена, что и исходные таблицы). Эти новые таблицы заполняются перенесенными данными на последующих шагах.

thingworxPostgresDataTableSchemaUpdate.sh

thingworxPostgresStreamSchemaUpdate.sh

thingworxPostgresValueStreamSchemaUpdate.sh

6. Откройте новое окно командной строки и выполните следующий сценарий переноса данных, чтобы перенести данные таблицы данных в резервную копию таблицы.

thingworxPostgresDataTableDataUpdate.sh

Использование:

thingworxPostgresDataTableDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

Пример:

thingworxPostgresDataTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

После запуска сценария переноса подождите, пока на консоли не появится сообщение, указывающее, что можно безопасно перезапустить Tomcat. После отображения этого сообщения можно безопасно перейти к следующему шагу, даже если еще не завершено выполнение этого сценария переноса.

7. Откройте новое окно командной строки и выполните следующие сценарии переноса данных, чтобы перенести данные потоков и потоков значений из резервных копий таблиц.

thingworxPostgresStreamDataUpdate.sh

thingworxPostgresValueStreamDataUpdate.sh

Использование:

thingworxPostgresStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

thingworxPostgresValueStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

Примеры:

thingworxPostgresStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

thingworxPostgresValueStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

После запуска этих двух сценариев переноса не переходите к следующему шагу до успешного завершения этих сценариев переноса, а также сценария переноса таблицы данных (запущенных на предыдущем шаге).

8. Вручную проверьте, что были успешно выполнены следующие сценарии: thingworxPostgresDataTableDataUpdate.sh, thingworxPostgresStreamDataUpdate.sh и thingworxPostgresValueStreamDataUpdate.sh. Убедитесь, что успешно перенесены все данные таблиц данных, потоков и потоков значений.

9. Запустите сценарий очистки данных, чтобы удалить все временные объекты базы данных, необходимые во время переноса:

Хотя этот сценарий выполняет некоторую очистку данных временных объектов базы данных, созданных в процессе обновления, этот сценарий *не* удаляет все резервные копии таблиц, созданные на предыдущих шагах, а также не изменяет данные в этих резервных копиях таблиц. Это сделано преднамеренно и гарантирует, что данные не могут быть случайно удалены. Если нужно удалить эти резервные копии таблиц, их следует удалить вручную.

thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh

Устранение неисправностей сценария

Следующие команды должны выполняться для базы данных ThingWorx.

• Код ошибки 23505 означает, что при вставке имелось повторяющееся значение ключа, нарушающее ограничение уникальности. Чтобы решить эту проблему, выполните следующие действия.

a. Выполните следующую команду:

Select * from migration_log where status = -1 OR status = 0.

b. Запишите диапазоны для fromId и toId для возвращенных строк.

c. Запросите в таблице данных entry_ids , записанные из журнала переноса.

d. Если все записи находятся там, для любого из этих диапазонов измените значение 0 или -1 на 1. Если записи из диапазона частично отсутствуют, попробуйте уменьшить размер части или удалите записи, уже перенесенные в таблицу, и повторите перенос.

• Чтобы найти все поддерживаемые часовые пояса, используйте следующую команду:

select pg_timezone_names()

. Необходимо использовать формальное наименование, перечисленное первым, чтобы PostgreSQL автоматически мог разрешать смещение для сдвига даты на основании заданной метки времени.

• Чтобы убедиться, что были перенесены все entry_ids, используйте запрос SQL, подобный следующему:

SELECT entry_id FROM data_table_backup EXCEPT SELECT entry_id FROM data_table

SELECT entry_id FROM data_table EXCEPT SELECT entry_id FROM data_table_backup

• Если переменная среды PGPASSWORD используется в системе, необходимо передать эту переменную в параметр -r , чтобы задать пароль, с которым должны запускаться сценарии.

E. Обновление схемы и перенос данных (только для MSSQL)

Только шаг 1 в этом разделе требуется для всех обновлений.

Выполните шаги, приведенные в оставшейся части этого раздела, если вы обновляете ThingWorx 8.4.x или 8.5.x --> 9.0.x, 9.1.x или 9.2.x.

Пропустите шаги, приведенные в остальной части этого раздела, при обновлении от ThingWorx 9.0.x или 9.1.x --> 9.1.x или 9.2.x

1. Скопируйте всю папку update, расположенную в загрузке ThingWorx, на сервер MS SQL и выполните следующие сценарии, находящиеся в папке update (начиная с версии, с которой выполняется обновление):

thingworxMssqlSchemaUpdate8.4-to-8.5.sh

thingworxMssqlSchemaUpdate8.5-to-9.0.sh

thingworxMssqlSchemaUpdate9.1-to-9.2.sh

Не нужно запускать сценарий thingworxMssqlSchemaUpdate9.0-to-9.1.sh, поскольку в выпуске 9.1 нет изменений схемы. Хотя сценарий включен в папку update для полноты, он пуст и предназначен только для пользователей с автоматизированными процессами обновления.

2. Запустите сценарий настройки длинных целых и часовых поясов, чтобы подготовить базу данных к переносу:

thingworxMssqlDBSetupBigIntTimezoneDataUpdate.sh

3. Выполните сценарий переноса модели, чтобы перенести все данные модели:

thingworxMssqlModelTablesDataUpdate.sh

Использование:

thingworxMssqlModelTablesDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>]

Пример:

thingworxMssqlModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC

4. Выполните каждый из следующих сценариев переноса схемы, чтобы создать резервные копии таблиц для всех данных потока данных, потоков и потоков значений.

thingworxMssqlDataTableSchemaUpdate.sh

thingworxMssqlStreamSchemaUpdate.sh

thingworxMssqlValueStreamSchemaUpdate.sh

5. Откройте новое окно командной строки и выполните следующий сценарий переноса данных, чтобы перенести данные таблицы данных в резервную копию таблицы.

thingworxMssqlDataTableDataUpdate.sh

Использование:

thingworxMssqlDataTableDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

Пример:

thingworxMssqlDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

6. Откройте новое окно командной строки и выполните следующие сценарии переноса данных, чтобы перенести данные потоков и потоков значений из резервных копий таблиц.

thingworxMssqlStreamDataUpdate.sh

thingworxMssqlValueStreamDataUpdate.sh

Использование:

thingworxMssqlStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

thingworxMssqlValueStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

Примеры:

thingworxMssqlStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxMssqlValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

После запуска этих двух сценариев переноса не переходите к следующему шагу до успешно завершения этих сценариев переноса, а также сценария переноса таблицы данных (запущенных на предыдущем шаге).

7. Вручную проверьте, успешно ли выполнены следующие сценарии: thingworxMssqlDataTableDataUpdate.sh, thingworxMssqlStreamDataUpdate.sh и thingworxMssqlValueStreamDataUpdate.sh, и убедитесь, что успешно перенесены все данные таблиц данных, потоков и потоков значений.

8. Запустите сценарий очистки данных, чтобы удалить все временные объекты базы данных, необходимые во время переноса:

thingworxMssqlDBCleanupBigIntTimezoneDataUpdate.sh

Устранение неисправностей сценария

• Чтобы найти все поддерживаемые часовые пояса, используйте следующую команду:

select * from sys.time_zone_info

• Чтобы убедиться, что были перенесены все entry_ids, используйте запрос SQL, подобный следующему:

select dt.entry_id, dtb.entry_id from [thingworx].[twschema].[data_table_backup] dtb full join [thingworx].[twschema].[data_table] dt on dtb.entry_id = dt.entry_id where dtb.entry_id is null or dt.entry_id is null

G. Обновление схемы и перенос данных (только для SQL Azure)

Только шаг 1 в этом разделе требуется для всех обновлений.

Пропустите шаги, приведенные в остальной части этого раздела, при обновлении от ThingWorx 9.0.x или 9.1.x --> 9.1.x или 9.2.x

1. Выполните следующий сценарий, расположенный в папке update в каталоге загрузки программного обеспечения ThingWorx (начиная с версии, из которой выполняется обновление):

Количество разрешений, существующих в платформе, может повлиять на время выполнения обновления. Дополнительные разрешения могут увеличить время завершения обновления.

thingworxAzureSchemaUpdate8.4-to-8.5.sh

thingworxAzureSchemaUpdate8.5-to-9.0.sh

thingworxAzureSchemaUpdate9.1-to-9.2.sh

Не требуется запускать сценарий thingworxAzureSchemaUpdate9.0-to-9.1.sh, поскольку в 9.1 схема не обновляется. Хотя сценарий включается в папку update для полноты, он пуст и предназначен только для пользователей с автоматизированными процессами обновления.

Использование:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d ^database^ -h ^server^ -l ^username^ [-i ^serverInstance^] [-p ^port^] [-o ^option^]

Пример:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d thingworx -h test.sqldatabase.net -l sqlAdmin

2. Запустите сценарий настройки длинных целых и часовых поясов, чтобы подготовить базу данных к переносу:

thingworxAzureDBSetupBigIntTimezoneDataUpdate.sh

3. Выполните сценарий переноса модели, чтобы перенести все данные модели:

thingworxAzureModelTablesDataUpdate.sh

Использование:

thingworxAzureModelTablesDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Пример:

thingworxAzureModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

При выполнении сценария таблицы данных отображается следующее ожидаемое предупреждение: Warning! The maximum key length for a clustered index is 900 bytes. The index 'data_table_indexes_pkey' has maximum length of 902 bytes. For some combination of large values, the insert/update operation will fail.

thingworxAzureDataTableSchemaUpdate.sh

thingworxAzureStreamSchemaUpdate.sh

thingworxAzureValueStreamSchemaUpdate.sh

thingworxAzureDataTableDataUpdate.sh

Использование:

thingworxAzureDataTableDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Пример:

thingworxAzureDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxAzureStreamDataUpdate.sh

thingworxAzureValueStreamDataUpdate.sh

Использование:

thingworxAzureStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

thingworxAzureValueStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

Примеры:

thingworxAzureStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxAzureValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

7. Вручную проверьте, успешно ли выполнены следующие сценарии: thingworxAzureDataTableDataUpdate.sh, thingworxAzureStreamDataUpdate.sh и thingworxAzureValueStreamDataUpdate.sh. Убедитесь, что успешно перенесены все данные таблиц данных, потоков и потоков значений.

thingworxAzureDBCleanupBigIntTimezoneDataUpdate.sh

H. Обновление до Java 11

Для ThingWorx 9.2.0 и более поздних версий требуется Java 11. Дополнительные сведения см. в разделе Требования к системе.

1. При обновлении до Java 11 необходимо выполнить следующие шаги. Пропустите этот раздел, если версия Java 11 уже установлена.

a. Загрузите OpenJDK или Java 11.

b. Установите jEnv в Linux:

i. Создайте копию (git clone) репозитория jEnv:

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. Перезапустите текущую сессию оболочки:

exec $SHELL -l

vii. Выполните следующую команду, и jEnv автоматически задаст значение для переменной JAVA_HOME в зависимости от текущей активной среды Java:

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. Проверьте все доступные версии Java для jenv:

jenv versions

iii. Задайте глобальную среду Java:

jenv global <version>

iv. Задайте специфичную для оболочки среду 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>
},

3. При использовании H2 в качестве базы данных с ThingWorx необходимо добавить имя пользователя и пароль в файл platform-settings.json.

},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},

4. Запустите Tomcat.

5. Чтобы восстановить конфигурации SSO, выполните следующие действия.

a. Скопируйте блок SSOSecurityContextFilter из файла резервной копии web.xml.

b. Во вновь созданный файл web.xml вставьте блок SSOSecurityContextFilter после последнего блока AuthenticationFilter.

6. Чтобы запустить ThingWorx, перейдите в расположение <имя_сервера>\Thingworx в веб-браузере. Используйте следующую информацию для входа в систему:

◦ Имя пользователя: Administrator

◦ Пароль: <Пароль администратора исходного сервера>

J. Импорт данных потоков данных и потоков значений (только для InfluxDB)

1. Создайте новый поставщик хранилища данных для InfluxDB 1.8.x или укажите новую информацию о соединении с существующим поставщиком хранилища данных 1.7.x.

2. Импортируйте данные потоков и потоков значений на сервер. Выполните следующие шаги для данных потоков и потоков значений.

a. Войдите в ThingWorx 9.x в качестве администратора.

b. Щелкните Импорт/экспорт > Импорт.

c. Используйте указанные ниже возможности.

i. В поле Опция импорта выберите Из файла.

ii. В поле Тип импорта выберите Данные.

iii. В поле Источник импорта выберите Репозиторий файлов.

iv. В поле Репозиторий файлов выберите Система.

v. В поле Путь укажите действительный путь к системному репозиторию.

K. Обновление дополнительных компонентов

• Если используются соединители интеграции, необходимо получить и установить последнюю версию среды выполнения интеграции. Дополнительные сведения см. в документе Initial Setup of Integration Runtime Service for Integration Connectors (Начальная настройка сервиса интеграции времени выполнения для соединителей интеграции) (на английском языке).

• При обновлении драйвера MSSQL JDBC проверьте требования к системе и см. раздел Конфигурирование ThingWorx для MSSQL, чтобы найти соответствующий драйвер.

• При обновлении от версии 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.2.x

При обновлении до ThingWorx 9.2.x или более поздней версии необходимо запустить сценарий очистки, чтобы удалить временные таблицы, созданные в процессе обновления.

Запустите сценарий очистки thingworx<имя базы данных>DBCleanupPermissionTempTableUpdate.sh, расположенный в папке <каталог установки>/schema/update.

Сценарий принимает параметры, например следующие:

-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)

Вам потребуется ввести пароль пользователя базы данных, который передается в параметрах -u или -l.

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

Было ли это полезно?