9.0.x, 9.1.x 및 9.2.x로 수동 현재 위치 업그레이드: Linux

1. OS가 RHEL인 경우 ThingWorx 업그레이드를 수행하기 전에 지원되는 버전으로 업그레이드했는지 확인합니다. 자세한 내용은 시스템 요구사항을 참조하십시오.

ThingWorx 9.1은 RHEL 8.2에서만 지원됩니다.

2. 업그레이드를 시작하기 전에 다음을 수행하는 것이 좋습니다.

◦ 데이터베이스 덤프

◦ ThingworxStorage 및 ThingworxPlatform 폴더의 모든 데이터를 백업합니다.

◦ Tomcat_home 폴더를 백업합니다. 이 폴더에는 bin, conf, lib, temp, webapps 및 work 폴더가 있습니다.

3. ThingWorx Platform과 함께 ThingWorx Apps를 사용하는 경우 다음을 수행합니다.

a. 업그레이드하려는 ThingWorx 버전이 ThingWorx Apps 버전에서 지원되는지 확인합니다. ThingWorx Apps 업그레이드 지원 매트릭스를 참조하십시오.

b. 플랫폼을 업그레이드하기 전에 수행해야 하는 단계가 있습니다. 다음 단계로 진행하기 전에 ThingWorx Apps 업그레이드를 참조하십시오.

4. Navigate도 설치되어 있는 경우 ThingWorx Navigate Compatibility Matrix(ThingWorx Navigate 호환성 매트릭스)에서 호환성을 확인합니다.

5. PTC 소프트웨어 다운로드에서 최신 버전의 ThingWorx를 구합니다.

현재 사용자에게 쓰기 권한이 있는 폴더에서 ThingWorx 콘텐츠를 다운로드하고 추출합니다. 업데이트 스크립트가 프로세스의 일부 파일을 생성하기 때문에 쓰기 권한이 필요합니다.

6. 필수 버전의 Tomcat 및 Java을 실행하고 있는지 확인합니다. 버전 요구사항은 시스템 요구사항을 참조하십시오.

Java 버전을 업그레이드해야 하는 경우 Java를 업그레이드하기 전에 ThingWorx 업그레이드를 수행합니다.

7. MSSQL, Azure SQL 또는 H2를 업그레이드하는 경우 데이터 테이블에 사용자 정의 색인 필드 값이 누락되면 업그레이드가 실패합니다. 업그레이드 프로세스를 시작하기 전에 모든 사용자 정의 색인 필드에 값이 있는지 확인합니다.

그렇게 하지 않으면 업그레이드가 실패하고 이전 버전을 다시 배포해야 하며(스키마 업데이트가 수행된 경우 데이터베이스를 롤백/복원해야 함) 누락된 색인 값을 추가하거나 데이터 테이블에서 사용자 정의 색인을 제거한 다음 업그레이드를 수행해야 합니다.

8. 다음을 Apache Tomcat Java Options에 추가합니다.

-Dlog4j2.formatMsgNoLookups=true

이 단원의 단계는 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 1.7.x/MS SQL/PostgreSQL에서 데이터 내보내기:

a. ThingWorx에 관리자로 로그인합니다.

b. 가져오기/내보내기 > 내보내기를 클릭합니다.

c. 다음 옵션을 사용합니다.

▪ 내보내기 옵션에서 파일로를 선택합니다.

▪ 내보내기 유형에서 데이터 컬렉션을 선택합니다.

▪ 컬렉션에서 스트림을 선택합니다.

▪ 내보내기를 클릭합니다.

d. 가치 스트림 데이터에 대해 a~c단계를 반복합니다.

e. 생성된 스트림 및 가치 스트림 데이터에 대해 내보낸 폴더를 백업을 위해 시스템 저장소에서 안전한 위치로 이동합니다.

1. Tomcat을 중지합니다.

2. 계속하기 전에 다음 두 폴더를 백업하는 것이 좋습니다.

◦ Apache Software Foundation/Tomcat x.x/webapps/Thingworx

◦ ThingworxStorage

3. 현재 Tomcat 버전이 이전 버전이고 대상 ThingWorx 버전에서 지원되지 않는 경우 지원되는 Tomcat 버전으로 업데이트합니다.

4. 기존 설치의 SSO 구성을 유지하려면 <Tomcat 설치 디렉토리>\webapps\Thingworx\WEB-INF 폴더에서 web.xml 파일을 백업합니다.

5. /ThingworxStorage/esapi 디렉터리에서 validation.properties 파일을 백업하고 삭제합니다.

ThingWorx를 시작할 때 validation.properties 파일이 작성됩니다. 수행한 변경 사항을 유지하려면 파일을 ThingworxStorage 디렉터리 외부에 저장한 다음 계속해서 esapi 디렉터리를 제거합니다. ThingWorx를 시작할 때 파일이 재작성되며 자동으로 생성된 validation.properties 파일에 사용자 정의 regex를 다시 추가할 수 있습니다.

자세한 내용은 이 항목을 참조하십시오.

6. /Apache Software Foundation/Tomcat x.x/webapps에 있는 Tomcat 설치로 이동하여 Thingworx.war 파일 및 Thingworx 폴더를 삭제합니다.

H2에 대해 업그레이드하는 경우 이 단계를 건너뜁니다. 다른 모든 데이터베이스의 경우 Tomcat Java 옵션에 다음 매개 변수를 추가하여 ThingWorx 서버 시간대를 설정합니다.

-Duser.timezone=UTC

이 단원의 1단계만 모든 업그레이드에 필요합니다.

ThingWorx 8.4.x 또는 8.5.x --> 9.0.x, 9.1.x 또는 9.2.x에서 업그레이드하는 경우 이 단원의 나머지 부분에 나오는 단계를 수행합니다.

ThingWorx 9.0.x 또는 9.1.x --> 9.1.x 또는 9.2.x에서 업그레이드 하는 경우 이 단원의 나머지 단계를 건너뜁니다.

1. ThingWorx 소프트웨어 다운로드의 update 폴더에 있는 다음 스크립트를 실행합니다(업그레이드할 버전부터 시작).

thingworxPostgresSchemaUpdate8.4-to-8.5.sh

thingworxPostgresSchemaUpdate8.5-to-9.0.sh

thingworxPostgresSchemaUpdate9.1-to-9.2.sh

9.1에는 스키마 업데이트가 없으므로 thingworxPostgresSchemaUpdate9.0-to-9.1.sh 스크립트를 실행할 필요가 없습니다. 완결성을 위해 이 스크립트가 update 폴더에 포함되어 있지만 이 스크립트는 비어 있으며 자동 업그레이드 프로세스를 사용하는 사용자만을 위한 것입니다.

이 단원의 나머지 단계는 ThingWorx 8.4.x 또는 8.5.x에서 9.0.x, 9.1.x 또는 9.2.x로 업그레이드하는 경우에만 수행해야 합니다. ThingWorx 9.0.x에서 9.1.x 또는 9.2.x로 업그레이드 하는 경우 이 단원의 나머지 단계를 건너뜁니다.

2. big integer/시간대 설정 스크립트를 실행하여 마이그레이션을 수행할 수 있도록 데이터베이스를 준비합니다.

이미 UTC에서 ThingWorx를 실행 중인 경우에도 big integer 변경을 위해 마이그레이션을 실행해야 하지만 sourceTZ 및 targetTZ 매개 변수(아래 단계에 나오는 일부 스크립트에서 사용 가능)에 모두 UTC 값을 제공할 수 있습니다.

thingworxPostgresDBSetupBigIntTimezoneDataUpdate.sh

3. 지원되는 모든 시간대를 찾으려면 다음 명령을 사용합니다.

select pg_timezone_names()

아래의 데이터 마이그레이션 스크립트에 대해 시간대를 지정할 때 지정된 시간대 이름은 pg_timezone_names() 스크립트로 표시되는 공식 이름 중 하나와 정확히 일치해야 합니다.

4. 모델 마이그레이션 스크립트를 실행하여 모든 모델 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxPostgresModelTablesDataUpdate.sh

사용법:

thingworxPostgresModelTablesDataUpdate.sh [-h <server>] [-p <port>] [-d <Thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>]

예:

thingworxPostgresModelTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

5. 다음의 각 스키마 마이그레이션 스크립트를 실행하여 모든 데이터 테이블, 스트림 및 가치 스트림 데이터의 백업 테이블을 만듭니다.

성능 상의 이유로 이러한 스크립트는 테이블에 원래 데이터의 복사본을 만들지 않습니다. 대신 기존 테이블의 이름을 "<원래 테이블 이름>"에서 "<원래 테이블 이름>_backup"으로 바꿉니다. 이를 통해 데이터를 실제로 복사하는 긴 시간이 걸리는 프로세스가 사라집니다. 기존 테이블의 이름이 바뀌고 백업 테이블이 되면 원래 이름을 사용하여 새 테이블이 작성됩니다. 새 테이블은 비어 있으며 원래 테이블과 이름이 같기 때문에 원래 테이블과 동일한 용도로 사용됩니다. 새 테이블은 이후 단계에서 마이그레이션된 데이터로 채워집니다.

thingworxPostgresDataTableSchemaUpdate.sh

thingworxPostgresStreamSchemaUpdate.sh

thingworxPostgresValueStreamSchemaUpdate.sh

6. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블 내의 데이터 테이블 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxPostgresDataTableDataUpdate.sh

사용법:

thingworxPostgresDataTableDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

예:

thingworxPostgresDataTablesDataUpdate.sh -sourceTZ US/Eastern -targetTZ Etc/UTC

이 마이그레이션 스크립트가 시작되면 Tomcat을 다시 시작해도 안전하다는 메시지가 콘솔에 표시될 때까지 기다립니다. 이 메시지가 표시되면 마이그레이션 스크립트의 실행이 아직 완료되지 않았어도 다음 단계를 진행해도 안전하다는 의미입니다.

7. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블의 스트림 및 가치 스트림 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxPostgresStreamDataUpdate.sh

thingworxPostgresValueStreamDataUpdate.sh

사용법:

thingworxPostgresStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

thingworxPostgresValueStreamDataUpdate.sh [-h <server>] [-p <port>] [-d <thingworx database name>] [-u <thingworx database username>] [-r <password>] [-m <azure managed instance name>] [-sourceTZ <source timezone>] [-targetTZ <target timezone>] [-chunkSize <chunk size>]

예:

thingworxPostgresStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

thingworxPostgresValueStreamDataUpdate.sh -sourceTz US/Eastern -targetTZ Etc/UTC -chunkSize 5000

이 두 마이그레이션 스크립트가 시작되면 마이그레이션 스크립트 및 데이터 테이블 마이그레이션 스크립트(이전 버전에서 시작됨)가 성공적으로 완료될 때까지 다음 단계를 진행하지 마십시오.

8. thingworxPostgresDataTableDataUpdate.sh, thingworxPostgresStreamDataUpdate.sh 및 thingworxPostgresValueStreamDataUpdate.sh 스크립트가 모두 성공적으로 완료되었는지 수동으로 확인합니다. 모든 데이터 테이블, 스트림 및 가치 스트림 데이터가 성공적으로 마이그레이션되었는지 확인합니다.

9. 정리 스크립트를 실행하여 마이그레이션하는 동안 필요한 모든 임시 데이터베이스 객체를 제거합니다.

이 스크립트는 업그레이드 프로세스 중 생성된 임시 데이터베이스 객체에 대한 정리를 수행하지만 이전 단계에서 작성된 백업 테이블을 삭제하거나 백업 테이블의 데이터를 수정하지 *않습니다*. 이는 의도된 동작이며 데이터를 실수로 삭제할 수 없도록 합니다. 백업 테이블을 삭제하려면 수동으로 삭제해야 합니다.

thingworxPostgresDBCleanupBigIntTimezoneDataUpdate.sh

스크립트 문제 해결

ThingWorx 데이터베이스에 대해 다음 명령을 실행해야 합니다.

• 오류 코드 23505는 삽입 시 중복 키 고유 제약 조건 위반이 발생했을 의미합니다. 이 문제를 해결하려면 다음을 수행하십시오.

a. 다음 명령을 실행합니다.

Select * from migration_log where status = -1 OR status = 0.

b. 반환된 행의 fromId 및 toId 범위를 기록합니다.

c. 마이그레이션 로그에서 기록된 entry_ids 에 대한 데이터 테이블을 질의합니다.

d. 레코드가 모두 있는 경우 해당 범위에 대해 0 또는 -1을 1로 변경합니다. 레코드가 범위에서 부분적으로 누락된 경우 더 작은 청크 크기를 시도하거나 이미 테이블로 마이그레이션된 레코드를 삭제하고 마이그레이션을 다시 시도하십시오.

• 지원되는 모든 시간대를 찾으려면

select pg_timezone_names()

명령을 사용합니다. PostgreSQL이 자동으로 오프셋을 확인하여 지정된 타임스탬프에 따라 날짜를 이동하려면 먼저 나열된 공식 이름을 사용해야 합니다.

• 모든 entry_ids가 마이그레이션되었는지 확인하려면 다음과 유사한 SQL 질의를 사용합니다.

SELECT entry_id FROM data_table_backup EXCEPT SELECT entry_id FROM data_table

SELECT entry_id FROM data_table EXCEPT SELECT entry_id FROM data_table_backup

• PGPASSWORD 환경 변수가 시스템에서 사용되고 있는 경우 해당 변수를 -r 매개 변수로 전달하여 스크립트가 실행되어야 하는 암호를 설정해야 합니다.

이 단원의 1단계만 모든 업그레이드에 필요합니다.

ThingWorx 8.4.x 또는 8.5.x --> 9.0.x, 9.1.x 또는 9.2.x에서 업그레이드하는 경우 이 단원의 나머지 부분에 나오는 단계를 수행합니다.

ThingWorx 9.0.x 또는 9.1.x --> 9.1.x 또는 9.2.x에서 업그레이드 하는 경우 이 단원의 나머지 단계를 건너뜁니다.

1. ThingWorx 소프트웨어 다운로드에 있는 전체 update 폴더를 MS SQL 서버에 복사하고 update 폴더에 있는 다음 스크립트를 실행합니다(업그레이드할 버전부터 시작).

thingworxMssqlSchemaUpdate8.4-to-8.5.sh

thingworxMssqlSchemaUpdate8.5-to-9.0.sh

thingworxMssqlSchemaUpdate9.1-to-9.2.sh

9.1에는 스키마 변경 사항이 없으므로 thingworxMssqlSchemaUpdate9.0-to-9.1.sh 스크립트를 실행할 필요가 없습니다. 완결성을 위해 이 스크립트가 update 폴더에 포함되어 있지만 이 스크립트는 비어 있으며 자동 업그레이드 프로세스를 사용하는 사용자만을 위한 것입니다.

이 단원의 나머지 단계는 ThingWorx 8.4.x 또는 8.5.x에서 9.0.x, 9.1.x 또는 9.2.x로 업그레이드하는 경우에만 수행해야 합니다. ThingWorx 9.0.x에서 9.1.x 또는 9.2.x로 업그레이드 하는 경우 이 단원의 나머지 단계를 건너뜁니다.

2. big integer/시간대 설정 스크립트를 실행하여 마이그레이션을 수행할 수 있도록 데이터베이스를 준비합니다.

이미 UTC에서 ThingWorx를 실행 중인 경우에도 big integer 변경을 위해 마이그레이션을 실행해야 하지만 sourceTZ 및 targetTZ 매개 변수(아래 단계에 나오는 일부 스크립트에서 사용 가능)에 모두 UTC 값을 제공할 수 있습니다.

thingworxMssqlDBSetupBigIntTimezoneDataUpdate.sh

3. 모델 마이그레이션 스크립트를 실행하여 모든 모델 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxMssqlModelTablesDataUpdate.sh

사용법:

thingworxMssqlModelTablesDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>]

예:

thingworxMssqlModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC

4. 다음의 각 스키마 마이그레이션 스크립트를 실행하여 모든 데이터 테이블, 스트림 및 가치 스트림 데이터의 백업 테이블을 만듭니다.

성능 상의 이유로 이러한 스크립트는 테이블에 원래 데이터의 복사본을 만들지 않습니다. 대신 기존 테이블의 이름을 "<원래 테이블 이름>"에서 "<원래 테이블 이름>_backup"으로 바꿉니다. 이를 통해 데이터를 실제로 복사하는 긴 시간이 걸리는 프로세스가 사라집니다. 기존 테이블의 이름이 바뀌고 백업 테이블이 되면 원래 이름을 사용하여 새 테이블이 작성됩니다. 새 테이블은 비어 있으며 원래 테이블과 이름이 같기 때문에 원래 테이블과 동일한 용도로 사용됩니다. 새 테이블은 이후 단계에서 마이그레이션된 데이터로 채워집니다.

thingworxMssqlDataTableSchemaUpdate.sh

thingworxMssqlStreamSchemaUpdate.sh

thingworxMssqlValueStreamSchemaUpdate.sh

5. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블 내의 데이터 테이블 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxMssqlDataTableDataUpdate.sh

사용법:

thingworxMssqlDataTableDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

예:

thingworxMssqlDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

이 마이그레이션 스크립트가 시작되면 Tomcat을 다시 시작해도 안전하다는 메시지가 콘솔에 표시될 때까지 기다립니다. 이 메시지가 표시되면 마이그레이션 스크립트의 실행이 아직 완료되지 않았어도 다음 단계를 진행해도 안전하다는 의미입니다.

6. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블의 스트림 및 가치 스트림 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxMssqlStreamDataUpdate.sh

thingworxMssqlValueStreamDataUpdate.sh

사용법:

thingworxMssqlStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

thingworxMssqlValueStreamDataUpdate.sh [-h <server>] [-i <server-instance>] [-p <port>] [-r <password>] [-l <login-name>] [-d <thingworx-database-name>] [-sourceTZ <source-timezone>] [-targetTZ <target-timezone>] [-chunkSize <chunk-size>]

예:

thingworxMssqlStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxMssqlValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

이 두 마이그레이션 스크립트가 시작되면 마이그레이션 스크립트 및 데이터 테이블 마이그레이션 스크립트(이전 버전에서 시작됨)가 성공적으로 완료될 때까지 다음 단계를 진행하지 마십시오.

7. thingworxMssqlDataTableDataUpdate.sh, thingworxMssqlStreamDataUpdate.sh 및 thingworxMssqlValueStreamDataUpdate.sh 스크립트가 모두 성공적으로 완료되었는지 수동으로 확인하고 모든 데이터 테이블, 스트림 및 가치 스트림 데이터가 성공적으로 마이그레이션되었는지 확인합니다.

8. 정리 스크립트를 실행하여 마이그레이션하는 동안 필요한 모든 임시 데이터베이스 객체를 제거합니다.

이 스크립트는 업그레이드 프로세스 중 생성된 임시 데이터베이스 객체에 대한 정리를 수행하지만 이전 단계에서 작성된 백업 테이블을 삭제하거나 백업 테이블의 데이터를 수정하지 *않습니다*. 이는 의도된 동작이며 데이터를 실수로 삭제할 수 없도록 합니다. 백업 테이블을 삭제하려면 수동으로 삭제해야 합니다.

thingworxMssqlDBCleanupBigIntTimezoneDataUpdate.sh

스크립트 문제 해결

• 지원되는 모든 시간대를 찾으려면 다음 명령을 사용합니다.

select * from sys.time_zone_info

• 모든 entry_ids가 마이그레이션되었는지 확인하려면 다음과 유사한 SQL 질의를 사용합니다.

select dt.entry_id, dtb.entry_id from [thingworx].[twschema].[data_table_backup] dtb full join [thingworx].[twschema].[data_table] dt on dtb.entry_id = dt.entry_id where dtb.entry_id is null or dt.entry_id is null

이 단원의 1단계만 모든 업그레이드에 필요합니다.

ThingWorx 8.4.x 또는 8.5.x --> 9.0.x, 9.1.x 또는 9.2.x에서 업그레이드하는 경우 이 단원의 나머지 부분에 나오는 단계를 수행합니다.

ThingWorx 9.0.x 또는 9.1.x --> 9.1.x 또는 9.2.x에서 업그레이드 하는 경우 이 단원의 나머지 단계를 건너뜁니다.

1. ThingWorx 소프트웨어 다운로드의 update 폴더에 있는 다음 스크립트를 실행합니다(업그레이드할 버전부터 시작).

플랫폼에 존재하는 권한 수는 업그레이드 완료 시간에 영향을 줄 수 있습니다. 권한이 많을수록 업그레이드 완료 시간이 늘어날 수 있습니다.

thingworxAzureSchemaUpdate8.4-to-8.5.sh

thingworxAzureSchemaUpdate8.5-to-9.0.sh

thingworxAzureSchemaUpdate9.1-to-9.2.sh

9.1에는 스키마 업데이트가 없으므로 thingworxAzureSchemaUpdate9.0-to-9.1.sh 스크립트를 실행할 필요가 없습니다. 완결성을 위해 이 스크립트가 update 폴더에 포함되어 있지만 이 스크립트는 비어 있으며 자동 업그레이드 프로세스를 사용하는 사용자만을 위한 것입니다.

사용법:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d ^database^ -h ^server^ -l ^username^ [-i ^serverInstance^] [-p ^port^] [-o ^option^]

예:

./thingworxAzureSchemaUpdate8.4-to-8.5.sh -d thingworx -h test.sqldatabase.net -l sqlAdmin

2. big integer/시간대 설정 스크립트를 실행하여 마이그레이션을 수행할 수 있도록 데이터베이스를 준비합니다.

이미 UTC에서 ThingWorx를 실행 중인 경우에도 big integer 변경을 위해 마이그레이션을 실행해야 하지만 sourceTZ 및 targetTZ 매개 변수(아래 단계에 나오는 일부 스크립트에서 사용 가능)에 모두 UTC 값을 제공할 수 있습니다.

thingworxAzureDBSetupBigIntTimezoneDataUpdate.sh

3. 모델 마이그레이션 스크립트를 실행하여 모든 모델 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxAzureModelTablesDataUpdate.sh

사용법:

thingworxAzureModelTablesDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

예:

thingworxAzureModelTablesDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

4. 다음의 각 스키마 마이그레이션 스크립트를 실행하여 모든 데이터 테이블, 스트림 및 가치 스트림 데이터의 백업 테이블을 만듭니다.

성능 상의 이유로 이러한 스크립트는 테이블에 원래 데이터의 복사본을 만들지 않습니다. 대신 기존 테이블의 이름을 "<원래 테이블 이름>"에서 "<원래 테이블 이름>_backup"으로 바꿉니다. 이를 통해 데이터를 실제로 복사하는 긴 시간이 걸리는 프로세스가 사라집니다. 기존 테이블의 이름이 바뀌고 백업 테이블이 되면 원래 이름을 사용하여 새 테이블이 작성됩니다. 새 테이블은 비어 있으며 원래 테이블과 이름이 같기 때문에 원래 테이블과 동일한 용도로 사용됩니다. 새 테이블은 이후 단계에서 마이그레이션된 데이터로 채워집니다.

데이터 테이블 스크립트를 실행하면 다음과 같은 예상 경고가 표시됩니다. Warning! The maximum key length for a clustered index is 900 bytes. The index 'data_table_indexes_pkey' has maximum length of 902 bytes. For some combination of large values, the insert/update operation will fail.

thingworxAzureDataTableSchemaUpdate.sh

thingworxAzureStreamSchemaUpdate.sh

thingworxAzureValueStreamSchemaUpdate.sh

5. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블 내의 데이터 테이블 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxAzureDataTableDataUpdate.sh

사용법:

thingworxAzureDataTableDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

예:

thingworxAzureDataTableDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

이 마이그레이션 스크립트가 시작되면 Tomcat을 다시 시작해도 안전하다는 메시지가 콘솔에 표시될 때까지 기다립니다. 이 메시지가 표시되면 마이그레이션 스크립트의 실행이 아직 완료되지 않았어도 다음 단계를 진행해도 안전하다는 의미입니다.

6. 새 명령 프롬프트 창을 열고 다음 데이터 마이그레이션 스크립트를 실행하여 백업 테이블의 스트림 및 가치 스트림 데이터를 마이그레이션합니다.

스크립트를 실행하기 전에 해당 스크립트를 텍스트 편집기에서 열어 해당 기본 환경 값(예: 서버, 포트, 시간대 등)이 올바르며 사용자의 환경에 적합한지 확인합니다. 스크립트 내에 정의된 기본값이 사용자 환경에 적절하지 않은 것으로 보이는 경우 하나 이상의 명령줄 인수를 지정하여 스크립트를 실행할 때 기본값을 무시합니다.

thingworxAzureStreamDataUpdate.sh

thingworxAzureValueStreamDataUpdate.sh

사용법:

thingworxAzureStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

thingworxAzureValueStreamDataUpdate.sh [-d database] [-h server] [-l loginname] [-i serverinstance] [-r password] [-p port] [-sourceTZ source-timezone] [-targetTZ target-timezone] [-chunkSize chunk-size]

예:

thingworxAzureStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

thingworxAzureValueStreamDataUpdate.sh -sourceTZ "Eastern Standard Time" -targetTZ UTC -chunkSize 5000

이 두 마이그레이션 스크립트가 시작되면 마이그레이션 스크립트 및 데이터 테이블 마이그레이션 스크립트(이전 버전에서 시작됨)가 성공적으로 완료될 때까지 다음 단계를 진행하지 마십시오.

7. thingworxAzureDataTableDataUpdate.sh, thingworxAzureStreamDataUpdate.sh 및 thingworxAzureValueStreamDataUpdate.sh 스크립트가 모두 성공적으로 완료되었는지 수동으로 확인합니다. 모든 데이터 테이블, 스트림 및 가치 스트림 데이터가 성공적으로 마이그레이션되었는지 확인합니다.

8. 정리 스크립트를 실행하여 마이그레이션하는 동안 필요한 모든 임시 데이터베이스 객체를 제거합니다.

이 스크립트는 업그레이드 프로세스 중 생성된 임시 데이터베이스 객체에 대한 정리를 수행하지만 이전 단계에서 작성된 백업 테이블을 삭제하거나 백업 테이블의 데이터를 수정하지 *않습니다*. 이는 의도된 동작이며 데이터를 실수로 삭제할 수 없도록 합니다. 백업 테이블을 삭제하려면 수동으로 삭제해야 합니다.

thingworxAzureDBCleanupBigIntTimezoneDataUpdate.sh

Java 11은 ThingWorx 9.2.0 이상에 필요합니다. 자세한 내용은 시스템 요구사항을 참조하십시오.

1. Java 11로 업그레이드하는 경우 다음 단계를 수행해야 합니다. Java 11이 이미 설치된 경우에는 이 단원을 건너뜁니다.

a. OpenJDK 또는 Java 11을 다운로드합니다.

b. Linux에 jEnv를 설치합니다.

i. jEnv 저장소를 Git 복제합니다.

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. 다음 명령을 실행합니다. 그러면 현재 활성화된 Java 환경에 따라 JAVA_HOME 변수가 jEnv에 의해 자동 설정됩니다.

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. jenv에 사용 가능한 모든 Java 버전을 확인합니다.

jenv versions

iii. 글로벌 Java 환경을 설정합니다.

jenv global <version>

iv. 셸 관련 Java 환경을 설정합니다.

jenv shell <version>

v. jenv에 의해 설정된 현재 버전을 확인합니다.

jenv versions

vi. Tomcat Java 설정에서 경로를 업데이트합니다.

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>
},

3. ThingWorx에서 H2를 데이터베이스로 사용하는 경우 platform-settings.json 파일에 사용자 이름 및 암호를 추가해야 합니다.

},
"PersistenceProviderPackageConfigs":{
"H2PersistenceProviderPackage":{
"ConnectionInformation":
{
"password": "<changeme>",
"username": "twadmin"
}
},

4. Tomcat을 시작합니다.

5. SSO 구성을 복원하려면 다음을 수행합니다.

a. 백업 web.xml 파일에서 SSOSecurityContextFilter 블록을 복사합니다.

b. 새로 생성된 web.xml 파일에서 마지막 AuthenticationFilter 블록 뒤에 SSOSecurityContextFilter 블록을 붙여넣습니다.

6. ThingWorx를 시작하려면 웹 브라우저에서 <서버 이름>\Thingworx로 이동합니다. 다음 로그인 정보를 사용합니다.

◦ 로그인 이름: 관리자

◦ 암호: <소스 서버 관리자 암호>

이 단원의 단계는 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 1.8.x에 대한 새 지속성 공급자를 생성하거나 기존 1.7.x 지속성 공급자에 새 연결 정보를 제공합니다.

2. 스트림 및 가치 스트림 데이터를 서버로 가져옵니다. 스트림 및 가치 스트림 데이터에 대해 아래 단계를 수행합니다.

a. ThingWorx 9.x에 관리자로 로그인합니다.

b. 가져오기/내보내기 > 가져오기를 클릭합니다.

c. 다음 옵션을 사용합니다.

i. 가져오기 옵션에서 파일에서를 선택합니다.

ii. 가져오기 유형에서 데이터를 선택합니다.

iii. 가져오기 소스에서 파일 저장소를 선택합니다.

iv. 파일 저장소에서 시스템을 선택합니다.

v. 경로에서 올바른 시스템 저장소 경로를 제공합니다.

• 통합 커넥터를 사용하는 경우 Integration Runtime의 최신 버전을 얻고 설치해야 합니다. 자세한 내용은 통합 커넥터에 대한 Integration Runtime Service의 초기 설정을 참조하십시오.

• MSSQL JDBC 드라이버를 업그레이드하는 경우 시스템 요구사항을 확인하고 MSSQL용 ThingWorx 구성을 참조하여 적절한 드라이버를 찾습니다.

• 8.x에서 9.x로 업그레이드하고 Java 확장이 있는 경우 Java 확장 8.x에서 9.x로 마이그레이션을 참조하십시오.

• ThingWorx Analytics를 솔루션의 일부로 사용하는 경우 두 설치 관리자에서 구성 요소 업그레이드를 처리할 수 있습니다.

◦ Analytics Server - Analytics Server 및 Analytics Extension 설치 또는 업그레이드

◦ Platform Analytics - Descriptive Analytics 및 Property Transform 설치 또는 업그레이드

업그레이드 절차에 대한 자세한 내용은 ThingWorx Analytics 업그레이드, 수정, 복원을 참조하십시오.

ThingWorx 9.2.x 이상으로 업그레이드하는 경우 정리 스크립트를 실행하여 업그레이드 프로세스 동안 생성된 임시 테이블을 제거해야 합니다.

<installDir>/schema/update에 있는 thingworx<database_name>DBCleanupPermissionTempTableUpdate.sh 정리 스크립트를 실행합니다.

스크립트에는 다음과 같은 매개 변수가 사용됩니다.

-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)

-u 또는 -l 매개 변수로 전달되는 데이터베이스 사용자의 암호를 입력하라는 메시지가 표시됩니다.

• 사용자 정의 색인 필드의 값이 누락되어 업그레이드에 실패한 경우 이전 버전을 다시 배포하고(스키마 업데이트가 수행된 경우 데이터베이스를 롤백/복원해야 함) 누락된 색인 값을 추가하거나 사용자 정의 색인을 데이터 테이블에서 제거한 후 업그레이드를 수행해야 합니다.

ThingWorx Platform을 시작한 후 플랫폼의 응용 프로그램 로그를 확인합니다. 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.