Обновление Linux вручную
Обновление на месте вручную до версии 9.3.x и выше: Linux
 |
Начиная с ThingWorx 9.4.0, клиенты не могут выполнять обновление непосредственно с версий ThingWorx 8.5 или ThingWorx 9.0 до ThingWorx 9.4.0. Клиентам, которым требуется выполнить обновление до ThingWorx 9.4.0 и более поздней версии с версии ThingWorx 8.5 или ThingWorx 9.0, необходимо выполнить обновление до промежуточной версии, а затем - до ThingWorx 9.4.0 и более поздних версий. В качестве промежуточного пути обновления ThingWorx рекомендуется использовать последнюю версию ThingWorx 9.3.x.
|
Чтобы определить путь обновления, см. таблицу обновления. Шаги, приведенные ниже, предназначены только для обновления на месте. Для обновления переноса см. Перенос вручную для 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)
| | При использовании 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 прерывается. Невозможно экспортировать данные из InfluxDB v2 в версии от ThingWorx 9.3.0 до ThingWorx 9.3.7. Эта проблема исправлена в 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.8 с версии Thingworx 9.3.7 или более старой. При обновлении до ThingWorx 9.3.9 и более поздней версии или до ThingWorx 9.4.0 и более поздней версии из версии ThingWorx, использующей InfluxDB 1.x, выполните шаги, приведенные ниже. Нет необходимости выполнять обновление до ThingWorx 9.3.8, поскольку экспорт для InfluxDB 1.x работает правильно. При обновлении версии 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 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
| | Чтобы сохранить конфигурации SSO из существующей установки, добавьте параметр SSOSecurityContextFilter в повторно созданный файл web.xml после завершения обновления. |
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.
1. Для всех остальных баз данных проверьте опции Tomcat Java для настройки конфигурации часового пояса. Если для этой настройки задано значение UTC (-Duser.timezone=UTC), пропустите остальные шаги и перейдите к разделу "Обновление схемы и перенос данных" для вашей базы данных.
2. Если эта настройка не сконфигурирована для времени UTC, определите текущее значение часового пояса для последующего использования:
◦ Если для этой настройки задан часовой пояс, отличный от UTC, запишите значение этого часового пояса для последующего использования.
◦ Если эта настройка не сконфигурирована в Tomcat, определите значение часового пояса операционной системы, в которой установлен Tomcat.
3. После того как записано одно из перечисленных выше значений часового пояса и источник этого значения (Tomcat или операционная система), отложите эту информацию, но оставьте ее доступной, так как она потребуется на более позднем шаге.
4. Задайте для этой настройки конфигурации значение UTC:
-Duser.timezone=UTC
E. Обновление схемы и перенос данных (только для PostgreSQL)
| | Все упоминающиеся ниже сценарии находятся в папке update в каталоге загрузки программного обеспечения ThingWorx. |
| | Для всех упоминающихся ниже сценариев требуется доступ к базе данных. Если определена переменная среды 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 необходимо только при обновлении с версии ThingWorx 8.5 или ThingWorx 9.0.0, 9.0.1 или 9.0.2 до новой версии 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. |
Шаги из этого раздела необходимо выполнять только в случае, если значение -Duser.timezone=UTC не было задано на шаге 1 раздела "Задание часового пояса сервера ThingWorx" или при обновлении с 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:
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?" |
E. Обновление схемы и перенос данных (только для MSSQL)
| | Все упоминающиеся ниже сценарии находятся в папке update в каталоге загрузки программного обеспечения ThingWorx. |
| | Для всех упоминающихся ниже сценариев требуется доступ к базе данных. Если определена переменная среды 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 необходимо только при обновлении с версии ThingWorx 8.5 или ThingWorx 9.0.0, 9.0.1 или 9.0.2 до новой версии 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. |
Шаги из этого раздела необходимо выполнять только в случае, если значение -Duser.timezone=UTC не было задано на шаге 1 раздела "Задание часового пояса сервера ThingWorx" или при обновлении с 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:
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. Обновление схемы и перенос данных (только для SQL Azure)
| | Все упоминающиеся ниже сценарии находятся в папке update в каталоге загрузки программного обеспечения ThingWorx. |
| | Для всех упоминающихся ниже сценариев требуется доступ к базе данных. Если определена переменная среды 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 необходимо только при обновлении с версии ThingWorx 8.5 или ThingWorx 9.0.0, 9.0.1 или 9.0.2 до новой версии 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. |
Шаги из этого раздела необходимо выполнять только в случае, если значение -Duser.timezone=UTC не было задано на шаге 1 раздела "Задание часового пояса сервера ThingWorx" или при обновлении с 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:
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. Установите 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>
},
"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. Скопируйте блок SSOSecurityContextFilter из файла резервной копии web.xml.
b. Во вновь созданный файл web.xml вставьте блок SSOSecurityContextFilter после последнего блока AuthenticationFilter.
6. Чтобы запустить ThingWorx, перейдите в расположение <имя_сервера>\Thingworx в веб-браузере. Используйте следующую информацию для входа в систему:
◦ Имя пользователя: Administrator
◦ Пароль: <Пароль администратора исходного сервера>
J. Импорт данных потоков данных и потоков значений (только для InfluxDB)
| | Если выполняется обновление, для которого требуется экспорт данных, хранящихся в InfluxDB с последующим импортом в новую версию ThingWorx, выполните шаги, описанные в этом разделе. Чтобы определить, нужно ли выполнять обновление с экспортом-импортом, см. раздел B. |
1. Создайте новый поставщик хранилища данных для InfluxDB или укажите новую информацию о соединении с существующим поставщиком хранилища данных.
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.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 и более поздних версиях просто игнорировать их. Но если решено их удалить, необходимо подождать, пока не будет завершена процедура обновления.
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. |