Mattermost v8.0부터 PostgreSQL은 플랫폼 성능과 기능을 향상시키기 위한 Mattermost의 선택 데이터베이스입니다. MySQL 데이터베이스에서 마이그레이션하는 데 관심 있는 커뮤니티 구성원을 지원하는 것의 중요성을 인식하여 지침과 모범 사례를 제공하기 위한 선제적 조치를 취했습니다.

* MySQL에서 PostgreSQL로 자동 마이그레이션 - 마이그레이션 프로세스를 간소화하고, 잠재적인 문제를 완화하며, 원활한 전환을 촉진하는 종합적인 지침과 migration-assist 도구.

* MySQL에서 PostgreSQL로 수동 마이그레이션 - 조직에 마이그레이션 프로세스를 담당할 데이터베이스 관리자가 있거나, migration-assist 도구가 자동화하는 내용을 알고 싶은 경우에 적합한 옵션.

자주 묻는 질문#

왜 Mattermost는 MySQL 지원을 중단하나요?#

Mattermost는 개발을 간소화하고 더 효율적이고 최적화된 기능 제공에 집중하기 위해 MySQL 데이터베이스 지원을 중단하기로 결정했습니다. 일반적으로 엔터프라이즈 환경에 더 적합하고 발전된 것으로 간주되는 PostgreSQL만 지원함으로써 Mattermost는 복잡성을 줄이고, 성능을 개선하며, 제품 향상에 더 많은 자원을 할당할 수 있습니다. 이 변경은 모든 Mattermost 배포에서 더 일관되고 견고하며 확장 가능한 데이터베이스 상호 작용을 보장하는 데 도움이 됩니다.

Mattermost를 업그레이드하기 전에 PostgreSQL로 마이그레이션하는 것을 권장하나요?#

예. 또한 PostgreSQL로 마이그레이션하기 전에 Mattermost 서버 v8.x 이상으로 업그레이드하는 것을 권장합니다.

migration-assist를 Mattermost 서버에서 실행할 수 있나요?#

기술적으로 가능합니다. migration-assist 도구는 Mattermost 서버에서 실행할 수 있습니다. 그러나 성능 문제를 방지하기 위해 별도의 서버에서 도구를 실행하는 것을 권장합니다. 마이그레이션 프로세스가 프로덕션 환경에 영향을 주지 않도록 MySQL 데이터베이스의 복사본에 대해 마이그레이션을 실행하는 것을 권장합니다.

PostgreSQL 서버는 얼마나 커야 하나요?#

PostgreSQL 서버 크기는 처음에는 MySQL 서버와 일치해야 합니다. PostgreSQL 서버의 성능을 모니터링하고 필요에 따라 리소스를 조정하는 것을 권장합니다.

migration-assist 서버를 실행하는 서버는 얼마나 커야 하나요?#

도구 자체는 경량이며 큰 서버를 필요로 하지 않습니다. 2개 CPU 코어와 16GB RAM이 있는 서버면 기본 구성에 충분합니다. 그러나 MySQL 데이터베이스 크기, 다운타임 제한 및 pgloader 구성에 따라 리소스를 조정해야 할 수 있습니다.

Mattermost가 pgloader를 번들로 제공하나요, 아니면 별도로 설치해야 하나요?#

Mattermost는 Mattermost 서버에 pgloader를 번들로 제공하지 않습니다. pgloader를 별도로 설치해야 합니다. 자세한 내용은 pgloader 설치 문서를 참조하세요.

플러그인에 대한 다른 마이그레이션이 있나요, 아니면 Boards, Playbooks, Calls만 해당하나요?#

NPS-plugin 등 다른 플러그인에 대한 마이그레이션을 개발 중입니다. 업데이트를 기대해 주세요.

이 프로세스가 AWS RDS 데이터베이스를 지원하나요?#

예, 프로세스는 AWS RDS 데이터베이스를 지원합니다. 그러나 마이그레이션 프로세스가 데이터베이스에 접근할 수 있도록 보안 그룹 설정을 조정해야 할 수 있습니다.

Mattermost가 MariaDB를 지원하나요? 지원하지 않는다면 이유는 무엇인가요?#

Mattermost는 MariaDB를 지원하지 않습니다. 이 결정의 주요 이유는 단일 데이터베이스 기술에 집중하여 개발 및 유지 관리를 간소화하기 위한 것입니다. PostgreSQL을 표준으로 채택함으로써 Mattermost는 최적화된 기능, 향상된 성능 및 더 집중된 엔지니어링 노력을 제공할 수 있습니다. PostgreSQL은 견고함, 고급 기능 및 엔터프라이즈 사용에 적합한 것으로 잘 알려져 있어 Mattermost의 선택 데이터베이스입니다.

MariaDB는 MySQL과 대부분 호환되지만, Mattermost 개발 팀이 데이터베이스 지원을 제한하여 피하려는 추가적인 복잡성과 잠재적 불일치를 도입합니다.

이러한 이유로 MariaDB에서 PostgreSQL로의 직접 마이그레이션도 지원하지 않습니다.

Oracle은 PostgreSQL로 마이그레이션하기 위한 출발점으로 사용할 수 있는 MariaDB에서 MySQL로 마이그레이션하는 방법에 대한 문서를 제공합니다.

문제 해결#

MySQL에 대한 지원되지 않는 인증#

MySQL v8의 인증으로 인한 오류가 발생하는 경우, pgloader의 알려진 문제와 관련이 있을 수 있습니다. 수정 방법은 MySQL 구성에서 기본 인증 방법을 mysql_native_password로 설정하는 것입니다. 이를 위해 mysql.cnf 파일에 default-authentication-plugin=mysql_native_password 값을 추가하세요. 또한 이 인증 방법을 사용하도록 사용자를 업데이트하는 것을 잊지 마세요.

ALTER USER '<mysql_user>'@'%' IDENTIFIED WITH mysql_native_password BY '<mysql_password>';

pgloader 명령 실행 중 오류#

pgloader 명령 실행 중 오류가 발생하면 두 데이터베이스 모두 접근 가능하고 사용자가 데이터베이스에 접근하는 데 필요한 권한을 갖고 있는지 확인하세요. pgloader 명령 실행 중 오류가 있는 경우 마이그레이션을 계속하지 마세요.

다음 섹션에서는 pgloader 명령 실행 중 발생할 수 있는 일반적인 오류를 해결하는 방법을 자세히 설명합니다:

JSON 유형에 대한 잘못된 입력 구문#

다음과 유사한 오류 메시지를 받는 경우:

ERROR Database error 22P02: invalid input syntax for type json

MySQL 데이터베이스의 데이터가 유효한 JSON 형식이 아닙니다. MySQL 데이터베이스의 데이터를 유효한 JSON 형식으로 업데이트하여 이 문제를 수정할 수 있습니다. 어떤 행이 문제를 일으키는지 알아내려면 다음 쿼리를 실행하세요(<table_name>과 <column_name>을 pgloader 출력에 표시된 실제 테이블 및 열 이름으로 교체):

SELECT * FROM <table_name> WHERE JSON_VALID(<column_name>) = 0;

위 쿼리로 MySQL 데이터베이스의 데이터를 찾아 유효한 JSON 형식으로 업데이트할 수 있습니다. 데이터를 업데이트한 후 pgloader 명령을 다시 실행할 수 있습니다.

열 또는 테이블을 찾지 못함#

다음과 유사한 오류 메시지를 받는 경우:

pgloader failed to find column

PostgreSQL 데이터베이스에 열 또는 테이블이 없습니다. 올바른 버전의 Postgres 스키마를 만들었는지 확인하여 이 문제를 수정할 수 있습니다. 스키마를 다시 만든 후 pgloader 명령을 다시 실행할 수 있습니다.

ECASE 표현식 실패#

다음과 유사한 오류 메시지를 받는 경우:

ERROR mysql: 76 fell through ECASE expression.

pgloader의 알려진 문제입니다. 소스에서 pgloader를 컴파일하거나 Docker 이미지로 pgloader를 실행하면 이 문제를 해결할 수 있습니다. 자세한 내용은 pgloader 설치를 참조하세요.

Mattermost가 PostgreSQL 데이터베이스에 연결할 수 없음#

Mattermost가 PostgreSQL 데이터베이스에 연결할 수 없는 문제가 발생하는 경우 PostgreSQL 서버가 실행 중이고 데이터베이스에 접근할 수 있는지 확인하세요. pgloader 명령 실행 중 오류가 있었다면 스키마 이름을 public으로 되돌리지 못하거나 search_path를 복원하지 못할 수 있습니다. 다음 명령을 실행하여 스키마 이름을 수동으로 public으로 되돌리고 search_path를 복원할 수 있습니다:

1. sudo -u postgres psql을 사용하여 PostgreSQL에 연결합니다.
2. \c mattermost를 사용하여 mattermost 데이터베이스를 선택합니다. SELECT current_database();를 실행하여 올바른 데이터베이스를 사용하고 있는지 확인합니다. 명령은 mattermost를 출력해야 합니다.
3. 스키마 이름 변경 되돌리기 (선택 사항)

ALTER SCHEMA <schema_name> RENAME TO public;

또한 데이터베이스 사용자가 public 스키마에 기본 접근하는 데 필요한 설정을 갖도록 확인하세요. 다음 명령을 실행하여 이를 수행할 수 있습니다:

4. mmuser에 대한 search_path 설정:

ALTER USER mmuser SET search_path TO "$user", public;


5. 연결을 종료하고 psql 서버에 다시 연결합니다.

5. search_path가 올바르게 설정되었는지 확인합니다:

SHOW search_path;

이는 ``"$user", public``을 반환해야 합니다.

6. 문제가 지속되면 다음도 실행합니다:

SELECT pg_catalog.set_config('search_path', '"$user", public', false);

PostgreSQL에서 스키마 접근 시 권한 문제#

2단계에서 권한 문제가 발생하여 명령이 다음과 유사한 권한 문제를 보고하는 경우:

An Error Occurred: could not check schema owner: the user "mmuser" is not owner of the "public" schema

PostgreSQL의 mmuser 사용자가 스키마의 소유자인지 확인하세요.

1. sudo -u postgres psql을 사용하여 PostgreSQL에 연결합니다.
2. \c mattermost를 사용하여 mattermost 데이터베이스를 선택합니다. SELECT current_database();를 실행하여 올바른 데이터베이스를 사용하고 있는지 확인합니다. 명령은 mattermost를 출력해야 합니다.
3. 다음 명령을 실행합니다:

ALTER SCHEMA public OWNER TO mmuser;
GRANT USAGE, CREATE ON SCHEMA public TO mmuser;

그런 다음 2단계의 명령을 다시 실행합니다.

마이그레이션 후 수신 웹훅 채널 이름이 대소문자를 구분하게 됨#

MySQL에서 PostgreSQL로 마이그레이션한 후 이전에 혼합 대소문자 채널 이름(예: "Tech-Talk")으로 작동했던 수신 웹훅이 다음 오류로 실패합니다:

GetChannelByName: Channel does not exist.

Mattermost는 대문자가 포함된 채널 생성을 허용하지 않기 때문에 이런 문제가 발생합니다. 모든 새 채널 이름은 소문자만 포함해야 합니다.

또한 MySQL은 채널 이름 매칭 시 대소문자를 구분하지 않지만 PostgreSQL은 대소문자를 구분합니다. 이는 MySQL의 허용적인 대소문자 무감 매칭으로 작동했던 웹훅 페이로드가 PostgreSQL의 엄격한 대소문자 구분 매칭에서 실패할 것임을 의미합니다.

드문 경우, 이전 채널이 데이터베이스에 혼합 대소문자 이름으로 여전히 존재할 수 있습니다. 이러한 채널은 유효하지 않은 것으로 간주되며 채널 헤더 업데이트와 같은 작업을 수행할 때 문제가 발생할 수 있습니다.

해결 방법:

모든 웹훅 페이로드를 소문자 채널 이름만 사용하도록 업데이트하세요.

예방:

PostgreSQL로 마이그레이션하기 전에:

1. 수신 웹훅을 감사하고 페이로드에서 혼합 대소문자 채널 이름을 사용하는 것을 업데이트합니다.
2. 이전 버전에서 만들어진 혼합 대소문자 이름의 레거시 채널이 있는지 확인합니다.
3. 문제를 방지하기 위해 혼합 대소문자 채널을 소문자로 이름을 변경하는 것을 고려하세요.

이것은 PostgreSQL에서 예상되는 동작이며 Mattermost의 채널 명명 요구 사항을 반영합니다.

마이그레이션 오류를 일으키는 레거시 Boards 테이블#

MySQL에서 PostgreSQL로 데이터베이스 마이그레이션 중 스키마 비교 도구(예: dbcmp)를 사용할 때 다음 오류가 발생할 수 있습니다:

error during comparison: no pk defined for table: focalboard_file_info

이것은 일반적으로 더 이상 사용되지 않는 이전 버전의 Boards의 레거시 테이블과 관련이 있습니다. Boards 버전 8.0.0 이상을 사용하는 경우 이 테이블은 더 이상 필요하지 않으며 마이그레이션 프로세스에서 무시할 수 있습니다.

적용 대상:

* Boards 버전 8.0.0 이상

* 모든 스테이징, UAT, QA 또는 프로덕션 환경

해결 방법:

Boards 버전 8.0.0 이상을 사용하는 경우 독립 실행형 버전에서만 사용되었으며 안전하게 무시할 수 있는 다음 레거시 테이블이 있습니다:

* focalboard_file_info - 독립 실행형 버전에서 사용됨; 플러그인 및 이후 버전에서는 더 이상 관련 없음. Boards의 업로드된 파일과 첨부 파일을 저장합니다.

* focalboard_sessions - 독립 실행형 버전에서 사용됨. Boards의 사용자 로그인 세션을 추적합니다.

* focalboard_teams - 독립 실행형 버전에서 사용됨. 이후 버전에서 사용되지 않는 레거시 팀 매핑. 팀 board 설정 및 권한을 저장합니다.

* focalboard_users - 독립 실행형 버전에서 사용됨. Boards의 사용자 기본 설정을 저장합니다.

이 테이블들은 현재 환경에서 비어 있거나 사용되지 않을 수 있습니다. 그런 경우 PostgreSQL로 마이그레이션할 필요가 없습니다.

지원 문의#

Mattermost 배포에 맞춤화된 지침을 원하는 Mattermost 고객은 Mattermost 전문가에게 문의할 수 있습니다.