Mattermost 업그레이드 준비#

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

deployment-img self-hosted 배포

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

업그레이드 모범 사례#

Mattermost는 일반적으로 잠금이 없는 하위 호환 마이그레이션을 목표로 합니다. 이 하위 호환성 보장은 마지막 ESR 버전까지만 적용됩니다. 예를 들어, ESR1, ESR2, ESR3의 세 가지 ESR 버전이 있는 경우, ESR1에서 ESR2로, 그 다음 ESR2에서 ESR3로 업그레이드하면 하위 호환성이 보장되지만, ESR1에서 ESR3로 직접 업그레이드하는 것은 보장되지 않습니다.

업그레이드가 지연된 경우, 먼저 가장 가까운 ESR 버전으로 업그레이드한 다음 그곳에서 다음 ESR로 업그레이드하는 것을 권장합니다. 클러스터의 이전 노드의 하위 호환성이 업그레이드 중에 깨질 수 있으므로 최신 버전으로 직접 업그레이드하려고 하지 마세요.

Mattermost v7.1로 업그레이드#

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

  • PostgreSQL 12M 게시물, 2.5M 반응 - ~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은 새로운 인덱스 형태의 스키마 변경을 도입합니다. 스키마 변경에 대한 테스트 결과는 다음과 같습니다:

  • Postgres 7M 게시물 - ~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 v6.0 업그레이드를 실행하기 전에 먼저 Mattermost 인스턴스를 최신 Extended Support Release (ESR) 로 업그레이드하세요.

중요

Mattermost Server v9.11 Extended Support Release 의 지원은 2025년 5월 15일에 수명 주기가 종료됩니다. Mattermost Server v10.5 Extended Support Release 이상으로 업그레이드하는 것이 권장됩니다. 이전 Extended Support Release에서 최신 Extended Support Release로의 업그레이드가 지원됩니다. 업그레이드에 영향을 줄 수 있는 가능한 마이그레이션을 인지할 수 있도록 중간 버전에 대한 중요 업그레이드 참고사항 를 검토하세요.

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

Mattermost v6.0은 데이터베이스와 애플리케이션 성능을 모두 개선하기 위해 여러 데이터베이스 스키마 변경을 도입합니다. 업그레이드는 데이터 세트 크기에 따라 시작 시간이 길어질 수 있는 중요한 데이터베이스 스키마 변경을 실행합니다. 지원되는 PostgreSQL 데이터베이스 드라이버에 대해 1,000만 개 이상의 게시물과 7,200만 개 이상의 게시물이 있는 실제 데이터 세트를 사용하여 광범위한 테스트를 수행했습니다.

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

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

PostgreSQL 쿼리의 전체 분석과 영향 및 지속 시간은 Mattermost v6.0 DB schema migrations analysis 를 참조하세요.

v5.35보다 이전 릴리스에서 업그레이드#

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

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

업그레이드에 영향을 줄 수 있는 가능한 마이그레이션을 인지할 수 있도록 중간 릴리스 버전에 대한 중요 업그레이드 참고사항 를 검토하세요.

참고

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

열 유형을 변경하지 못했습니다. 열에 잘못된 JSON 값이 있을 가능성이 높습니다. 값을 수동으로 수정하고 마이그레이션을 다시 실행하세요.","caller":"sqlstore/store.go:854","error":"pq: unsupported Unicode escape sequence

문제 해결을 돕기 위해 SqlSettings.Trace 를 활성화하여 업그레이드 중에 어떤 테이블과 열이 문제를 일으키는지 파악할 수 있습니다. 다음 쿼리는 PostgreSQL에서 열을 JSONB 형식으로 변경합니다. v5.39 개발 데이터베이스에서 이 쿼리를 실행하여 어떤 테이블과 열에 유니코드 문제가 있는지 확인하세요:

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으로 업그레이드하기 위해 다운타임을 예약해야 합니다. 데이터베이스 크기와 설정에 따라 v6.0으로의 마이그레이션은 상당한 시간이 걸릴 수 있으며, 게시물 테이블을 잠글 수도 있어 마이그레이션이 완료될 때까지 사용자가 메시지를 게시하거나 수신할 수 없게 됩니다.

고가용성 클러스터 기반 배포 업그레이드 가이드 와 중요 업그레이드 참고사항 를 검토하여 특정 버전에서 업그레이드하기 전후에 취해야 할 조치를 인지하도록 하세요.

중요

클러스터에서 두 가지 다른 버전의 Mattermost를 실행하는 것은 업그레이드 시나리오 외에는 수행하지 마세요. v6.0의 클러스터링 코드에 근본적인 변경이 있어 중요 업그레이드 참고사항 제품 문서에 명시된 대로 다른 버전의 노드를 실행할 수 없습니다.

v6.0 릴리스는 데이터베이스 스키마 변경을 도입하며 마이그레이션 시간이 더 길어질 것으로 예상됩니다.