Mattermost 업그레이드 준비

plans-img 모든 플랜 에서 사용 가능

deployment-img self-hosted 배포판

대부분의 경우 몇 분 안에 Mattermost Server 업그레이드 를 할 수 있습니다. 그러나 업그레이드에는 설치 크기와 복잡성, 그리고 현재 버전에 따라 업그레이드 시간이 달라질 수 있습니다. 업그레이드를 계획할 때는 현재 데이터베이스와 운영 체제 버전이 여전히 지원되는지 확인하는 것이 좋습니다. 자세한 내용은 소프트웨어 및 하드웨어 요구 사항 문서 를 참조하세요.

업그레이드 최적의 방법

일반적으로 Mattermost는 잠금을 걸지 않고, 역호환 마이그레이션을 목표로 합니다. 이 역 호환성 보증은 일반적으로 마지막 ESR(Extended Support Release) 버전에만 적용됩니다. 예를 들어 ESR1, ESR2 및 ESR3 세 가지 ESR 버전이 있다면, ESR1에서 ESR2로, 그리고 ESR2에서 ESR3로 업그레이드하는 것이 역 호환성을 보장하지만, ESR1에서 ESR3으로 바로 업그레이드하는 것은 보장하지 않습니다.

지연된 업그레이드의 경우 가장 가까운 ESR 버전으로 먼저 업그레이드하는 것을 권장하며, 그런 다음 다음 ESR로 업그레이드하세요. 이전 버전과 바로 최신 버전으로 업그레이드하려고 하지 마세요. 그렇게 하면 업그레이드 중에 클러스터 내의 이전 노드의 역 호환성이 깨질 수 있습니다.

Mattermost v7.1로 업그레이드

Mattermost v7.1은 새로운 열과 해당 인덱스 형태의 스키마 변경을 도입했습니다. 이 스키마 변경에 대한 테스트 결과는 다음과 같습니다:

  • PostgreSQL 12M Posts, 2.5M Reactions - ~1분 18초 (인스턴스: db.r5.2xlarge)

업그레이드 전에 Reactions 테이블에서 잠금을 얻는 다음 SQL 쿼리를 실행할 수 있습니다. 이 기간 동안 게시된 사용자 반응은 마이그레이션이 완료될 때까지 데이터베이스에 반영되지 않습니다. 이것은 완전히 역 호환성이 유지됩니다.

만약 연결 협력 및 테이블 협력이 다르면 협력 혼합이 불법( Illegal mix of collations ) 오류가 발생할 수 있습니다. 이 오류를 해결하려면 연결과 테이블의 협력을 동일하게 설정하세요. 다른 수준에서 서로 다른 협력이 있을 수 있으며, 데이터베이스 관리자는 서로 다른 협력 수준을 다른 개체에 대해 설정할 수 있습니다.

ALTER TABLE reactions ADD COLUMN IF NOT EXISTS channelid varchar(26) NOT NULL DEFAULT '';

UPDATE reactions SET channelid = COALESCE((select channelid from posts where posts.id = reactions.postid), '') WHERE channelid='';

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_reactions_channel_id on reactions (channelid);

Mattermost v6.7로 업그레이드

Mattermost v6.7은 새로운 인덱스 형태의 스키마 변경을 도입했습니다. 다음은 스키마 변경에 대한 테스트 결과입니다:

  • PostgreSQL 7M Posts - ~9초 (인스턴스: db.r5.xlarge)

제로 다운타임 업그레이드를 원하는 경우, 업그레이드를 수행하기 전에 이 인덱스를 적용할 수 있습니다.

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_posts_create_at_id on posts(createat, id);

이것은 완전히 역 호환성을 유지하며, 테이블 잠금을 얻거나 테이블에 대한 기존 작업에 영향을 미치지 않습니다.

Mattermost v6.0으로 업그레이드

Mattermost Server v6.0 업그레이드는 데이터셋 크기에 따라 시작 시간이 길어질 수 있는 중요한 데이터베이스 스키마 변경을 실행합니다. v6.0의 경우 제로 다운타임은 불가능하지만, 마이그레이션 프로세스 중에 수고를 기울일 경우 꽤나 줄일 수 있습니다.

업그레이드 전에 쿼리를 실행하면 일부 다운타임을 줄일 수 있습니다. 그러나 일부 쿼리는 여전히 테이블 전체 잠금을 유발할 수 있으며 쿼리 기간에 Mattermost를 읽기 전용 모드로 설정해야 할 수도 있습니다.

다음을 강력히 추천합니다:

  • 마이그레이션 영향을 줄이기 위해 근무 시간 외에 유지 보수 창을 설정하세요.

  • 필요한 경우 이전 데이터베이스 스냅샷을 로드할 수 있도록 데이터베이스의 백업을 유지하세요.

  • Mattermost 인스턴스를 업그레이드하기 전에 최신 Extended Support Release (ESR) 로 업그레이드를 시도하기 전에 먼저 수행하세요.

Important

Mattermost Server v7.8의 지원은 2023년 11월 15일에 종료되었습니다. Mattermost Server v8.1 Extended Support Release 또는 그 이후 버전으로 업그레이드해야합니다. 이전 Extended Support Release에서 최신 Extended Support Release로의 업그레이드는 지원됩니다. v5.31에서 v5.37로의 업그레이드는 v5.31에서 v5.35로의 업그레이드와 v5.35에서 5.37으로의 업그레이드와 거의 동일한 시간이 걸릴 것으로 예상됩니다. 그러나 v5.31에서 v5.37으로 직접 업그레이드하려면 v5.35에서 필요한 데이터베이스 스키마 마이그레이션으로 인해 몇 시간이 걸릴 수도 있습니다. 업그레이드 영향을 확인하려면 중간 버전에 대한 중요한 업그레이드 노트 를 검토하여 업그레이드에 영향을 줄 가능성이 있는 마이그레이션을 인식하세요.

v6.0 데이터베이스 스키마 마이그레이션

Mattermost v6.0은 데이터베이스 및 애플리케이션 성능을 개선하기 위해 여러 데이터베이스 스키마 변경을 도입했습니다. 업그레이드는 1000만 개 이상의 게시물 및 7200만 개 이상의 게시물과 같은 현실적인 데이터셋을 사용하여 지원되는 PostgreSQL 데이터베이스 드라이버에서 철저한 테스트를 거쳤습니다.

마이그레이션 프로세스 중 실행되는 다음 쿼리는 데이터베이스 CPU 사용률 및 쿼리 기간 동안의 쓰기 작업 제약에 상당한 영향을 미칠 것입니다:

ALTER TABLE posts ALTER COLUMN props TYPE jsonb USING props::jsonb; (~ 11 분)

PostgreSQL 쿼리의 상세 내용 및 그들의 영향과 기간에 대한 자세한 내용은 Mattermost v6.0 DB 스키마 마이그레이션 분석 을 참조하세요.

v5.35보다 오래된 버전에서의 업그레이드

Mattermost v5.35보다 오래된 버전에서 업그레이드하는 고객은 v5.35에서 백엔드 데이터베이스 아키텍처가 도입되면서 v6.0으로 업그레이드할 때 연장된 다운타임이 예상됩니다. 이 업그레이드 경로는 대규모 설치에 권장되지 않습니다. Mattermost v6.0으로 업그레이드하기 전에 먼저 최신 Extended Support Release (ESR) 로 업그레이드하는 것을 권장합니다. 자세한 내용은 Mattermost 변경 로그 문서를 참조하세요.

만약 Mattermost v5.0 이전 버전에서 업그레이드하는 경우, v6.0으로 직접 업그레이드할 수 없습니다. 대신, 업그레이드를 단계적으로 진행하는 것을 강력히 권장하며, 먼저 최신 ESR로 업그레이드를 시작한 다음 v6.0으로 업그레이드하세요. 업데이트의 첫 단계에서는 또한 v5.0 릴리스에서 도입된 이진 변경사항과 함께 서비스 파일을 수정해야 합니다. 실행 디렉터리는 Mattermost 기본 디렉터리를 가리켜야하며(예: /opt/mattermost), 이진 파일은 mattermost 바이너리를 가리켜야합니다(예: /opt/mattermost/bin/mattermost).

중간 릴리스 버전 간의 모든 important-upgrade-notes 를 검토하여 업그레이드에 영향을 줄 수있는 가능한 마이그레이션에 대해 인식하십시오.

Note

v5.35 이전 버전에서 v6.0으로 업그레이드하는 고객은 권장하는 업그레이드 프로세스를 따를 경우 다음과 같은 오류가 발생 할 수 있습니다:

Failed to alter column type. It is likely you have invalid JSON values in the column. Please fix the values manually and run the migration again.","caller":"sqlstore/store.go:854","error":"pq: unsupported Unicode escape sequence

문제 해결을 돕기 위해, 업그레이드 중에 문제를 일으키는 테이블과 열을 좁히기 위해 SqlSettings.Trace 를 활성화 할 수 있습니다. 다음 쿼리는 PostgreSQL에서 열을 JSONB 형식으로 변경합니다. 이 쿼리를 v5.39 개발 데이터베이스에 실행하여 Unicode 문제가 발생하는 테이블 및 열을 찾을 수 있습니다:

ALTER TABLE posts ALTER COLUMN props TYPE jsonb USING props::jsonb;
ALTER TABLE channelmembers ALTER COLUMN notifyprops TYPE jsonb USING notifyprops::jsonb;
ALTER TABLE jobs ALTER COLUMN data TYPE jsonb USING data::jsonb;
ALTER TABLE linkmetadata ALTER COLUMN data TYPE jsonb USING data::jsonb;
ALTER TABLE sessions ALTER COLUMN props TYPE jsonb USING props::jsonb;
ALTER TABLE threads ALTER COLUMN participants TYPE jsonb USING participants::jsonb;
ALTER TABLE users ALTER COLUMN props TYPE jsonb USING props::jsonb;
ALTER TABLE users ALTER COLUMN notifyprops TYPE jsonb USING notifyprops::jsonb;
ALTER TABLE users ALTER COLUMN timezone TYPE jsonb USING timezone::jsonb;

영향 받는 테이블을 식별 한 후, 다음 SELECT 쿼리를 사용하여 u0000 가 얼마나 많이있는지 확인하고 수정합니다:

SELECT COUNT(*) FROM TableName WHERE ColumnName LIKE '%\u0000%';

그런 다음 해당 행을 선택하고 수정하십시오. 원하는 경우 다음 UPDATE 쿼리를 사용하여 테이블 또는 열의 모든 발생을 한 번에 수정 할 수 있습니다:

UPDATE TableName SET ColumnName = regexp_replace(ColumnName, '\\u0000', '', 'g') WHERE ColumnName LIKE '%\u0000%';

고가용성 배포 업그레이드

고가용성 환경에서는 데이터베이스 크기 및 설정에 따라 v6.0으로의 마이그레이션이 상당한 시간이 소요될 수 있으며, 마이그레이션이 완료 될 때까지 게시물 테이블을 잠길 수 있어 사용자가 게시하거나 메시지를 수신하지 못하도록 할 수 있습니다.

특정 버전에서 업그레이드하기 전에 필요한 조치 사항을 확인하기 위해 중요한 업그레이드 참고 사항 와 함께 고가용성 클러스터 업그레이드 가이드 를 검토하십시오.

Important

클러스터에서 Mattermost의 두 가지 다른 버전을 실행하는 것은 업그레이드 시나리오 이외에는 수행하지 않아야합니다. v6.0에서 클러스터링 코드에 기본적인 변경 사항으로 인해 다른 버전의 노드를 실행할 수 없으며, 중요한 업그레이드 참고 사항 제품 문서에 기재되어 있습니다.

또한, v6.0의 릴리스는 데이터베이스 스키마 변경을 소개하며 더 오랜 마이그레이션 시간이 예상됩니다.