Обновление с помощью установщика
Если для установки ThingWorx Foundation 8.5.0 или более поздней версии использовался установщик ThingWorx Foundation, можно использовать установщик для обновления ThingWorx Foundation, включая сопутствующие обновления. Ссылки на поддерживаемые таблицы обновления для каждой версии ThingWorx см. в разделе Обновление ThingWorx.
 |
С версии ThingWorx 9.4 клиенты не могут обновляться непосредственно с версии ThingWorx 8.5 или ThingWorx 9.0 до ThingWorx 9.4.0. Клиентам, которым требуется обновление до версии 9.4.0 и более поздней с версии ThingWorx 8.5 или ThingWorx 9.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.
◦ Если вы используете ThingWorx 9.0 или более ранней версии на Java 8 и выполняете обновление до ThingWorx 9.2, необходимо предварительно установить Java 11, но не следует перенаправлять ThingWorx на новую JVM. Параметр JAVA_HOME должен оставаться настроенным на папку Java 8. Оба каталога Java должны быть указаны в переменной среды PATH, но java8/bin должен быть указан перед java11/bin в переменной PATH. В процессе обновления до версии 9.2 установщик также изменяет используемую версию Java на Java 11, поскольку ThingWorx 9.2 не поддерживает Java 8.
◦ Если вы используете 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
Если установлена версия ThingWorx Foundation 8.5.3 или более ранняя, необходимо сначала запустить утилиту поддержки обновления ThingWorx, доступную в разделе > > > > > .
Утилита, поддерживающая обновление ThingWorx, создает XML-файлы, необходимые для поддержки автоматического обновления ThingWorx Foundation и, если установлено, ThingWorx Flow. Эта утилита предлагает найти 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, а теперь собираетесь обновить до 9.x, выполняя утилиту поддержки обновления ThingWorx, выполните следующие действия.
◦ Выполните утилиту поддержки обновления ThingWorx.
◦ Убедитесь, что значение свойства <ВерсияПриложения> в файле ThingWorxFoundation.xml в профиле пользователя - это ваша текущая версия.
• Если у вас возникли проблемы при выполнении утилиты обновления ThingWorx и требуется создание или правка файла 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 в разделе Download Software > Order or Download Software Updates > 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. Перейдите в каталог Tomcat /bin в каталоге установки ThingWorx Foundation.
Например: cd C:\Program Files (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin.
4. Измените конфигурацию сервиса ThingWorx-Foundation, чтобы открыть приложение GUI, выполнив следующие действия.
tomcat9w.exe //ES//ThingWorx-Foundation
5. Перейдите на вкладку Java приложения GUI.
a. В разделе Java Options добавьте следующее: -Duser.timezone=UTC.
b. Выберите Применить.
6. Нажмите кнопку OK, чтобы закрыть GUI.
7. Обновите параметры сервиса, используя tomcat9.exe.
8. Запустите CMD от имени администратора и выполните команду:
tomcat9.exe //US//ThingWorx-Foundation
Конфигурирование настроек часового пояса в Linux
1. Остановите сервис ThingWorx-Foundation, используя systemctl stop ThingWorx-Foundation.service.
2. Создайте резервную копию ThingWorx-Foundation.service в /etc/systemd/system/ThingWorx-Foundation.service.backup.
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…..." только один раз. Поэтому, чтобы перенести все данные таблиц, потоков и потоков значений, этот сценарий необходимо выполнить три раза (один раз для каждого набора данных). Поскольку эти наборы данных независимы друг от друга, перенос одного набора данных может быть выполнен параллельно с переносом другого набора данных. Например, если открыть три отдельных окна команд, можно одновременно выполнить перенос таблицы данных в первом окне, перенести поток во втором окне и перенести поток значений в третьем окне. Однако не пытайтесь использовать более одного процесса для параллельного переноса конкретного набора данных. Например, не пытайтесь использовать два параллельных процесса для переноса данных потока значений. Это приведет к неопределенности и повреждению данных. • Предлагаемое значение chunk_size для типичной среды - 10000. • Поскольку платформу можно перезапустить до завершения переноса всех данных, перенос данных происходит в очередности от последних данных до самых старых данных. Это сделано намеренно и позволяет любым запросам для этих данных сначала получать наиболее актуальные данные. • Размер наборов данных может существенно влиять на время, необходимое для переноса всех данных. Например, если имеются миллиарды строк для переноса, перенос этих данных может занять несколько дней. |
7. После завершения переноса всех данных 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 или более поздней версии необходимо запустить сценарий очистки, чтобы удалить временные таблицы, созданные в процессе обновления.
Запустите сценарий очистки thingworx<имя_базы_данных>DBCleanupPermissionTempTableUpdate.bat (Windows) или thingworx<имя_базы_данных>DBCleanupPermissionTempTableUpdate.sh (Linux), который находится в папке <каталог_установки>/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)
-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 требуется создать папку symmetric в папке ThingworxPlatform\ssoSecurityConfig в каталоге установки ThingWorx.
Инструмент KeyCzar теперь устарел. В ThingWorx 9.3 и более поздних версиях он был заменен на использование Tink для шифрования лексем доступа. Для Tink папка symmetric или параметр keyczarKeyFolderPath в файле ThingWorx sso-settings.json не требуются. Можно оставить эти файлы и настройки как они есть, а в ThingWorx 9.3 и более поздних версиях просто игнорировать их. Но если решено их удалить, необходимо подождать, пока не будет завершена процедура обновления.
G. (Необязательно) Обновление до PostgreSQL 13
Обновление более старой версии PostgreSQL до PostgreSQL 13 является необязательным для ThingWorx 9.2.0 и более поздних версий.
1. Создайте резервную копию базы данных. Это вторая резервная копия, которая будет создана после обновления ThingWorx.
2. Загрузите PostgreSQL 13.
3. Выполните обновление до версии PostgreSQL 13, используя документацию PostgreSQL как справочный материал.
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 может быть неактуальным. Версию ThingWorx можно проверить в Composer в разделе > .
• Если используется операционная система 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 и удалите все файлы Chef Infra Client, удалив каталог установки $ sudo rm -rf /opt/chef.