설치 관리자 업그레이드
ThingWorx Foundation 설치 관리자를 사용하여 ThingWorx Foundation 8.5.0 이상을 설치한 경우 설치 관리자를 사용하여 유지보수 릴리즈 업그레이드를 비롯한 ThingWorx Foundation을 업그레이드할 수 있습니다. 각 ThingWorx 버전에 대해 지원되는 업그레이드 매트릭스 링크는 ThingWorx 업그레이드를 참조하십시오.
 |
ThingWorx 9.4부터 고객은 ThingWorx 8.5 또는 ThingWorx 9.0에서 ThingWorx 9.4.0으로 직접 업그레이드할 수 없습니다. ThingWorx 8.5 또는 ThingWorx 9.0에서 9.4.0 이상으로 업그레이드하려는 고객은 중간 버전으로 업그레이드한 다음 ThingWorx 9.4.0 이상으로 업그레이드해야 합니다. 최신 ThingWorx 9.3.x를 중간 업그레이드 경로로 사용하는 것이 좋습니다.
|
|
|
ThingWorx 9.2 및 PostgreSQL 13으로 업그레이드하는 경우 PostgreSQL 업그레이드가 업그레이드 프로세스의 마지막 단계가 됩니다.
|
|
|
업그레이드를 수행하는 사용자는 응용 프로그램의 원래 설치를 수행한 사용자와 동일해야 합니다.
|
A.) 사전 요구 사항
• Java 요구 사항(설치 프로그램이 설치의 일부로 Java를 패키징하거나 설치하지 않음):
◦ ThingWorx를 처음 설치한 사용자는 업그레이드를 실행해야 합니다. 초기 설치 중 설치 관리자는 설치에 대한 정보를 포함하고 업그레이드에 필요한 ThingWorxFoundation.xml 파일을 생성합니다. 이 파일은 설치를 실행하는 사용자의 사용자 프로파일에 있습니다. 예를 들어, C:\Users\Administrator\.ptc_cci 내에 있습니다.
◦ ThingWorx Foundation 9.2에는 Java 11이 필요하지만 Java 8도 설치해야 합니다. 설치 프로그램을 실행하기 전에 지원되는 Java 8 및 11 버전이 설치되어 있는지 확인합니다. Java 11을 PATH 환경 변수에 추가합니다.
◦ Java 8에서 ThingWorx 9.0 이하를 실행 중이고 ThingWorx 9.2로 업그레이드하는 경우 Java 11을 사전 설치해야 하지만 새 jvm을 가리키도록 ThingWorx를 전환하지 마십시오. JAVA_HOME은 Java 8 폴더로 설정된 상태를 유지해야 합니다. 두 Java 디렉터리 모두 PATH 환경 변수에 있어야 하지만 PATH 변수에서 java8/bin은 java11/bin 앞에 나열되어야 합니다. ThingWorx 9.2는 Java 8을 지원하지 않으므로 9.2로 업그레이드하는 동안 설치 프로그램은 사용 중인 Java 버전도 Java 11로 전환합니다.
◦ ThingWorx 9.1을 실행 중인 경우 Java 8 및 Java 11을 지원하므로 위의 조언을 따르거나(둘 다 설치하고 경로에 모두 포함) 업그레이드를 시작하기 전에 ThingWorx 9.1 인스턴스를 Java 11로 마이그레이션할 수 있습니다.
• 데이터베이스를 백업합니다. 설치 관리자는 업그레이드 프로세스 중에 데이터베이스 백업을 실행하지 않습니다.
• 이러한 데이터베이스 조합을 사용하는 다음 운영 체제 중 하나가 있어야 합니다.
◦ Windows(PostgreSQL 포함)
◦ Windows(Microsoft SQL Server 포함)
◦ Red Hat Enterprise Linux(PostgreSQL 포함)
◦ Red Hat Enterprise Linux(Microsoft SQL Server 포함)
버전 정보는 시스템 요구사항을 참조하십시오.
• 데이터 테이블에 사용자 정의 색인 필드 값이 누락된 경우 업그레이드가 실패합니다. 업그레이드 프로세스를 시작하기 전에 모든 사용자 정의 색인 필드에 값이 있는지 확인합니다.
B.) ThingWorx 업그레이드 준비 유틸리티를 실행합니다.
ThingWorx Foundation 8.5.3 이하 버전이 설치되어 있는 경우 먼저 > > > > > 에서 사용 가능한 ThingWorx 업그레이드 준비 유틸리티를 실행해야 합니다.
ThingWorx 업그레이드 준비 유틸리티는 ThingWorx Foundation 및 ThingWorx Flow(설치된 경우)의 자동 업그레이드를 지원하는 데 필요한 XML 파일을 생성합니다. 이 유틸리티는 시스템에서 ThingWorx Foundation 및 ThingWorx Flow(설치된 경우)를 찾으라는 메시지를 표시한 다음 선택한 설치를 구성합니다. 사용자 프로파일에서 ThingWorxFoundation.xml 파일 및 ThingWorxFlow.xml 파일(ThingWorx Flow를 설치한 경우)을 생성합니다. 이러한 파일은 사용자 프로파일에서 .ptc_ccif 폴더에 저장됩니다(예를 들어 Windows의 경우: C:\Users\Administrator\.ptc_ccif, Linux의 경우: ~/.ptc_ccif/).
설치 관리자를 사용하여 ThingWorx 8.5.4 이상을 설치한 경우 필요한 XML 파일이 이미 설치 일부로 생성되었기 때문에 ThingWorx 업그레이드 준비 유틸리티를 실행할 필요가 없습니다.
문제 해결
• 설치 관리자를 사용하여 ThingWorx Foundation 8.5.3 이하를 설치하고 수동으로 이후 8.5.x 버전으로 업그레이드했고, 이제 ThingWorx 업그레이드 준비 유틸리티를 실행하여 9.x로 업그레이드할 준비를 하고 있는 경우 다음을 수행합니다.
◦ ThingWorx 업그레이드 준비 유틸리티를 실행합니다.
◦ 사용자 프로파일의 ThingWorxFoundation.xml 파일에 있는 <applicationVersion> 속성 값이 현재 버전인지 확인합니다.
• ThingWorx 업그레이드 준비 유틸리티를 실행하는 데 문제가 있어 ThingWorxFoundation.xml 파일을 수동으로 작성하거나 편집해야 할 경우 다음 예를 사용하고 업그레이드 경로를 기반으로 예를 업데이트할 수 있습니다.
<?xml version="1.0" encoding='utf-8'?>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
<installationInfo>
<projectFlavor>PostgreSQL</projectFlavor>
<applicationName>ThingWorxFoundation</applicationName>
<applicationVersion>9.0.1</applicationVersion>
<applicationInstallDir>C:\Program Files
(x86)\ThingWorxFoundation</applicationInstallDir>
</installationInfo>
C.) 업그레이드
1. 위의 단원에서 설명한 사전 요구 사항을 충족하는지 확인합니다.
2. support.ptc.com의 소프트웨어 다운로드 > 소프트웨어 업데이트 주문 또는 다운로드 > ThingWorx Foundation > 릴리즈 x.x > ThingWorx PostgreSQL 또는 ThingWorx Mssql에서 온프레미스 설치를 위한 최신 ThingWorx Foundation 설치 관리자 파일을 얻고 다운로드합니다.
3. 설치 관리자는 다음과 같은 기존 설치 정보를 나열합니다.
◦ 설치 디렉터리
◦ 포트
◦ SSL 구성 설정
◦ SSO 구성 설정
4. PTC 라이선스 계약이 표시됩니다. 업그레이드를 계속하기 전에 계약 약관에 동의해야 합니다.
5. ThingWorx Foundation 관리자 암호를 입력해야 합니다. SSO가 구성된 경우 응용 프로그램 키를 입력합니다.
6. 설치 구성 정보를 검토하고 확인할 수 있습니다.
7. 설치 관리자가 업그레이드를 완료합니다.
이제 확장 및 응용 프로그램을 호환되는 버전으로 업그레이드할 수 있습니다.
D.) 시간대 데이터 마이그레이션
| | ThingWorx 9.4.0 이상으로 업데이트할 때는 시간대 데이터를 마이그레이션할 필요가 없습니다. ThingWorx 8.5 또는 ThingWorx 9.0에서 ThingWorx 9.4로의 직접 업그레이드는 지원되지 않습니다. 시간대 마이그레이션은 중간 버전으로 마이그레이션하는 동안 수행됩니다. |
다음 중 하나가 참이면 이 단원에서 중요 데이터 마이그레이션 단계를 수행해야 합니다.
• ThingWorx 8.5.x가 설치되어 있고 설치 관리자를 사용하여 ThingWorx 9.0.x 또는 9.1로 업그레이드하는 경우
• ThingWorx 9.0.x가 설치되어 있고 설치 관리자를 사용하여 ThingWorx 9.0.3.x 이상으로 업그레이드하는 경우
이 데이터 마이그레이션을 수행하려면 다음을 수행합니다.
1. 업그레이드가 성공한 즉시 ThingWorx 및 Apache Tomcat을 중지합니다.
2. 사용자의 운영 체제에 따라 아래 단계를 사용하여 시간대 매개 변수 -Duser.timezone=UTC를 수동으로 설정합니다.
Windows에서 시간대 설정 구성
1. ThingWorx-Foundation 서비스를 중지합니다.
2. 관리자로 CMD를 실행합니다.
3. ThingWorx Foundation 설치 디렉터리 아래의 Tomcat /bin 디렉터리로 이동합니다.
예: cd C:\Program Files (x86)\ThingWorxFoundation\tomcat\apache-tomcat-9.0.37\bin
4. 다음을 실행하여 GUI 응용 프로그램을 열도록 ThingWorx-Foundation 서비스 구성을 편집합니다.
tomcat9w.exe //ES//ThingWorx-Foundation
5. GUI 응용 프로그램의 Java 탭으로 이동합니다.
a. Java Options에 다음 -Duser.timezone=UTC를 추가합니다.
b. 적용을 선택합니다.
6. 확인을 선택하여 GUI를 닫습니다.
7. tomcat9.exe를 사용하여 서비스 매개 변수를 업데이트합니다.
8. 관리자로 CMD를 실행하고 다음을 실행합니다.
tomcat9.exe //US//ThingWorx-Foundation
Linux에서 시간대 설정 구성
1. systemctl stop ThingWorx-Foundation.service를 사용하여 ThingWorx-Foundation 서비스를 중지합니다.
2. ThingWorx-Foundation.service를 /etc/systemd/system/ThingWorx-Foundation.service.backup에 백업합니다.
3. JVM 옵션에 대한 ThingWorx-Foundation.service를 변경하여 서비스 구성을 편집합니다.
a. CATALINA_OPTS에 다음을 추가합니다. -Duser.timezone=UTC
4. 다음을 실행합니다. systemctl daemon-reload
스크립트 실행
• 설치 관리자를 9.3.x 이상 버전으로 업그레이드
1. 모든 데이터베이스 관련 시간대 이름 목록을 가져옵니다. 이렇게 하려면 데이터베이스에 수동으로 연결하고 이 질의를 실행하여 현재 데이터베이스에서 지원되는 모든 시간대 이름 목록을 가져옵니다.
SELECT name, utc_offset, is_dst FROM pg_timezone_names ORDER BY name
| | 나중에 참조하도록 이 목록을 보관합니다. |
2. 모든 기존 ThingWorx 데이터가 현재 연관되어 있는 시간대의 이름을 확인합니다("시작" 시간대).
▪ 위의 "ThingWorx 서버 시간대 설정" 단원에서 기록해 둔 시간대 값을 가져옵니다.
▪ 이 값은 모든 기존 ThingWorx 데이터가 현재 연관되어 있는 시간대입니다.
▪ 이 값은 해당 JVM 또는 운영 체제와 관련되며 데이터베이스 특정 목록(1단계에서 질의됨) 내의 시간대 이름과 정확히 일치하지 않을 수 있습니다.
▪ 데이터베이스에서 질의된 시간대 목록을 수동으로 검사하여 "ThingWorx 서버 시간대 설정" 단원의 해당 값과 가장 적합하게 일치하는 시간대 이름을 확인합니다.
▪ 가장 적절한 일치 항목을 찾으면 해당 시간대 이름이 이후 단계에서 필요한 "시작" 시간대("끝" 시간대와 비교)가 됩니다.
3. 모든 기존 ThingWorx 데이터를 마이그레이션해야 하는 시간대를 확인합니다("끝" 시간대).
▪ 위의 "ThingWorx 서버 시간대 설정" 단원에서 Tomcat의 -Duser.timezone 구성 설정을 UTC로 설정합니다. 이는 모든 기존 ThingWorx 데이터가 마이그레이션되어야 하는 시간대입니다. 그러나 이 값은 JVM과 관련되며 질의된 데이터베이스 목록(1단계에서 질의됨) 내의 시간대 이름과 정확히 일치하지 않을 수 있습니다.
▪ 데이터베이스에서 질의된 시간대 목록을 수동으로 검사하여 해당 UTC 값과 가장 적합하게 일치하는 시간대 이름을 확인합니다.
▪ 가장 적절한 일치 항목을 찾으면 해당 시간대 이름이 이후 단계에서 필요한 "끝" 시간대("시작" 시간대와 비교)가 됩니다.
| | "시작" 시간대 이름과 및 "끝" 시간대 이름은 같을 수 있습니다. |
4. BigInt/Timezone 스키마 스크립트를 실행하여 모든 데이터 테이블, 스트림 및 가치 스트림 데이터의 마이그레이션을 준비합니다.
update_bigint_timezone_schema_postgres.ps1
| | 인수 없이 이 스크립트를 실행하면 해당 사용 문이 인쇄됩니다. Usage: update_bigint_timezone_schema_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. -y Suppress all non-required prompts, such as "Are you sure?" |
| | 이 스크립트는 일부 데이터는 직접 마이그레이션하지만 데이터 테이블, 스트림 또는 가치 스트림 데이터는 마이그레이션하지 않습니다. 대신 이 스크립트는 나중에 마이그레이션할 수 있도록 모든 데이터 테이블, 스트림 및 가치 스트림 데이터의 백업을 생성합니다. 성능상의 이유로 이 스크립트는 실제로 기존 데이터 테이블, 스트림 및 가치 스트림 테이블 내 데이터의 백업 복사본을 만들지 않습니다. 대신 이 스크립트는 기존 테이블의 이름을 "foo"에서 "foo_backup"으로 바꿉니다. 이렇게 하면 막대한 양의 데이터를 복사하는 잠재적으로 시간이 많이 소요되는 프로세스를 피할 수 있습니다. 기존 테이블의 이름이 바뀌고 자체 백업 테이블이 되면 원래 이름을 사용하여 새 테이블이 작성됩니다. 새 테이블은 비어 있으며 원래 테이블과 이름이 같기 때문에 원래 테이블과 동일한 용도로 사용됩니다. |
5. 이전 단계를 완료한 후 필요한 경우 플랫폼을 다시 시작할 수도 있습니다. 그러나 데이터 테이블, 스트림 및 가치 스트림 데이터는 아직 마이그레이션되지 않았습니다. 따라서 데이터 마이그레이션이 발생할 때까지 해당 데이터에 대한 질의에서 감소된 결과 집합을 받을 수도 있습니다.
6. BigInt/Timezone 데이터 스크립트를 실행하여 데이터 테이블, 스트림 또는 가치 스트림 데이터를 마이그레이션합니다.
update_bigint_timezone_data_postgres.ps1
| | 인수 없이 이 스크립트를 실행하면 해당 사용 문이 인쇄됩니다. Usage: update_bigint_timezone_data_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] --from_timezone <timezone> --to_timezone <timezone> --chunk_size <chunk_size> ( --update_data_table | --update_stream | --update_value_stream ) [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). --system_version_override version Forces the upgrade to assume the database schema is currently of this version (i.e. "n.n.n"), rather than of the actual, persisted version. --from_timezone timezone The name of the timezone for all existing data. --to_timezone timezone The name of the timezone to which all existing data will be updated. --chunk_size chunk_size The number of records to update per transaction. Must be greater than 0. --update_data_table Update "data_table" information. Cannot be specified with any other "--update_..." flag. --update_stream Update "stream" information. Cannot be specified with any other "--update_..." flag. --update_value_stream Update "data_table" information. Cannot be specified with any other "--update_..." flag. -y Suppress all non-required prompts, such as "Are you sure?" |
| | • 위의 사용 문에 따라 "--update…" 옵션은 한 번에 하나씩만 지정할 수 있습니다. 따라서 모든 데이터 테이블, 스트림 및 가치 스트림 데이터를 마이그레이션하려면 이 스크립트를 세 번 실행해야 합니다(각 데이터 집합에 대해 한 번씩). 이러한 데이터 집합은 서로 독립적이기 때문에 한 데이터 집합의 마이그레이션은 다른 데이터 집합의 마이그레이션과 동시에 수행될 수 있습니다. 예를 들어, 세 개의 별도 명령 창을 열면 첫 번째 창에서 데이터 테이블 마이그레이션, 두 번째 창에서 스트림 마이그레이션, 세 번째 창에서 가치 스트림 마이그레이션을 동시에 실행할 수 있습니다. 그러나 두 개 이상의 프로세스를 사용하여 지정된 데이터 집합을 동시에 마이그레이션하지 마십시오. 예를 들어, 가치 스트림 데이터를 마이그레이션하기 위해 두 개의 동시 프로세스를 사용하지 마십시오. 이러한 작업은 정의되지 않으며 데이터 손상을 유발합니다. • 일반적인 환경에 대한 권장 chunk_size는 10000입니다. • 모든 데이터 마이그레이션이 완료되기 전에 플랫폼을 다시 시작할 수 있으므로 가장 최신 데이터부터 가장 오래된 데이터까지 데이터 마이그레이션이 발생합니다. 이는 의도된 것으로, 해당 데이터에 대한 모든 질의가 가장 적절한 데이터를 먼저 수신하기 시작할 수 있도록 합니다. • 데이터 집합의 크기는 모든 데이터를 마이그레이션하는 데 걸리는 시간에 크게 영향을 줄 수 있습니다. 예를 들어, 마이그레이션할 행이 수십억 개인 경우 해당 데이터의 마이그레이션을 완료하는 데 며칠이 걸릴 수 있습니다. |
7. 모든 BigInt/Timezone 데이터 마이그레이션이 완료된 후 그리고 마이그레이션된 모든 BigInt/Timezone 데이터가 수동으로 확인 및 검증된 후 BigInt/Timezone 정리 스크립트를 실행하여 BigInt/Timezone 스키마 스크립트에 의해 생성된 임시 데이터베이스 아티팩트를 정리합니다.
cleanup_bigint_timezone_data_update_postgres.ps1
| | 인수 없이 이 스크립트를 실행하면 해당 사용 문이 인쇄됩니다. Usage: cleanup_bigint_timezone_data_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
| | 이 스크립트는 업그레이드 프로세스 중 생성된 임시 데이터베이스 객체에 대한 일부 정리 작업을 수행하지만 이전 단계에서 생성된 백업 테이블을 삭제하거나 이러한 백업 테이블 내의 데이터를 수정하지 않습니다. 이는 의도된 동작이며 데이터를 실수로 삭제할 수 없도록 합니다. 이러한 백업 테이블을 삭제하려면 수동으로 삭제해야 합니다. |
8. 모든 데이터 마이그레이션이 완료, 확인 및 검증된 후 기본 정리 스크립트를 실행합니다.
모든 BigInt/Timezone 데이터 마이그레이션이 완료, 확인 및 검증된 후 이 스크립트를 실행하여 기본 ThingWorx 업데이트 스크립트에서 생성된 임시 데이터베이스 아티팩트를 정리합니다.
cleanup_update_postgres.ps1
| | 인수 없이 이 스크립트를 실행하면 해당 사용 문이 인쇄됩니다. Usage: cleanup_update_postgres.ps1 -h <host> -p <port> -d <database> -s <schema> -u <user> [--managed_instance <name>] [-y] Supported Options: -h host The host name of the machine on which the database is running. -p port The port on which the database server is listening for connections. -d database The name of the database to connect to. -s schema The name of the database schema to update. -u user Connect to the database as this user. --managed_instance name To be specified only when the database is deployed within a Managed Instance (e.g. Azure, etc). -y Suppress all non-required prompts, such as "Are you sure?" |
• 설치 관리자를 9.0.x, 9.1.x, 9.2.x로 업그레이드
시간대가 설정되면 <설치 위치>/schema/update로 이동하고 운영 체제 및 데이터베이스 조합에 대한 적절한 스크립트(예: Windows의 경우 아래에 나열된 .bat 파일, RHEL 설치의 경우 .sh 파일)를 다음 순서대로 실행합니다.
a. thingworxPostgresDBSetupBigIntTimezoneDataUpdate.bat
b. thingworxPostgresModelTablesDataUpdate.bat
c. thingworxPostgresDataTableSchemaUpdate.bat
d. thingworxPostgresValueStreamSchemaUpdate.bat
e. thingworxPostgresStreamSchemaUpdate.bat
f. thingworxPostgresDataTableDataUpdate.bat
g. thingworxPostgresStreamDataUpdate.bat
h. thingworxPostgresValueStreamDataUpdate.bat
스크립트에는 다음과 같은 매개 변수가 사용됩니다.
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
이러한 매개 변수와 해당 예상 입력에 대한 자세한 내용은 수동 현재 위치 업그레이드: Windows 또는 수동 현재 위치 업그레이드: Linux를 참조하십시오.
-u 또는 -l 매개 변수로 전달되는 데이터베이스 사용자의 암호를 입력하라는 메시지가 표시됩니다.
| | StreamDataUpdate 및 ValueStreamDataUpdate 스크립트(예: thingworxPostgresStreamDataUpdate.bat 및 thingworxPostgresValueStreamDataUpdate.bat)는 비동기식으로 실행하도록 설계되었습니다. 이러한 스크립트는 중단된 위치를 선택한 후 일괄 작동하도록 설계되었으므로 사용자가 ThingWorx 인스턴스가 실행되는 동안 자신의 데이터를 마이그레이션할 수 있습니다. 이러한 스크립트는 데이터의 볼륨에 따라 실행하는 데 시간이 오래 걸릴 수 있습니다. |
실행 중 DataTableDataUpdate 스크립트(예: thingworxPostgresDataTableDataUpdate.bat)가 다음 메시지를 표시합니다. Essential System Data Has Been Migrated. It Is Now Safe To Restart Tomcat Server.
DataTableDataUpdate 스크립트가 이 메시지를 게시한 후에는 ThingWorx 인스턴스를 다시 시작하고 나머지 데이터 마이그레이션 스크립트를 계속 진행할 수 있습니다. 나머지 스크립트는 ThingWorx 실행 중에 실행할 수 있으며, 사용자의 스트림과 가치 스트림 데이터의 마이그레이션을 완료합니다.
마이그레이션이 완료되면 정리 스크립트(예: "thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh")를 실행하여 migration_log 테이블 및 마이그레이션 함수를 정리해야 합니다.
E.) 9.2 이상의 정리 스크립트 실행
ThingWorx 9.2.x 이상으로 업그레이드하는 경우 정리 스크립트를 실행하여 업그레이드 프로세스 동안 생성된 임시 테이블을 제거해야 합니다.
<installDir>/schema/update에 있는 thingworx<database_name>DBCleanupPermissionTempTableUpdate.bat(Windows) 또는 thingworx<database_name>DBCleanupPermissionTempTableUpdate.sh(Linux) 정리 스크립트를 실행합니다.
스크립트에는 다음과 같은 매개 변수가 사용됩니다.
-h <server>
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-p <port>
-d <thingworx database name>
-l <thingworx database username> for MSSQL
-u <thingworx database username> for PostgreSQL
-i <SQL server instance name> (optional, for MSSQL installations only)
-u 또는 -l 매개 변수로 전달되는 데이터베이스 사용자의 암호를 입력하라는 메시지가 표시됩니다.
F.) 9.3+에 대한 추가 선택적 정리
ThingWorx 9.2.x 이하에서 업그레이드하고 액세스 토큰 암호화를 사용하여 Single Sign-On을 활성화한 경우 선택적 정리 단계를 수행할 수 있습니다. 9.3 이전 릴리즈에서는 액세스 토큰을 데이터베이스에 지속하기 전에 암호화하는 데 KeyCzar 도구가 사용됩니다. KeyCzar를 사용하려면 ThingWorx 설치 디렉터리의 ThingworxPlatform\ssoSecurityConfig 폴더에 symmetric 폴더를 만들어야 합니다.
KeyCzar 도구는 이제 더 이상 사용되지 않습니다. ThingWorx 9.3 이상에서는 액세스 토큰을 암호화하는 데 Tink로 대체되었습니다. Tink에는 ThingWorx sso-settings.json 파일의 symmetric 폴더 또는 keyczarKeyFolderPath 매개 변수가 필요하지 않습니다. 이러한 파일과 설정은 그대로 두고 ThingWorx 9.3 이상에서는 무시해도 됩니다. 하지만 해당 파일과 설정을 제거하려면 업그레이드 절차가 완료될 때까지 기다려야 합니다.
G.) (선택 사항) PostgreSQL 13으로 업그레이드
ThingWorx 9.2.0 이상에서는 이전 PostgreSQL 버전에서 PostgreSQL 13으로 업그레이드하는 것이 선택 사항입니다.
1. 데이터베이스를 백업합니다. 이는 ThingWorx 업그레이드 후 데이터베이스를 백업하므로 두 번째로 수행하는 백업입니다.
2. PostgreSQL 13을 다운로드합니다.
3. PostgreSQL 설명서를 참조하여 PostgreSQL 13으로 업그레이드합니다.
H.) 문제 해결
• 다음 오류가 발생하여 업그레이드가 실패할 경우 아래 단계를 수행합니다. 이 오류는 사용자 정의 색인 값이 64자보다 크거나 같은 경우에 발생합니다.
Unable to Invoke Service Reindex on Data Table : com.microsoft.sqlserver.jdbc.SQLServerException: String or binary data would be truncated in table 'thingworx.thingworx.data_table_indexes', column 'mskey'. Truncated value: '<with_actual_field_Value_from_mskey_field>'.
a. thingworxMssqlSchemaUpdate<priorVersion>-to-<currentVersion>.bat/.sh 또는 SQL 스크립트를 실행합니다.
sqlcmd -S server\\serverinstance,port -U db_user -P password -d databaseName -i <schemaUpdateFile.sql>
이 스크립트를 실행하면 mskey 열 길이가 늘어나고 색인이 업데이트됩니다.
b. Tomcat을 시작합니다.
• 기존에 ThingWorx 8.5.3 이하 버전이 설치되어 있지만 설치 관리자가 찾지 못하는 경우 ThingWorx 업그레이드 준비 유틸리티를 실행합니다.
• 설치 관리자가 업그레이드를 완료할 수 없는 경우 다음을 수행하십시오.
1. /Installer/logs 아래 설치 디렉터리에 있는 로그 파일을 확인합니다.
2. 업그레이드 이전 설치로 되돌립니다.
a. 데이터베이스를 백업으로 복원합니다.
b. ThingWorx-Foundation 서비스를 시작합니다.
• 설치 관리자가 성공적으로 실행되면 ThingWorx Foundation이 업그레이드됩니다. 하지만 ThingWorx Foundation 설치 위치의 이름이 최신이 아닐 수 있습니다. > 아래의 Composer에서 ThingWorx 버전을 확인할 수 있습니다.
• 운영 체제가 RHEL 8.2이고 ThingWorx 8.5.7에서 업그레이드하는 경우, 먼저 Chef Infra Client를 수동으로 제거하여 설치 관리자가 지원되는 Chef 버전을 프로비져닝하고 사용할 수 있는지 확인해야 합니다. Chef를 제거하려면 다음을 수행하십시오.
a. Chef Infra Client 설치 관리자의 패키지 이름을 찾으려면 다음 명령을 실행합니다. $ rpm -qa chef
출력은 다음과 같습니다. chef-14.10.9-1.el7.x86_64.rpm.
b. 위의 출력에서 패키지 이름을 복사합니다.
c. 복사한 패키지 이름과 함께 다음 명령을 실행합니다. $ sudo yum remove <copied_package_name>
예: $ sudo yum remove chef-14.10.9-1.el7.x86_64.rpm
d. /opt 디렉터리로 이동하고 설치 디렉터리($ sudo rm -rf /opt/chef)를 삭제하여 Chef Infra Client 파일을 모두 제거합니다.