Actualización del instalador
Si se utiliza el Instalador de ThingWorx Foundation para instalar ThingWorx Foundation 8.5.0 o una versión posterior, se puede utilizar el instalador para actualizar ThingWorx Foundation, incluidas las actualizaciones de la versión de mantenimiento. Para obtener vínculos a matrices de actualización soportadas de cada versión de ThingWorx, consulte Actualización de ThingWorx.
 |
A partir de ThingWorx 9.4, los clientes no pueden actualizar directamente de ThingWorx 8.5 o ThingWorx 9.0 a ThingWorx 9.4.0. Los clientes que deseen actualizar a 9.4.0 y versiones posteriores desde ThingWorx 8.5 o ThingWorx 9.0 deben actualizar a una versión intermedia y, a continuación, actualizar a ThingWorx 9.4.0 y versiones posteriores. En ThingWorx se recomienda utilizar la versión más reciente de ThingWorx 9.3.x como ruta de actualización intermedia.
|
|
|
Si se está actualizando a ThingWorx 9.2 y PostgreSQL 13, la actualización de PostgreSQL será el último paso del proceso de actualización.
|
|
|
El usuario que realiza la actualización debe ser el mismo que realizó la instalación original de la aplicación.
|
A) Requisitos previos
• Requisitos de Java (el instalador no empaqueta ni instala Java como parte de la instalación):
◦ El usuario que instaló inicialmente ThingWorx debe ejecutar la actualización. Durante la instalación inicial, el instalador genera el fichero ThingWorxFoundation.xml, en el que se incluye información sobre la instalación y es necesario para la actualización. Este fichero se encuentra en el perfil del usuario que ejecuta la instalación. Por ejemplo, en C:\Usuarios\Administrator\.ptc_cci.
◦ ThingWorx Foundation 9.2 requiere Java 11, pero también se debe instalar Java 8. Antes de ejecutar el instalador, verifique que las versiones soportadas de Java 8 y 11 están instaladas. Añada Java 11 a la variable del entorno PATH.
◦ Si se ejecuta ThingWorx 9.0 o una versión anterior en Java 8 y se actualiza a ThingWorx 9.2, se debe instalar previamente Java 11 pero no se debe cambiar ThingWorx para que señale a la nueva jvm. JAVA_HOME debe permanecer definida en la carpeta Java 8. Ambos directorios Java deben estar en la variable del entorno PATH, pero java8/bin se debe mostrar antes que java11/bin en la variable PATH. Durante la actualización a 9.2, el instalador también cambiará la versión de Java que se esté utilizando a Java 11, ya que ThingWorx 9.2 no soporta Java 8.
◦ Si se ejecuta ThingWorx 9.1, se soporta Java 8 y Java 11, por lo que se puede seguir el consejo anterior (instalar ambos, tener ambos en la ruta), o bien se puede migrar la instancia de ThingWorx 9.1 a Java 11 antes de iniciar la actualización.
• Cree una copia de seguridad de la base de datos. El instalador no ejecuta una copia de seguridad de la base de datos durante el proceso de actualización.
• Debe tener uno de los siguientes sistemas operativos con estas combinaciones de base de datos:
◦ Windows con PostgreSQL
◦ Windows con Microsoft SQL Server
◦ Red Hat Enterprise Linux con PostgreSQL
◦ Red Hat Enterprise Linux con Microsoft SQL Server
Para obtener información sobre la versión, consulte Requisitos del sistema.
• La actualización fallará si falta cualquiera de los valores de campo de índice personalizado en las tablas de datos. Verifique que todos los campos de índice personalizados tengan valores antes de iniciar el proceso de actualización.
B) Ejecución de ThingWorx Upgrade Ready Utility
Si se ha instalado ThingWorx Foundation 8.5.3 o una versión anterior, primero se debe ejecutar ThingWorx Upgrade Ready Utility, disponible en > > > > > .
ThingWorx Upgrade-Ready Utility crea los ficheros XML necesarios para soportar la actualización automática de ThingWorx Foundation y, si está instalado, ThingWorx Flow. La utilidad solicita al usuario que localice ThingWorx Foundation y, si está instalado, ThingWorx Flow, en el sistema y, a continuación, configura las instalaciones seleccionadas. Crea el fichero ThingWorxFoundation.xml y, si se ha instalado ThingWorx Flow, el fichero ThingWorxFlow.xml, en el perfil de usuario. Los ficheros se guardan en la carpeta .ptc_ccif del perfil de usuario (por ejemplo, en Windows: C:\Usuarios\Administrador\.ptc_ccif; en Linux: ~/.ptc_ccif/).
Si se ha instalado ThingWorx 8.5.4 o una versión posterior mediante el instalador, los ficheros XML necesarios ya se han creado como parte de la instalación; por lo tanto, no es necesario ejecutar ThingWorx Upgrade-Ready Utility.
Resolución de problemas
• Si se ha utilizado el instalador para instalar ThingWorx Foundation 8.5.3 o versiones anteriores y, a continuación, se ha actualizado manualmente a una versión 8.5.x posterior y ahora se prepara para actualizar a 9.x ejecutando ThingWorx Upgrade-Ready Utility, realice lo siguiente:
◦ Ejecute ThingWorx Upgrade-Ready Utility.
◦ Valide que el valor de la propiedad <applicationVersion> del fichero ThingWorxFoundation.xml del perfil de usuario sea la versión actual.
• Si se tienen problemas al ejecutar ThingWorx Upgrade-Ready Utility y se debe crear o editar manualmente el fichero ThingWorxFoundation.xml, se puede utilizar el siguiente ejemplo y actualizarlo en función de la ruta de actualización:
<?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) Actualización
1. Asegúrese de que se cumplan los requisitos previos que se describen en las secciones anteriores.
2. Obtenga y descargue los ficheros más recientes del instalador de ThingWorx Foundation para instalaciones locales en support.ptc.com en Descargar software > Pedir o descargar actualizaciones de software > ThingWorx Foundation > Versión x.x > ThingWorx PostgreSQL o ThingWorx Mssql .
3. El instalador muestra la información de instalación existente, que incluye:
◦ Directorio de instalación
◦ Puerto
◦ Opciones de configuración de SSL
◦ Opciones de configuración de SSO
4. Se presenta al usuario el convenio de licencia de PTC. Se deben aceptar los términos del convenio antes de continuar con la actualización.
5. Se debe introducir la contraseña de administrador de ThingWorx Foundation o, si se ha configurado el SSO, introducir la clave de aplicación.
6. Se puede revisar y confirmar la información de configuración de la instalación.
7. El instalador completará la actualización.
Ahora se pueden actualizar extensiones y aplicaciones a versiones compatibles.
D) Migración de datos de zona horaria
| | No es necesario migrar los datos de zona horaria para actualizar a ThingWorx 9.4.0 y versiones posteriores. No se soportan actualizaciones directas desde ThingWorx 8.5 o ThingWorx 9.0 a ThingWorx 9.4. La migración de zonas horarias se realizará durante el proceso de migración a la versión intermedia. |
Se deben realizar los pasos de migración de datos críticos de esta sección si se cumple alguna de las siguientes condiciones:
• ThingWorx 8.5.x estaba instalado y se utilizó el instalador para actualizar a ThingWorx 9.0.x o 9.1.
• ThingWorx 9.0.x estaba instalado y se utilizó el instalador para actualizar a ThingWorx 9.0.3 o posterior.
Para realizar esta migración de datos, realice lo siguiente:
1. Inmediatamente después de la actualización correcta, detenga ThingWorx y Apache Tomcat.
2. Defina manualmente el parámetro de zona horaria -Duser.timezone=UTC mediante los siguientes pasos en función del sistema operativo.
Definición de la configuración de zona horaria en Windows
1. Detenga el servicio ThingWorx-Foundation.
2. Ejecute CMD como administrador.
3. Vaya al directorio /bin de Tomcat en el directorio de instalación de ThingWorx Foundation.
Por ejemplo: cd C:\Archivos de programa (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin.
4. Edite la configuración del servicio ThingWorx-Foundation para abrir la aplicación GUI ejecutando lo siguiente:
tomcat9w.exe //ES//ThingWorx-Foundation
5. Vaya a la ficha Java de la aplicación GUI.
a. Para Java Options, añada lo siguiente:-Duser.timezone=UTC.
b. Elija Apply.
6. Elija OK para cerrar la GUI.
7. Actualice los parámetros de servicio mediante tomcat9.exe.
8. Ejecute CMD como administrador y ejecute lo siguiente:
tomcat9.exe //US//ThingWorx-Foundation
Definición de la configuración de zona horaria en Linux
1. Detenga el servicio ThingWorx-Foundation mediante systemctl stop ThingWorx-Foundation.service.
2. Realice una copia de seguridad de ThingWorx-Foundation.service en /etc/systemd/system/ThingWorx-Foundation.service.backup.
3. Para editar la configuración del servicio, cambie ThingWorx-Foundation.service para las opciones de JVM:
a. Para CATALINA_OPTS, incorpore lo siguiente: -Duser.timezone=UTC.
4. Ejecute lo siguiente: systemctl daemon-reload.
Ejecución de scripts
• Actualización del instalador a 9.3. x y versiones posteriores
1. Obtenga la lista de todos los nombres de zona horaria específicos de la base de datos. Para ello, conéctese manualmente a la base de datos y ejecute esta consulta para obtener una lista de todos los nombres de zonas horarias que la base de datos soporta actualmente:
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | Conserve esta lista para referencia posterior. |
2. Determine el nombre de la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes (la zona horaria "De"):
▪ Obtenga el valor de zona horaria que anotó en la sección "Definición de la zona horaria del servidor de ThingWorx" anterior.
▪ Este valor es la zona horaria a la que están asociados actualmente todos los datos de ThingWorx existentes.
▪ Este valor es específico de la JVM o del sistema operativo y puede que no coincida exactamente con ningún nombre de zona horaria de la lista específica de la base de datos (consultadas en el paso 1).
▪ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor de la sección "Definición de la zona horaria del servidor de ThingWorx".
▪ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "De" (frente a la zona horaria "A") que se necesitará en pasos posteriores.
3. Determine la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes (la zona horaria "A"):
▪ En la sección "Definición de la zona horaria del servidor de ThingWorx" anterior, se ha definido el valor de configuración -Duser.timezone de Tomcat en UTC. Esta es la zona horaria a la que se deben migrar todos los datos de ThingWorx existentes. Sin embargo, ese valor es específico de la JVM y puede no coincidir exactamente con ningún nombre de zona horaria de la lista de bases de datos consultadas (en el paso 1).
▪ Examine manualmente la lista de las zonas horarias que se consultan desde la base de datos para determinar el nombre de la zona horaria que coincide más adecuadamente con ese valor UTC.
▪ Después de encontrar la coincidencia más adecuada, el nombre de la zona horaria se convierte en la zona horaria "A" (frente a la zona horaria "De") que se necesitará en pasos posteriores.
| | Los nombres de zona horaria "De" y "A" pueden ser iguales. |
4. Ejecute el script de esquema BigInt/Timezone para preparar la migración de todos los datos de tabla de datos, flujo y flujo de valor:
update_bigint_timezone_schema_postgres.ps1
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script migra directamente algunos datos, no migra ningún dato de tabla de datos, flujo o flujo de valor. En su lugar, este script crea una copia de seguridad de todos los datos de tabla de datos, flujo y flujo de valor, por lo que se puede migrar posteriormente. Por motivos de rendimiento, este script no crea realmente una copia de seguridad de los datos en las tablas de datos, de flujo y de flujo de valor existentes. En su lugar, este script cambia el nombre de las tablas existentes de "foo" a "foo_backup". Así se evita el proceso de copiar grandes cantidades de datos que puede tardar mucho tiempo. Una vez que se cambie el nombre de las tablas existentes (y convertirse, por lo tanto, en tablas de copia de seguridad), se crearán nuevas tablas con los nombres originales. Estas tablas nuevas están vacías y sirven para el mismo propósito que las tablas originales (porque tienen los mismos nombres que las tablas originales). |
5. Después de completar el paso anterior, se puede reiniciar la plataforma si es necesario. Sin embargo, se debe tener en cuenta que los datos de tabla de datos, flujo y flujo de valor todavía no se han migrado. Por lo tanto, hasta que se produzca la migración de datos, las consultas de esos datos pueden recibir conjuntos de resultados reducidos.
6. Ejecute el script de datos BigInt/TimeZone para migrar los datos de tabla de datos, flujo o flujo de valor:
update_bigint_timezone_data_postgres.ps1
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | • Según la sentencia de uso anterior, solo se puede especificar una opción "--update..." a la vez. Por lo tanto, para migrar todos los datos de tabla de datos, flujo y flujo de valor, este script se debe ejecutar tres veces (una vez para cada conjunto de datos). Dado que estos conjuntos de datos son independientes entre sí, la migración de un conjunto de datos se puede realizar en paralelo a la migración de otro conjunto de datos. Por ejemplo, si se abren tres ventanas de comandos independientes, se puede ejecutar simultáneamente la migración de la tabla de datos en la primera ventana, la migración de flujo en la segunda ventana y la migración de flujo de valor en la tercera ventana. Sin embargo, no intente utilizar más de un proceso para migrar simultáneamente un conjunto de datos determinado. Por ejemplo, no intente utilizar dos procesos simultáneos para migrar los datos de flujo de valor. Esta operación no está definida y provocará daños en los datos. • El valor de chunk_size sugerido para un entorno típico es 10 000. • Puesto que la plataforma se puede reiniciar antes de que se haya completado la migración de todos los datos, la migración de datos se produce de los datos más recientes a los más antiguos. Esto es intencionado y permite que cualquier consulta de esos datos empiece a recibir los datos más relevantes en primer lugar. • El tamaño de los conjuntos de datos puede tener un impacto considerable en el tiempo que se tarda en migrar todos los datos. Por ejemplo, si hay miles de millones de filas que se deben migrar, la migración de los datos puede tardar varios días en completarse. |
7. Una vez completada la migración de todos los datos de BigInt/TimeZone y después de verificar y validar manualmente todos los datos migrados, ejecute el script de limpieza de BigInt/TimeZone para limpiar los artefactos de base de datos temporales creados por el script de esquema BigInt/TimeZone:
cleanup_bigint_timezone_data_update_postgres.ps1
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
| | Aunque este script realiza cierta limpieza de los objetos de base de datos temporales creados durante el proceso de actualización, no borra ninguna de las tablas de copia de seguridad creadas en los pasos anteriores, ni tampoco modifica los datos de las tablas de copia de seguridad. Esto es intencionado y garantiza que los datos no se puedan borrar accidentalmente. Si desea borrar estas tablas de copia de seguridad, debe hacerlo manualmente. |
8. Ejecute el script principal de limpieza una vez se haya completado, verificado y validado toda la migración de datos.
Después de que se haya completado, verificado y validado toda la migración de datos BigInt/TimeZone, ejecute este script para limpiar cualquier artefacto temporal de la base de datos creado por el script principal de actualización de ThingWorx:
cleanup_update_postgres.ps1
| | Si se ejecuta este script sin argumentos, se imprime su sentencia de uso: 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?" |
• Actualización del instalador a 9.0.x, 9.1.x, 9.2.x
Una vez definida la zona horaria, vaya a <UbicaciónDeInstalación>/schema/update y ejecute los scripts correspondientes para la combinación de sistema operativo y base de datos (por ejemplo, para Windows, los ficheros .bat que se enumeran a continuación y, para una instalación RHEL, los ficheros .sh) en el siguiente orden:
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
Los scripts toman parámetros, como los siguientes:
-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)
Para obtener más información sobre estos parámetros y las entradas previstas, consulte Actualización manual local: Windows o Actualización manual local: Linux.
Se le pedirá que introduzca la contraseña del usuario de la base de datos, que se transmite en los parámetros -u o -l.
| | Los scripts StreamDataUpdate y ValueStreamDataUpdate (por ejemplo, thingworxPostgresStreamDataUpdate.bat y thingworxPostgresValueStreamDataUpdate.bat) están diseñados para ejecutarse de forma asincrónica. Los scripts están diseñados para seleccionar dónde se pararon y operar por lotes, de modo que se puedan migrar los datos mientras se ejecuta la instancia de ThingWorx. Estos scripts pueden tardar mucho tiempo en ejecutarse, en función del volumen de los datos. |
El script DataTableDataUpdate (por ejemplo, thingworxPostgresDataTableDataUpdate.bat) mostrará el siguiente mensaje durante la ejecución: Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server.
Una vez que el script DataTableDataUpdate haya publicado este mensaje, se puede reiniciar la instancia de ThingWorx y continuar con los scripts de migración de datos restantes. Los scripts restantes se pueden ejecutar mientras ThingWorx está en ejecución y finalizarán la migración de los datos de flujo y flujo de valor.
Una vez completada la migración, se debe ejecutar el script de limpieza (por ejemplo, "thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh") para limpiar la tabla migration_log y las funciones de migración.
E) Ejecución del script de limpieza para la versión 9.2 y posteriores
Si se está actualizando a ThingWorx 9.2. x o una versión posterior, se debe ejecutar el script de limpieza para quitar las tablas temporales creadas durante el proceso de actualización.
Ejecute el script de limpieza thingworx<nombre_base_datos>DBCleanupPermissionTempTableUpdate.bat(Windows) o thingworx<nombre_base_datos>DBCleanupPermissionTempTableUpdate.sh (Linux) que se encuentra en <Dir_instalación>/schema/update.
Los scripts toman parámetros, como los siguientes:
-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)
Se le pedirá que introduzca la contraseña del usuario de la base de datos, que se transmite en los parámetros -u o -l.
F) Limpieza opcional adicional para la versión 9.3 y posteriores
Si se está actualizando desde ThingWorx 9.2.x o una versión anterior, y se ha activado el inicio de sesión único con la codificación de tokens de acceso, hay un paso de limpieza opcional que se puede realizar. En las versiones anteriores a 9.3, se utiliza la herramienta KeyCzar para cifrar los tokens de acceso antes de que se conserven en la base de datos. KeyCzar requiere la creación de una carpeta symmetric en la carpeta ThingworxPlatform\ssoSecurityConfig del directorio de instalación de ThingWorx.
La herramienta KeyCzar ya está obsoleta. En ThingWorx 9.3 y versiones posteriores, se ha reemplazado por el uso de Tink para la codificación de tokens de acceso. Tink no requiere la carpeta symmetric ni el parámetro keyczarKeyFolderPath del fichero sso-settings.json de ThingWorx. Estos ficheros y configuraciones se pueden dejar tal como están y ThingWorx 9.3 y las versiones posteriores simplemente los desestimarán. Sin embargo, si el usuario decide quitarlos, debe esperar hasta que se haya completado el procedimiento de actualización.
G) (Opcional) Actualización a PostgreSQL 13
La actualización de una versión anterior de PostgreSQL a PostgreSQL 13 es opcional para ThingWorx 9.2.0 y versiones posteriores.
1. Cree una copia de seguridad de la base de datos. Esta es la segunda copia de seguridad que se realiza, ya que se hará una copia de seguridad de la base de datos después de la actualización de ThingWorx.
2. Descargue PostgreSQL 13.
3. Actualice a PostgreSQL 13 empleando la documentación de PostgreSQL como referencia.
H) Resolución de problemas
• Si la actualización falla con el siguiente error, siga los pasos que se indican a continuación. Este error se producirá si algún valor de índice personalizado es mayor o igual que 64 caracteres.
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. Ejecute thingworxMssqlSchemaUpdate<versiónAnterior>-to-<versiónActual>.bat/.sh o el script SQL:
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
Al ejecutar este script, aumentará la longitud de las columnas de mskey y se actualizarán los índices.
b. Inicie Tomcat.
• Si existe una instalación de ThingWorx 8.5.3 o una versión anterior, pero el instalador no la encuentra, ejecute ThingWorx Upgrade-Ready Utility.
• Si el instalador no puede completar la actualización, realice lo siguiente:
1. Verifique los ficheros de registro del directorio de instalación en /installer/logs.
2. Revierta a la instalación previa a la actualización:
a. Restaure la base de datos a su copia de seguridad.
b. Inicie el servicio ThingWorx-Foundation.
• Si el instalador se ha ejecutado correctamente, ThingWorx Foundation se ha actualizado. Sin embargo, es posible que el nombre de la ubicación de instalación de ThingWorx Foundation no sea actual. Se puede verificar la versión de ThingWorx en > en Composer.
• Si el sistema operativo es RHEL 8.2 y se actualiza desde ThingWorx 8.5.7, primero se debe desinstalar manualmente Chef Infra Client para garantizar que el instalador pueda suministrar y utilizar una versión soportada de Chef. Para desinstalar Chef, realice lo siguiente:
a. Para buscar el nombre del paquete del instalador de Chef Infra Client, ejecute el siguiente comando: $ rpm -qa chef.
La salida debe ser similar a la siguiente: chef-14.10.9-1.el7.x86_64.rpm.
b. Copie el nombre del paquete de la salida que se encuentra arriba.
c. Ejecute el siguiente comando con el nombre del paquete copiado: $ sudo yum remove <copied_package_name>.
Por ejemplo: $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm.
d. Vaya al directorio /opt y quite todos los ficheros de Chef Infra Client. Para ello, borre el directorio de instalación $ sudo rm -rf /opt/chef.