Upgrade mit dem Installationsprogramm
Wenn Sie ThingWorx Foundation 8.5.0 oder höher mit dem ThingWorx Foundation Installationsprogramm installiert haben, können Sie das Installationsprogramm verwenden, um ein Upgrade für ThingWorx Foundation, einschließlich Upgrades für Wartungsversionen, durchzuführen. Links zu unterstützten Upgrade-Matrizen für jede ThingWorx Version finden Sie unter Upgrade für ThingWorx ausführen.
 |
Ab ThingWorx 9.4 können Kunden kein direktes Upgrade von ThingWorx 8.5 oder ThingWorx 9.0 auf ThingWorx 9.4.0 mehr durchführen. Kunden, die ein Upgrade von ThingWorx 8.5 oder ThingWorx 9.0 auf ThingWorx 9.4.0 und höher durchführen möchten, müssen auf eine Zwischenversion aktualisieren und dann ein Upgrade auf ThingWorx 9.4.0 und höher durchführen. ThingWorx empfiehlt, die neueste ThingWorx 9.3.x Version als Zwischenversion für ein Upgrade zu verwenden.
|
|
|
Wenn Sie ein Upgrade auf ThingWorx 9.2 und PostgreSQL 13 durchführen, ist das Upgrade von PostgreSQL der letzte Schritt im Upgrade-Prozess.
|
|
|
Der Benutzer, der das Upgrade durchführt, muss der Benutzer sein, der die ursprüngliche Installation der Anwendung durchgeführt hat.
|
A.) Voraussetzungen
• Java-Anforderungen (Installationsprogramm packt oder installiert Java nicht als Teil der Installation):
◦ Das Upgrade sollte von dem Benutzer ausgeführt werden, der ThingWorx ursprünglich installiert hat. Während der ursprünglichen Installation generiert das Installationsprogramm die Datei ThingWorxFoundation.xml, die Informationen zur Installation enthält und für das Upgrade erforderlich ist. Diese Datei befindet sich unter dem Benutzerprofil des Benutzers, der die Installation ausführt. Beispielsweise in C:\Users\Administrator\.ptc_cci.
◦ ThingWorx Foundation 9.2 erfordert Java 11. Java 8 muss jedoch ebenfalls installiert sein. Verifizieren Sie, ob unterstützte Versionen von Java 8 und 11 vor dem Ausführen des Installationsprogramms installiert sind. Fügen Sie Java 11 zur Umgebungsvariable PATH hinzu.
◦ Wenn Sie ThingWorx 9.0 oder niedriger auf Java 8 ausführen und ein Upgrade auf ThingWorx 9.2 durchführen, müssen Sie Java 11 vorinstallieren. ThingWorx sollte aber nicht auf die neue JVM verweisen. JAVA_HOME sollte auf den Java 8-Ordner eingestellt bleiben. Beide Java-Verzeichnisse sollten sich in der Umgebungsvariable PATH befinden. java8/bin sollte jedoch vor java11/bin in der Variable PATH aufgeführt werden. Während des Upgrade auf 9.2 wechselt das Installationsprogramm auch die verwendete Version von Java in Java 11, da ThingWorx 9.2 Java 8 nicht unterstützt.
◦ Wenn Sie ThingWorx 9.1 ausführen, unterstützt es Java 8 und Java 11, sodass Sie entweder den obigen Anweisungen folgen (beide installieren/im Pfad haben) oder Ihre ThingWorx 9.1 Instanz zu Java 11 migrieren können, bevor Sie mit dem Upgrade beginnen.
• Sichern Sie Ihre Datenbank. Das Installationsprogramm führt während des Upgrade-Prozesses keine Datenbanksicherung aus.
• Sie müssen eines der folgenden Betriebssysteme mit diesen Datenbank-Kombinationen verwenden:
◦ Windows mit PostgreSQL
◦ Windows mit Microsoft SQL Server
◦ Red Hat Enterprise Linux mit PostgreSQL
◦ Red Hat Enterprise Linux mit Microsoft SQL Server
Versionsinformationen finden Sie unter Systemanforderungen.
• Das Upgrade schlägt fehl, wenn einer der benutzerdefinierten Indexfeldwerte in den Datentabellen fehlt. Überprüfen Sie, ob alle benutzerdefinierten Indexfelder Werte aufweisen, bevor Sie den Upgrade-Prozess starten.
B.) ThingWorx Upgrade Ready Utility ausführen
Wenn ThingWorx Foundation 8.5.3 oder früher installiert ist, sollten Sie zuerst die ThingWorx Upgrade Ready Utility ausführen. Dieses Dienstprogramm ist auf der Seite > > > > > verfügbar.
Das ThingWorx Upgrade-Ready Utility erstellt XML-Dateien, die zur Unterstützung des automatisierten Upgrades von ThingWorx Foundation und – sofern installiert – von ThingWorx Flow erforderlich sind. Das Dienstprogramm fordert Sie auf, ThingWorx Foundation und – sofern installiert – ThingWorx Flow auf Ihrem System zu suchen, und konfiguriert dann die ausgewählten Installationen. Es erstellt die Datei ThingWorxFoundation.xml, und – wenn ThingWorx Flow installiert ist – die Datei ThingWorxFlow.xml in Ihrem Benutzerprofil. Die Dateien werden im Ordner .ptc_ccif in Ihrem Benutzerprofil gespeichert (z.B. unter Windows: C:\Users\Administrator\.ptc_ccif; unter Linux: ~/.ptc_ccif/).
Wenn Sie ThingWorx 8.5.4 oder höher mit dem Installationsprogramm installiert haben, wurden die erforderlichen XML-Dateien bereits im Rahmen der Installation erstellt. Daher ist es nicht erforderlich, das ThingWorx Upgrade-Ready Utility auszuführen.
Problembehandlung
• Wenn Sie ThingWorx Foundation 8.5.3 oder früher mit dem Installationsprogramm installiert und dann manuell ein Upgrade auf eine höhere 8.5.x-Version durchgeführt haben und jetzt das Upgrade auf 9.x vorbereiten, indem Sie das ThingWorx Upgrade Ready Utility ausführen, gehen Sie wie folgt vor:
◦ Führen Sie das ThingWorx Upgrade-Ready Utility aus.
◦ Überprüfen Sie, ob der Wert der Eigenschaft <applicationVersion> in der Datei ThingWorxFoundation.xml in Ihrem Benutzerprofil Ihre aktuelle Version ist.
• Wenn Sie Probleme beim Ausführen des ThingWorx Upgrade-Ready Utility hatten und die Datei ThingWorxFoundation.xml manuell erstellen oder bearbeiten müssen, können Sie das folgende Beispiel verwenden und es entsprechend Ihrem Upgrade-Pfad aktualisieren:
<?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.) Upgrade
1. Stellen Sie sicher, dass die in den obigen Abschnitten beschriebenen Voraussetzungen erfüllt sind.
2. Die neuesten Installationsdateien für ThingWorx Foundation für lokale Installationen sind auf der Seite support.ptc.com unter Software herunterladen > Software-Aktualisierungen bestellen oder herunterladen > ThingWorx Foundation > Release x.x > ThingWorx PostgreSQL oder ThingWorx Mssql verfügbar.
3. Das Installationsprogramm listet die vorhandenen Installationsinformationen auf, einschließlich:
◦ Installationsverzeichnis
◦ Port
◦ SSL-Konfigurationseinstellung
◦ SSO-Konfigurationseinstellung
4. Ihnen wird der PTC Lizenzvertrag angezeigt. Sie müssen die Bedingungen des Vertrags akzeptieren, bevor Sie mit dem Upgrade fortfahren können.
5. Sie müssen das ThingWorx Foundation Administratorpasswort, oder wenn SSO konfiguriert ist, Ihren Anwendungsschlüssel eingeben.
6. Sie können die Installationskonfigurationsinformationen prüfen und bestätigen.
7. Das Installationsprogramm schließt das Upgrade ab.
Sie können jetzt ein Upgrade für Erweiterungen und Anwendungen auf kompatible Versionen durchführen.
D.) Zeitzonendaten migrieren
| | Bei einer Aktualisierung auf ThingWorx 9.4.0 und höher ist keine Migration von Zeitzonendaten erforderlich. Direkte Upgrades von ThingWorx 8.5 oder ThingWorx 9.0 auf ThingWorx 9.4 werden nicht unterstützt. Die Migration der Zeitzonen erfolgt während der Migration zur Zwischenversion. |
Wenn eine der folgenden Aussagen zutrifft, müssen Sie wichtige Datenmigrationsschritte in diesem Abschnitt ausführen:
• ThingWorx 8.5.x ist installiert und Sie haben das Installationsprogramm verwendet, um ein Upgrade auf ThingWorx 9.0.x oder 9.1 durchzuführen.
• ThingWorx 9.0.x ist installiert und Sie haben das Installationsprogramm verwendet, um ein Upgrade auf ThingWorx 9.0.3 oder höher durchzuführen.
Gehen Sie wie folgt vor, um diese Datenmigration durchzuführen:
1. Halten Sie ThingWorx und Apache Tomcat unmittelbar nach dem erfolgreichen Upgrade an.
2. Legen Sie den Zeitzonenparameter -Duser.timezone=UTC mit den unten für Ihr Betriebssystem angegebenen Schritten manuell fest.
Zeitzoneneinstellungen unter Windows konfigurieren
1. Halten Sie den Dienst ThingWorx-Foundation an.
2. Führen Sie CMD als Administrator aus.
3. Wechseln Sie im ThingWorx Foundation Installationsverzeichnis zum Tomcat-Verzeichnis /bin.
Beispiel: cd C:\Programme (x86) \ThingWorxFoundation\tomcat\apache-Tomcat-9.0.37\bin.
4. Bearbeiten Sie die Konfiguration des Diensts ThingWorx-Foundation, um die GUI-Anwendung zu öffnen, indem Sie Folgendes ausführen:
tomcat9w.exe //ES//ThingWorx-Foundation
5. Wechseln Sie zur Registerkarte Java der GUI-Anwendung.
a. Fügen Sie Folgendes zu Java Options hinzu: -Duser.timezone=UTC
b. Wählen Sie Apply.
6. Wählen Sie OK, um die GUI zu schließen.
7. Aktualisieren Sie die Dienstparameter mit tomcat9.exe.
8. Führen Sie CMD als Administrator aus, und führen Sie Folgendes aus:
tomcat9.exe //US//ThingWorx-Foundation
Zeitzoneneinstellungen unter Linux konfigurieren
1. Halten Sie den Dienst ThingWorx-Foundation mit systemctl stop ThingWorx-Foundation.service an.
2. Sichern Sie ThingWorx-Foundation.service im Verzeichnis /etc/systemd/system/ThingWorx-Foundation.service.backup.
3. Bearbeiten Sie die Dienstkonfiguration, indem Sie den ThingWorx-Foundation.service für JVM-Optionen ändern:
a. Hängen Sie Folgendes an CATALINA_OPTS an: -Duser.timezone=UTC.
4. Führen Sie Folgendes aus: systemctl daemon-reload.
Skripts ausführen
• Upgrade mit dem Installationsprogramm auf 9.3.x und höhere Versionen
1. Rufen Sie die Liste aller datenbankspezifischen Zeitzonennamen ab. Stellen Sie dazu manuell eine Verbindung zu der Datenbank her, und führen Sie diese Abfrage aus, um eine Liste mit den Namen aller Zeitzonen abzurufen, die derzeit von der Datenbank unterstützt werden:
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | Bewahren Sie diese Liste zur späteren Referenz auf. |
2. Ermitteln Sie den Namen der Zeitzone, der alle vorhandenen ThingWorx Daten derzeit zugeordnet sind (Ihre "Von"-Zeitzone):
▪ Ermitteln Sie den Zeitzonenwert, den Sie oben im Abschnitt "Zeitzone für den ThingWorx Server festlegen" oben notiert haben.
▪ Dieser Wert ist die Zeitzone, der alle vorhandenen ThingWorx Daten derzeit zugeordnet sind.
▪ Dieser Wert ist entweder für die JVM oder das Betriebssystem spezifisch und stimmt möglicherweise mit keinem der Zeitzonennamen in der datenbankspezifischen Liste (in Schritt 1 abgerufen) genau überein.
▪ Überprüfen Sie die Liste der von der Datenbank abgerufenen Zeitzonen manuell, um zu ermitteln, welcher Zeitzonenname am ehesten mit diesem Wert aus dem Abschnitt "Zeitzone für den ThingWorx Server festlegen" übereinstimmt.
▪ Nachdem Sie die passendste Übereinstimmung gefunden haben, wird dieser Zeitzonenname zur "Von"-Zeitzone (im Gegensatz zur "In"-Zeitzone), die in späteren Schritten benötigt wird.
3. Bestimmen Sie die Zeitzone, in die alle vorhandenen ThingWorx Daten migriert werden sollen (Ihre "In"-Zeitzone):
▪ Legen Sie im Abschnitt "Zeitzone für den ThingWorx Server festlegen" die Tomcat-Konfigurationseinstellung -Duser.timezone auf UTC fest. Dies ist die Zeitzone, in die alle vorhandenen ThingWorx Daten migriert werden sollen. Dieser Wert ist jedoch für die JVM spezifisch und stimmt möglicherweise mit keinem der Zeitzonennamen in der abgerufenen Datenbankliste (in Schritt 1 abgerufen) überein.
▪ Überprüfen Sie die Liste der von der Datenbank abgerufenen Zeitzonen manuell, um zu ermitteln, welcher Zeitzonenname am ehesten mit diesem UTC-Wert übereinstimmt.
▪ Nachdem Sie die passendste Übereinstimmung gefunden haben, wird dieser Zeitzonenname zur "In"-Zeitzone (im Gegensatz zur "Von"-Zeitzone), die in späteren Schritten benötigt wird.
| | Die Namen der "Von"- und "In"-Zeitzone können identisch sein. |
4. Führen Sie das BigInt/Zeitzonen-Schemaskript aus, um die Migration aller Datentabellen-, Stream- und Wert-Stream-Daten vorzubereiten:
update_bigint_timezone_schema_postgres.ps1
| | Wenn Sie dieses Skript ohne Argumente ausführen, wird die Anweisung zur Verwendung des Skripts gedruckt: 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?" |
| | Während dieses Skript einige Daten direkt migriert, migriert es keine Datentabellen-, Stream- oder Wert-Stream-Daten. Stattdessen erstellt dieses Skript eine Sicherung aller Datentabellen-, Stream- und Wert-Stream-Daten, sodass sie später migriert werden können. Aus Leistungsgründen erstellt dieses Skript nicht wirklich eine Sicherungskopie der Daten in den vorhandenen Datentabellen-, Stream- und Wert-Stream-Tabellen. Stattdessen benennt dieses Skript die vorhandenen Tabellen von "foo" in "foo_backup" um. Dadurch wird der möglicherweise zeitaufwendige Prozess des Kopierens großer Datenmengen umgangen. Sobald diese vorhandenen Tabellen umbenannt wurden (sodass sie zu ihren eigenen Sicherungstabellen werden), werden neue Tabellen mit den ursprünglichen Namen erstellt. Diese neuen Tabellen sind leer und dienen demselben Zweck wie die ursprünglichen Tabellen (da sie dieselben Namen wie die ursprünglichen Tabellen haben). |
5. Nach Abschluss des vorherigen Schritts kann die Plattform bei Bedarf neu gestartet werden. Beachten Sie jedoch, dass Datentabellen-, Stream- und Wert-Stream-Daten noch nicht migriert wurden. Daher können Abfragen für diese Daten reduzierte Ergebnissätze zurückgeben, bis diese Datenmigration stattfindet.
6. Führen Sie das BigInt/Zeitzonen-Datenskript aus, um Datentabellen-, Stream- oder Wert-Stream-Daten zu migrieren:
update_bigint_timezone_data_postgres.ps1
| | Wenn Sie dieses Skript ohne Argumente ausführen, wird die Anweisung zur Verwendung des Skripts gedruckt: 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?" |
| | • Gemäß der vorstehenden Verwendungsanweisung kann nur jeweils eine "--update..."-Option angegeben werden. Dieses Skript muss daher dreimal ausgeführt werden (einmal für jeden Datensatz), um alle Datentabellen-, Stream- und Wert-Stream-Daten zu migrieren. Da diese Datensätze voneinander unabhängig sind, kann die Migration eines Datensatzes parallel zur Migration eines anderen Datensatzes durchgeführt werden. Wenn Sie beispielsweise drei separate Befehlsfenster öffnen, können Sie gleichzeitig im ersten Fenster die Datentabelle, im zweiten Fenster den Stream und im dritten Fenster den Wert-Stream migrieren. Versuchen Sie jedoch nicht, mehr als einen Prozess zur gleichzeitigen Migration eines bestimmten Datensatzes zu verwenden. Versuchen Sie beispielsweise nicht, zwei gleichzeitige Prozesse zum Migrieren von Wert-Stream-Daten auszuführen. Dieses Verfahren ist nicht definiert und führt zu Datenbeschädigungen. • Die vorgeschlagene chunk_size für eine typische Umgebung ist 10000. • Da die Plattform neu gestartet werden kann, bevor die Datenmigration vollständig abgeschlossen ist, erfolgt die Datenmigration von den neuesten Daten zu den ältesten Daten. Dies ist beabsichtigt und ermöglicht es allen Abfragen für diese Daten, zuerst die relevantesten Daten zu erhalten. • Die Größe Ihrer Datensätze kann erhebliche Auswirkungen darauf haben, wie lange es dauert, bis alle Daten migriert sind. Wenn Sie beispielsweise Milliarden von Zeilen migrieren müssen, kann die Migration dieser Daten mehrere Tage dauern. |
7. Nachdem die Migration von BigInt/Zeitzonen-Daten vollständig abgeschlossen wurde und alle migrierten BigInt/Zeitzonen-Daten manuell verifiziert und validiert wurden, führen Sie das BigInt/Zeitzonen-Bereinigungsskript aus, um alle temporären Datenbank-Artefakte, die durch das BigInt/Zeitzonen-Schemaskript erstellt wurden, zu bereinigen:
cleanup_bigint_timezone_data_update_postgres.ps1
| | Wenn Sie dieses Skript ohne Argumente ausführen, wird die Anweisung zur Verwendung des Skripts gedruckt: 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?" |
| | Obwohl dieses Skript einige temporäre Datenbankobjekte bereinigt, die während des Upgrade-Prozesses erstellt wurden, löscht es keine der in den vorherigen Schritten erstellten Sicherungstabellen und ändert auch keine Daten in diesen Sicherungstabellen. Dies ist beabsichtigt und stellt sicher, dass Daten nicht versehentlich gelöscht werden können. Wenn Sie diese Sicherungstabellen löschen möchten, müssen Sie dies manuell tun. |
8. Führen Sie das Haupt-Bereinigungsskript aus, nachdem die Datenmigration vollständig abgeschlossen, verifiziert und validiert wurde.
Nachdem die Migration von BigInt/Zeitzonen-Daten vollständig abgeschlossen, verifiziert und validiert wurde, führen Sie dieses Skript aus, um alle temporären Datenbank-Artefakte, die durch das ThingWorx Haupt-Aktualisierungsskript erstellt wurden, zu bereinigen:
cleanup_update_postgres.ps1
| | Wenn Sie dieses Skript ohne Argumente ausführen, wird die Anweisung zur Verwendung des Skripts gedruckt: 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?" |
• Upgrade mit dem Installationsprogramm auf 9.0.x, 9.1.x, 9.2.x
Nachdem die Zeitzone festgelegt wurde, gehen Sie zu <Installationsspeicherort>/schema/update, und führen Sie die entsprechenden Skripts für Ihre Kombination von Betriebssystem und Datenbank (z.B. für Windows .bat-Dateien, wie unten aufgeführt; für eine RHEL-Installation .sh -Dateien) in der folgenden Reihenfolge aus:
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
Die Skripts akzeptieren Parameter wie die folgenden:
-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)
Weitere Informationen zu diesen Parametern und ihren erwarteten Eingaben finden Sie unter Manuelles direktes Upgrade: Windows oder Manuelles direktes Upgrade: Linux.
Sie werden aufgefordert, das Passwort für den Datenbankbenutzer einzugeben, der in den Parametern -u oder -l übergeben wird.
| | Die StreamDataUpdate- und ValueStreamDataUpdate-Skripts (z.B. thingworxPostgresStreamDataUpdate.bat und thingworxPostgresValueStreamDataUpdate.bat) sind zur asynchronen Ausführung vorgesehen. Die Skripts sind so konzipiert, dass sie dort weitermachen, wo sie aufgehört haben. Außerdem arbeiten sie in Batches, sodass Sie Ihre Daten migrieren können, während die ThingWorx Instanz ausgeführt wird. Je nach Volumen Ihrer Daten kann die Ausführung dieser Skripts viel Zeit in Anspruch nehmen. |
Das Skript DataTableDataUpdate (z.B. thingworxPostgresDataTableDataUpdate.bat) zeigt während der Ausführung die folgende Meldung an: Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server.
Sobald das DataTableDataUpdate-Skript diese Meldung gesendet hat, können Sie die ThingWorx Instanz neu starten und mit den verbleibenden Datenmigrationsskripts fortfahren. Die verbleibenden Skripts können ausgeführt werden, während ThingWorx ausgeführt wird. Mit ihnen wird die Migration von Stream- und Wert-Stream-Daten abgeschlossen.
Wenn die Migration abgeschlossen ist, sollten Sie das Bereinigungsskript ausführen (z.B. "thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh"), um die Tabelle migration_log und die Migrationsfunktionen zu bereinigen.
E.) Bereinigungsskript für 9.2+ ausführen
Wenn Sie ein Upgrade auf ThingWorx 9.2.x oder höher durchführen, müssen Sie das Bereinigungsskript ausführen, um temporäre Tabellen, die während des Upgrade-Prozesses erstellt wurden, zu löschen.
Führen Sie das Bereinigungsskript thingworx<Datenbankname>DBCleanupPermissionTempTableUpdate.bat (Windows) oder thingworx<Datenbankname>DBCleanupPermissionTempTableUpdate.sh (Linux) in <Installationsverzeichnis>/Schema/Update aus.
Die Skripts akzeptieren Parameter wie die folgenden:
-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)
Sie werden aufgefordert, das Passwort für den Datenbankbenutzer einzugeben, der in den Parametern -u oder -l übergeben wird.
F.) Zusätzliche optionale Bereinigung für 9.3+
Wenn Sie ein Upgrade von ThingWorx 9.2.x oder früher durchführen und Single Sign-On mit Verschlüsselung des Zugriffs-Tokens aktiviert ist, kann die Durchführung eines optionalen Bereinigungsschritts sinnvoll sein. In Versionen vor 9.3 wird das Keyczar-Tool verwendet, um Zugriffs-Token zu verschlüsseln, bevor sie in der Datenbank persistent gemacht werden. Keyczar erfordert die Erstellung des Ordners symmetric im Ordner ThingworxPlatform\ssoSecurityConfig Ihres ThingWorx Installationsverzeichnisses.
Das Keyczar-Tool ist jetzt veraltet. In ThingWorx 9.3 und höher wurde es durch Tink ersetzt, das jetzt zur Verschlüsselung von Zugriffs-Token verwendet wird. Für Tink ist der Ordner symmetric oder der Parameter keyczarKeyFolderPath in der ThingWorx Datei sso-settings.json nicht erforderlich. Sie können diese Dateien und Einstellungen unverändert lassen. Sie werden in ThingWorx 9.3 und höher einfach ignoriert. Wenn Sie sie jedoch entfernen möchten, müssen Sie warten, bis das Upgrade-Verfahren abgeschlossen ist.
G.) (Optional) Upgrade auf PostgreSQL 13
Das Upgrade von einer älteren PostgreSQL-Version auf PostgreSQL 13 ist für ThingWorx 9.2.0 und höher optional.
1. Sichern Sie die Datenbank. Dies ist die zweite Sicherung, die Sie durchführen, da dadurch Ihre Datenbank nach dem ThingWorx Upgrade gesichert wird.
2. Laden Sie PostgreSQL 13 herunter.
3. Führen Sie das Upgrade auf PostgreSQL 13 unter Verwendung der PostgreSQL-Dokumentation als Referenz durch.
H.) Problembehandlung
• Wenn das Upgrade mit dem folgenden Fehler fehlschlägt, führen Sie die nachfolgenden Schritte aus. Dieser Fehler tritt auf, wenn ein benutzerdefinierter Indexwert 64 oder mehr Zeichen hat.
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. Führen Sie thingworxMssqlSchemaUpdate<vorherigeVersion>-to-<aktuelleVersion>.bat/.sh oder das SQL-Skript aus:
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
Durch Ausführen dieses Skripts wird die mskey-Spalte länger und Indizes werden aktualisiert.
b. Starten Sie Tomcat.
• Wenn Sie über eine vorhandene Installation von ThingWorx 8.5.3 oder früher verfügen, das Installationsprogramm diese jedoch nicht gefunden hat, führen Sie das ThingWorx Upgrade-Ready Utility aus.
• Wenn das Installationsprogramm das Upgrade nicht abschließen kann, gehen Sie wie folgt vor:
1. Prüfen Sie die Protokolldateien in Ihrem Installationsverzeichnis unter /installer/logs.
2. Stellen Sie die Installation vor dem Upgrade wieder her:
a. Stellen Sie Ihre Datenbank auf ihre Sicherung wieder her.
b. Starten Sie den ThingWorx-Foundation-Dienst.
• Wenn das Installationsprogramm erfolgreich ausgeführt wurde, wurde ein Upgrade von ThingWorx Foundation durchgeführt. Der Name des ThingWorx Foundation Installationsspeicherortes ist jedoch möglicherweise nicht aktuell. Sie können Ihre ThingWorx Version in Composer unter > prüfen.
• Wenn Sie RHEL 8.2 als Betriebssystem nutzen und ein Upgrade von ThingWorx 8.5.7 durchführen, sollten Sie zuerst den Chef Infra Client manuell deinstallieren, um sicherzustellen, dass das Installationsprogramm eine unterstützte Version von Chef bereitstellen und verwenden kann. Gehen Sie zum Deinstallieren von Chef folgendermaßen vor:
a. Führen Sie den folgenden Befehl aus, um den Paketnamen des Chef Infra Client-Installationsprogramms zu suchen: $ rpm -qa chef.
Die Ausgabe sollte wie folgt aussehen: chef-14.10.9-1.el7.x86_64.rpm.
b. Kopieren Sie den Paketnamen aus der oben gefundenen Ausgabe.
c. Führen Sie den folgenden Befehl mit dem kopierten Paketnamen aus: $ sudo yum remove <copied_package_name>.
Beispiel: $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm.
d. Wechseln Sie zum Verzeichnis /opt, und entfernen Sie alle Chef Infra Client-Dateien, indem Sie das Installationsverzeichnis $ sudo rm -rf /opt/chef löschen.