Data Science Lab

[MySQL] MySQL Percona XtraDB Cluster 소개 및 설정 변수 알아보기

l  Version : MySQL Percona 8.X

Percona XtraDB Cluster는 MySQL을 위한 완전한 오픈 소스 고가용성 솔루션으로 MySQL용 Percona Server 및 Percona XtraBackup을 Galera 라이브러리와 통합하여 동기식 다중 소스 복제를 가능하게 한다. Galera 라이브러리에 대한 내용은 아래 링크를 참고한다.

l  MySQL/MariaDB 환경에서 다중 마스터 복제를 지원하는 Galera Cluster 알아보기 : https://sungwookkang.com/entry/MySQLMariaDB-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-%EB%8B%A4%EC%A4%91-%EB%A7%88%EC%8A%A4%ED%84%B0-%EB%B3%B5%EC%A0%9C%EB%A5%BC-%EC%A7%80%EC%9B%90%ED%95%98%EB%8A%94-Galera-Cluster-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

l  MySQL Galera Cluster + ProxySQL에서 Galera Cluster 특성을 고려한 R/W 호스트 그룹 설정 하기 : https://sungwookkang.com/entry/MySQL-Galera-Cluster-ProxySQL%EC%97%90%EC%84%9C-Galera-Cluster-%ED%8A%B9%EC%84%B1%EC%9D%84-%EA%B3%A0%EB%A0%A4%ED%95%9C-RW-%ED%98%B8%EC%8A%A4%ED%8A%B8-%EA%B7%B8%EB%A3%B9-%EC%84%A4%EC%A0%95-%ED%95%98%EA%B8%B0

클러스터는 노드로 구성되며, 각 노드에는 노드 전체에 걸쳐 동기화된 동일한 데이터 세트가 포함되어 있다. 권장되는 구성은 3개 이상의 노드를 보유하는 것이지만 2개의 노드를 보유할 수도 있다. 각 노드는 일반 MySQL Server 인스턴스(예: Percona Server)이다. 기존 MySQL Server 인스턴스를 노드로 변환하고 이 노드를 기본으로 사용하여 클러스터를 실행할 수 있다. 클러스터에서 노드를 분리하여 일반 MySQL Server 인스턴스로 사용할 수도 있다.

Percona XtraDB Cluster 장점은 쿼리를 실행하면 노드에서 로컬로 실행된다. 모든 데이터는 로컬에서 사용할 수 있으므로 원격 액세스가 필요하지 않다. 중앙 관리 시스템이 아니므로 언제든지 노드를 유연하게 구성할 수 있으며 클러스터는 데이터 손실 없이 계속 작동한다. 읽기 작업 부하를 확장하는 데 적합한 솔루션이며 모든 노드에 읽기 쿼리를 호출할 수 있다.

단점으로는 노드 프로비저닝의 오버헤드가 있다. 새 노드를 추가하면 기존 노드 중 하나에서 전체 데이터 세트를 복사해야 한다. 예를 들어 노드가 100GB이면 100GB를 복사하는 방식이다. 이러한 특징 때문에 쓰기 확장 솔루션으로는 사용할 수 없다. 전체 트래픽을 1개 노드에 실행하는 경우에 비해 2개 노드에 쓰기 트래픽을 실행하는 경우 쓰기 처리량이 약간 향상될 수 있지만 많은 것을 기대할 수는 없다. 모든 쓰기는 여전히 모든 노드에서 진행되기 때문이다.

Percona XtraDB Cluster 구성요소는 XtraDB 스토리지 엔진으로 실행되는 MySQL용 Percona 서버를 기반으로 하며, Codership Oy에서 개발한 쓰기 세트 복제(wsrep) API의 구현인 Galera 라이브러리를 사용한다. 기본 및 권장 데이터 전송 방법은 Percona XtraBackup을 사용한다.

[XtraDB Cluster제약 사항]

l   복제는 InnoDB 스토리지 엔진에서만 작동한다.

l   다른 유형의 테이블에 대한 쓰기는 복제되지 않는다.

l   LOCK TABLES 및 UNLOCK TABLES는 다중 소스 설정에서 지원되지 않는다.

n  GET_LOCK(), RELEASE_LOCK() 등과 같은 잠금 함수

l   쿼리 로그를 테이블로 보낼 수 없다. 쿼리 로깅을 활성화하는 경우 로그를 파일로 전달해야 한다. 쿼리 로깅 및 로그 파일 이름을 선택하려면 General_log 및 General_log_file을 사용해야 한다.

l   허용되는 최대 트랜잭션 크기는 wsrep_max_ws_rows 및 wsrep_max_ws_size 변수에 의해 정의된다.

l   LOAD DATA INFILE 처리는 10,000개 행마다 커밋된다. 따라서 LOAD DATA로 인한 대규모 트랜잭션은 일련의 작은 트랜잭션으로 분할된다.

l   COMMIT를 발행하는 트랜잭션은 해당 단계에서 여전히 중단될 수 있다.

l   클러스터 수준의 낙관적 동시성 제어로 인해 동일한 행에 쓰고 별도의 Percona XtraDB 클러스터 노드에서 커밋하는 두 개의 트랜잭션이 있을 수 있으며 그 중 하나만 성공적으로 커밋할 수 있다. 실패한 항목은 중단되며, 클러스터 수준 중단의 경우 Percona XtraDB Cluster는 교착 상태 오류 코드를 반환한다.

l   XA 트랜잭션은 지원되지 않는다. 커밋시 롤백이 가능하기 때문이다.

l   전체 클러스터의 쓰기 처리량은 가장 약한 노드에 의해 제한된다. 한 노드가 느려지면 전체 클러스터도 느려진다.

l   최소 권장 클러스터 크기는 노드 3개이다. 세 번째 노드는 중재자가 될 수 있다.

l   enforce_storage_engine=InnoDB는 wsrep_replicate_myisam=OFF와 호환되지 않는다. wsrep_replicate_myisam은 기본적으로 OFF로 설정된다.

l   클러스터 모드에서 Percona XtraDB Cluster를 실행할 때 ALTER TABLE ... IMPORT/EXPORT 워크로드를 가급적 사용하지 않도록 한다. 모든 노드에서 동기화되어 실행되지 않으면 노드 불일치가 발생할 수 있다.

l   모든 테이블에는 기본 키가 있어야 합니다. 이렇게 하면 동일한 행이 다른 노드에서 동일한 순서로 표시된다. 기본 키가 없는 테이블에서는 DELETE 문이 지원되지 않는다.

l   임시 테이블에 영구 테이블 이름을 재사용하지 않도록 한다. MySQL은 영구 테이블과 동일한 이름의 임시 테이블을 허용하지만 이 접근 방식은 권장되지 않는다. Galera Cluster는 이름이 임시 테이블의 이름과 일치하는 영구 테이블의 복제를 차단한다.

l   wsrep_debug를 1로 설정하면 오류 로그에 다음 메시지가 포함될 수 있다.

l   버전 8.0.21부터 INPLACE ALTER TABLE 쿼리는 쿼리 실행 중에 테이블에 대한 내부 공유 잠금을 사용한다. 이 변경으로 인해 모든 INPLACE ALTER TABLE 쿼리에 대해 LOCK=NONE 절이 더 이상 허용되지 않는다. 이 변경 사항은 다음 시나리오에서 클러스터 노드가 중단될 수 있는 교착 상태를 해결한다.

n  한 세션에 있거나 TOI(Total Order Isolation)로 적용되는 INPLACE ALTER TABLE 쿼리

n  다른 세션의 동일한 테이블에 있는 DML

n  log_bin, log_bin_index 값을 정의할 때 하나 이상의 점 문자(.)를 사용하지 않는다.

n  MySQL과 XtraBackup은 서로 다른 방식으로 값을 처리하며 이러한 차이로 인해 예측할 수 없는 동작이 발생한다.

[Percona 버전 번호이해]

버전 번호는 제품 릴리스를 식별한다. 제품에는 해당 릴리스 당시의 최신 GA(일반 출시) 기능이 포함되어 있다.

Percona는 기본 버전, 마이너 빌드 및 선택적 사용자 정의 빌드 패턴을 따르는 의미 체계 버전 번호 지정을 사용한다. Percona는 각 마이너 빌드 릴리스에 대해 음수가 아닌 고유한 정수를 오름차순으로 할당한다. 버전 번호는 필요한 경우 기본 Percona Server for MySQL 버전 번호, 마이너 빌드 버전 및 사용자 정의 빌드 버전을 결합한다.

l   Base Version : 기본으로 사용되는 Percona Server for MySQL 버전을 나타내는 가장 왼쪽 숫자 집합으로, 베이스 버전이 이 증가하면 마이너 빌드 버전과 사용자 정의 빌드 버전이 0으로 재설정된다.

l   Minor Build : Percona XtraDB 클러스터가 릴리스 될 때마다 증가하는 내부 번호이며 사용자 정의 빌드 번호는 0으로 재설정된다.

l   Customer Build : 버그 수정에 사용되는 사용자 정의 빌드에 할당된 선택적 번호이다. 수정 사항에 해당 기능이 포함되지 않는 한 기능은 변경되지 않는다. 예를 들어 Percona XtraDB Cluster 8.0.20-11.1, 8.0.20-11.2 및 8.0.20-11.3은 동일한 Percona Server for MySQL 버전 및 마이너 빌드 버전을 기반으로 하지만 사용자 정의 빌드 버전이다.

[wsrep status variables]

[wsrep system variables]

[참고자료]

l   About Percona XtraDB Cluster : https://docs.percona.com/percona-xtradb-cluster/8.0/intro.html

2023-09-27 / Sungwook Kang / http://sungwookkang.com

MySQL Percona, XtraDB, XtraBackup, XtraDB Cluster, 퍼코나 클러스터, 퍼코나 데이터베이스

[Linux] 리눅스 디스크 용량 확인

l  Linux

리눅스 시스템을 운영하다 보면 디스크 공간 사용률이 100%가 되어 서비스에 장애가 발생하는 경우가 있다. 일반적으로 실수하는 부분이 로그 파일을 방치하여 어느 순간 디스크 공간을 모두 소진하였거나, 데이터베이스 서버의 경우 데이터를 백업할 때 순간적으로 디스크를 모두 소진하여 발생할 때가 있다. 주기적인 시스템 모니터링으로 디스크 공간에 대한 사용률을 확인하여 사전에 이러한 부분을 방지할 수 있도록 하는 것이 중요하다. 그렇다면 어느 디렉터리에서 많은 공간을 사용하는지를 확인하는 방법은 무엇일까? 이번 포스트에서는 리눅스에서 디스크 사용량을 확인하는 방법에 대해서 알아본다.

리눅스에서 디스크 공간을 확인하는 명령어는 df (Disk Free)이다. 마운트 되어있는 모든 디스크의 사용량을 보여준다. 1K-blocks 항목이 디스크에 할당된 용량이며, Used는 실제 사용량, Available는 사용 가능한 공간, Use%는 디스크 공간에서 사용률을 퍼센트로 나타낸다.

디스크 용량 및 사용량이 킬로바이트로 표시되기 때문에 용량이 큰 경우 자릿수로 인해 쉽게 사용자가 확인하기 어렵다. 이때 -h 옵션을 사용하면 사용자 친화적으로 확인할 수 있다.

디스크가 아닌 각 디렉터리별 사용량 확인은 du명령을 사용한다. du는 disk usage의 약자로 하위 디렉토리를 포함한 디스크 사용량을 보여준다.

하위 디렉터리가 많을 경우, 어느 디렉토리에서 사용량이 많은지 한번에 확인하기 힘들다. 따라서 사용량 기준으로 정렬한 결과를 표시할 때에는 sort -n 옵션을 사용한다.

그런데 나타난 결과를 보면 정렬 상태가 이상하다. 단위가 바뀌면서 88K가 4.1G 보다 더 큰 것처럼 정렬되었다. 따라서 정렬을 할 때에는 -h 옵션을 사용하지 않도록 한다.

2023-09-26 / Sungwook Kang / https://sungwookkang.com

리눅스, Linux, 디스크 사용량, 리눅스 디스크, 디스크 usage, disk usage

[MySQL] MySQL 5.7에서 8.0으로 업그레이드시 변경되는 설정 및 옵션 정리

l  Version : MySQL 8.X

MySQL 5.7 버전과 MySQL 8.0은 큰 변화가 있기 때문에, 업그레이드하기 전에 많은 주의가 필요하다. 현재 운영중인 MySQL 5.7X 버전에서 MySQL 8.0.X로 업그레이드 프로젝트를 진행하게 되어, 업그레이드시 주의해야 될 사항 및 변경되는 사항을 정리해본다.

[Data Dictionary]

MySQL Server 8.0에는 트랜잭션 테이블의 데이터베이스 개체에 대한 정보가 포함된 전역 Data Dictionary가 통합되어 있다. 이전 MySQL 시리즈에서는 Data Dictionary가 메타데이터 파일과 InnoDB 시스템 테이블에 저장되었다. 이전에는 innodb_read_only 시스템 변수를 활성화하면 InnoDB 스토리지 엔진에 대해서만 테이블을 생성하고 삭제할 수 없었다. MySQL 8.0부터 innodb_read_only를 활성화하면 모든 스토리지 엔진에 대해 이러한 작업이 방지된다. 모든 스토리지 엔진에 대한 테이블 생성 및 삭제 작업은 mysql 시스템 데이터베이스의 데이터 Dictionary 테이블을 수정하지만 해당 테이블은 InnoDB 스토리지 엔진을 사용하며 innodb_read_only가 활성화되면 수정할 수 없다. Data Dictionary 테이블을 수정해야 하는 다른 테이블 작업에도 동일한 원칙이 적용된다.

이전에는 STATISTICS 및 테이블 통계에 대한 INFORMATION_SCHEMA 쿼리가 스토리지 엔진에서 직접 통계를 검색했다면, MySQL 8.0부터는 캐시된 테이블 통계가 기본적으로 사용된다. information_schema_stats_expiry 시스템 변수는 캐시된 테이블 통계가 만료되는 기간을 정의한다. 기본값은 86400초(24시간)이며, 테이블에 대해 수동으로 캐시된 값을 업데이트하려면 ANALYZE TABLE을 사용할 수 있다. 캐시된 통계가 없거나 통계가 만료된 경우에는 테이블 통계 열을 쿼리할 때 스토리지 엔진에서 통계가 검색된다. 항상 스토리지 엔진에서 직접 최신 통계를 검색하려면 information_schema_stats_expiry를 0으로 설정한다.

INFORMATION_SCHEMA 테이블은 Data Dictionary 테이블에 대한 뷰로, 이를 통해 최적화 프로그램은 해당 기본 테이블에 대한 인덱스를 사용할 수 있다. 결과적으로 최적화 프로그램 선택에 따라 INFORMATION_SCHEMA 쿼리 결과의 행 순서가 이전 결과와 다를 수 있다. 쿼리 결과에 특정 행 순서 특성이 있어야 하는 경우 ORDER BY 절을 포함한다.

INFORMATION_SCHEMA 테이블에 대한 쿼리는 이전 MySQL 시리즈와는 다른 문자로 열 이름을 반환할 수 있다. 애플리케이션은 결과 세트에 대해 열 이름이 대소문자를 구분하지 않도록 테스트해야 한다. 이러한 부분을 방지하려면 필수 문자 대소문자로 열 이름을 반환하도록 별칭을 사용한다.

mysqldump 및 mysqlpump는 명령줄에 명시적으로 이름이 지정된 경우에도 더 이상 INFORMATION_SCHEMA 데이터베이스를 덤프하지 않는다. Data Dictionary에 대한 자세한 내용은 아래 링크를 참고한다.

l  Data Dictionary Usage Differences : https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-usage-differences.html

[caching_sha2_password 인증 플러그인 변경]

caching_sha2_password 및 sha256_password 인증 플러그인은 mysql_native_password 플러그인보다 더 안전한 비밀번호 암호화를 제공하고, caching_sha2_password는 sha256_password보다 더 나은 성능을 제공한다. caching_sha2_password은 MySQL 8.0부터 기본 인증 플러그인으로 사용된다. 이 변경 사항은 서버와 libmysqlclient 클라이언트 라이브러리 모두에 영향을 미친다.

서버의 경우 default_authentication_plugin 시스템 변수의 기본값이 mysql_native_password에서 caching_sha2_password로 변경된다. 이 변경 사항은 MySQL 8.0 이상을 설치하거나 업그레이드한 후에 생성된 새 계정에만 적용된다. 업그레이드된 설치에 이미 존재하는 계정의 경우 해당 인증 플러그인은 변경되지 않은 상태로 유지된다. 기존 사용자를 caching_sha2_password로 전환하려면  ALTER USER 문을 사용하여 전환할 수 있다.

MySQL 8.0 이상으로 업그레이드한 후 호환성 문제가 발생하는 경우 이전 기본 인증 플러그인으로 되돌리도록 서버를 재구성할 수 있다. 이 설정을 사용하면 기본의 애플리케이션들이 이전의 패스워드 방식을 사용할 수 있다. 하지만 이 방법은 보안에 취약하기 때문에 영구적으로 사용할 수 없다.

자세한 내용은 아래 링크를 참고한다.

l  Pluggable Authentication : https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html#pluggable-authentication-compatibility

[caching_sha2_password and the root Administrative Account]

MySQL 8.0으로 업그레이드하는 경우 'root'@'localhost' 관리 계정용 플러그인을 포함하여 기존 인증 플러그인 계정은 변경되지 않은 상태로 유지된다. 새로운 MySQL 8.0 설치의 경우 데이터 디렉터리를 초기화하면 'root'@'localhost' 계정이 생성되고 해당 계정은 기본적으로 caching_sha2_password를 사용한다. 따라서 데이터 디렉터리 초기화 후 서버에 연결하려면 caching_sha2_password를 지원하는 클라이언트나 커넥터를 사용해야 한다. 신규 설치 후 루트 계정이 mysql_native_password를 사용하도록 하려면 MySQL을 설치하고 평소와 같이 데이터 디렉토리를 초기화한다. 그런 다음 루트로 서버에 연결하고 다음과 같이 ALTER USER를 사용하여 계정 인증 플러그인과 비밀번호를 변경한다.

[caching_sha2_password and Replication]

모든 서버가 MySQL 8.0.4 이상으로 업그레이드된 복제 시나리오에서 원본 서버에 대한 복제본 연결은 caching_sha2_password로 인증하는 계정을 사용할 수 있다. 이러한 연결의 경우 caching_sha2_password로 인증하는 계정을 사용하는 다른 클라이언트와 동일한 요구 사항이 적용된다. 즉, 보안 연결 또는 RSA 기반 암호 교환을 사용한다.

[Configuration Changes]

MySQL 스토리지 엔진은 자체 파티셔닝 핸들러 제공을 담당하며 MySQL 서버는 더 이상 일반 파티셔닝 지원을 제공하지 않는다. InnoDB와 NDB는 MySQL 8.0에서 지원되는 기본 파티셔닝 핸들러를 제공하는 유일한 스토리지 엔진이다. 다른 스토리지 엔진을 사용하는 파티션된 테이블은 서버를 업그레이드하기 전에 InnoDB 또는 NDB로 변환하거나 파티셔닝을 제거하기 위해 변경해야 한다. 그렇지 않으면 나중에 사용할 수 없다.

collation_server 및 collation_database 시스템 변수의 기본값이 latin1_swedish_ci에서 utf8mb4_0900_ai_ci로 변경되었다. 결과적으로 새 개체의 기본 문자 집합과 데이터 정렬은 명시적인 문자 집합과 데이터 정렬을 지정하지 않는 한 이전과 다르다. 여기에는 테이블, 뷰, 저장된 프로그램 등 데이터베이스와 그 안에 있는 개체가 포함된다. 이전 기본값이 사용되었다고 가정하면 이를 유지하기 위한 방법은 my.cnf 파일에서 아래 명령을 사용하여 서버를 재시작 한다.

복제된 설정에서 MySQL 5.7에서 8.0으로 업그레이드할 때, 업그레이드하기 전에 기본 문자 집합을 MySQL 5.7에서 사용된 문자 집합으로 다시 변경하는 것이 좋다. 업그레이드가 완료되면 기본 문자 집합을 utf8mb4로 변경할 수 있다. 또한 MySQL 8.0은 MySQL 5.7이 수행하지 않는 특정 문자 집합의 허용된 문자에 대한 검사를 시행한다는 점을 기억해야 한다. 이는 알려진 문제로 업그레이드를 시도하기 전에 사용 중인 문자 세트에 대해 정의되지 않은 문자가 주석에 포함되어 있는지 확인해야 한다.  아래 두 가지 방법 중 하나로 이 문제를 해결할 수 있다.

l  문제의 문자를 포함하는 문자 세트로 문자 세트를 변경

l  문제가 되는 문자를 제거

MySQL 8.0.11부터 서버 초기화 시 사용된 설정과 다른 lower_case_table_names 설정으로 서버를 시작할 수 없다. 다양한 데이터 사전 테이블 필드에서 사용되는 데이터 정렬은 서버가 초기화될 때 정의된 lower_case_table_names 설정을 기반으로 하고, 다른 설정으로 서버를 다시 시작하면 식별자 정렬 및 비교 방법과 관련하여 불일치가 발생하므로 제한이 필요하다.

[Server Changes]

MySQL 8.0.11에서는 사용자 계정의 비권한 특성을 수정하기 위한 GRANT 문 사용, NO_AUTO_CREATE_USER SQL 모드, PASSWORD() 함수, old_passwords 시스템 변수 등 계정 관리와 관련된 더 이상 사용되지 않는 여러 기능이 제거되었다. 이러한 제거된 기능을 참조하는 명령문을 MySQL 5.7에서 8.0으로 복제하면 복제 오류가 발생할 수 있다. 제거된 기능을 사용하는 애플리케이션은 이를 방지하도록 수정되어야 하며, 가능하면 MySQL 8.0에서 제거된 기능에 설명된 대로 대안을 사용해야 한다.

MySQL 8.0에서 시작 실패를 방지하려면 MySQL 옵션 파일의 sql_mode 시스템 변수 설정에서 NO_AUTO_CREATE_USER 인스턴스를 제거한다. 저장된 프로그램 정의에 NO_AUTO_CREATE_USER SQL 모드를 포함하는 덤프 파일을 MySQL 8.0 서버로 로드하면 오류가 발생한다. MySQL 5.7.24 및 MySQL 8.0.13부터 mysqldump는 저장된 프로그램 정의에서 NO_AUTO_CREATE_USER를 제거한다. 이전 버전의 mysqldump로 생성된 덤프 파일을 수동으로 수정하여 NO_AUTO_CREATE_USER 인스턴스를 제거해야 한다.

MySQL 8.0.11에서는 더 이상 사용되지 않는 호환성 SQL 모드인 DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS, NO_TABLE_OPTIONS가 제거되었다. 더 이상 sql_mode 시스템 변수에 할당하거나 mysqldump -- Compatible 옵션에 허용되는 값으로 사용할 수 없다. MAXDB가 제거된다는 것은 CREATE TABLE 또는 ALTER TABLE에 대한 TIMESTAMP 데이터 유형이 더 이상 DATETIME으로 처리되지 않음을 의미한다.

제거된 SQL 모드를 참조하는 명령문을 MySQL 5.7에서 8.0으로 복제하면 복제 오류가 발생할 수 있다. 여기에는 현재 sql_mode 값에 제거된 모드가 포함되어 있는 동안 실행되는 저장 프로그램(저장 프로시저 및 함수, 트리거 및 이벤트)에 대한 CREATE 문의 복제가 포함된다.

MySQL 8.0.3부터 공간 데이터 유형은 열에 저장된 값에 대한 공간 참조 시스템(SRS)을 명시적으로 나타내기 위해 SRID 속성을 허용한다. 명시적인 SRID 특성이 있는 공간 열은 SRID로 제한되며 해당열은 해당 ID를 가진 값만 사용하며 열의 SPATIAL 인덱스는 최적화 프로그램에서 사용하게 된다. 최적화 프로그램은 SRID 속성이 없는 공간 열의 SPATIAL 인덱스를 무시한다. 최적화 프로그램이 SRID로 제한되지 않은 공간 열의 SPATIAL 인덱스를 고려하도록 하려면 해당 열을 각각 수정해야 한다.

정확한 연산을 수행하는 함수에 대해 ST_ 접두사를 구현하거나 최소 경계 사각형을 기반으로 연산을 수행하는 함수에 대해 MBR 접두사를 구현하는 공간 함수 네임스페이스 변경으로 인해 MySQL 8.0.0에서 여러 공간 함수가 제거되었다. 생성된 열 정의에서 제거된 공간 함수를 사용하면 업그레이드가 실패할 수 있다. 업그레이드하기 전에 제거된 공간 함수에 대해 mysqlcheck --check-upgrade를 실행하고 찾은 모든 것을 ST_ 또는 MBR이라는 이름의 대체 항목으로 변경해야 한다. 제거된 함수목록은 아래 링크를 참고한다.

l   Features Removed in MySQL 8.0 : https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals

BACKUP_ADMIN 권한은 MySQL 8.0.3 이상으로 전체 업그레이드를 수행할 때 RELOAD 권한이 있는 사용자에게 자동으로 부여된다.

MySQL 8.0.13부터는 행 기반 또는 혼합 복제 모드와 명령문 기반 복제 모드의 임시 테이블 처리 방식 차이로 인해 런타임 시 바이너리 로깅 형식 전환에 대한 새로운 제한 사항이 있다. 세션에 열려 있는 임시 테이블이 있으면 SET @@SESSION.binlog_format을 사용할 수 없다. 복제 채널에 열려 있는 임시 테이블이 있으면 SET @@global.binlog_format 및 SET @@persist.binlog_format을 사용할 수 없다. PERSIST와 달리 PERSIST_ONLY는 런타임 전역 시스템 변수 값을 수정하지 않기 때문에 복제 채널에 열려 있는 임시 테이블이 있는 경우 SET @@persist_only.binlog_format이 허용된다. 복제 채널 적용자가 실행 중인 경우 SET @@global.binlog_format 및 SET @@persist.binlog_format을 사용할 수 없다. 이는 적용자가 다시 시작될 때만 변경 사항이 복제 채널에 적용되며 이때 복제 채널에 열려 있는 임시 테이블이 있을 수 있기 때문이다. 이 동작은 이전보다 더 제한적이며 복제 채널 적용자가 실행 중인 경우 SET @@persist_only.binlog_format이 허용된다.

MySQL 8.0.27부터 Internal_tmp_mem_storage_engine에 대한 세션 설정을 구성하려면 SESSION_VARIABLES_ADMIN 또는 SYSTEM_VARIABLES_ADMIN 권한이 필요하다.

MySQL 8.0.27부터 복제 플러그인은 복제 작업이 진행되는 동안 donor 역할을 하는 MySQL 인스턴스에서 동시 DDL 작업을 허용한다. 이전에는 복제 작업 중에 백업 잠금이 유지되어 donor에 대한 동시 DDL이 방지되었다. 복제 작업 중에 donor에서 동시 DDL을 차단하는 이전 동작으로 되돌리려면 clone_block_ddl 변수를 활성화한다. 자세한 내용은 아래 링크를 참고한다.

l   Cloning and Concurrent DDL : https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-concurrent-ddl.html

MySQL 8.0.30부터 시작 시 log_error_services 값에 나열된 오류 로그 구성 요소는 MySQL Server 시작 시퀀스 초기에 암시적으로 로드된다. 이전에 INSTALL COMPONENT를 사용하여 로드 가능한 오류 로그 구성 요소를 설치했고 시작 시 읽는 log_error_services 설정(예: 옵션 파일에서)에 해당 구성 요소를 나열한 경우 시작 경고가 발생하지 않도록 구성을 업데이트해야 한다. 자세한 내용은 아래 링크를 참고한다.

l   Error Log Configuration Methods : https://dev.mysql.com/doc/refman/8.0/en/error-log-configuration.html#error-log-configuration-methods

[InnoDB Changes]

InnoDB 시스템 테이블을 기반으로 하는 INFORMATION_SCHEMA 뷰는 Data Dictionary 테이블의 내부 시스템 뷰로 대체되었다. 그리고 영향을 받은 InnoDB INFORMATION_SCHEMA 뷰의 이름이 변경되었다. MySQL 8.0.3 이상으로 업그레이드한 후 이전 InnoDB INFORMATION_SCHEMA 뷰 이름을 참조하는 스크립트가 있다면 새로운 이름으로 업데이트 해야 한다.

MySQL과 함께 번들로 제공되는 zlib 라이브러리 버전이 버전 1.2.3에서 버전 1.2.11로 상향되었다. zlib 1.2.11의 zlib 압축Bound() 함수는 zlib 버전 1.2.3에서보다 주어진 바이트 길이를 압축하는 데 필요한 버퍼 크기의 약간 더 높은 추정치를 반환한다. CompressBound() 함수는 압축된 InnoDB 테이블을 생성하거나 압축된 InnoDB 테이블에 행을 삽입 및 업데이트할 때 허용되는 최대 행 크기를 결정하는 InnoDB 함수에 의해 호출된다. 결과적으로 이전 릴리스에서 성공했던 최대 행 크기에 매우 가까운 행 크기를 사용하는 CREATE TABLE ... ROW_FORMAT=COMPRESSED, INSERT 및 UPDATE 작업이 이제 실패할 수 있다. 이 문제를 방지하려면 업그레이드하기 전에 MySQL 8.0 테스트 인스턴스에서 큰 행이 있는 압축된 InnoDB 테이블에 대해 CREATE TABLE 문을 테스트해야 한다.

--innodb-directories 기능이 도입되면서 절대 경로 또는 데이터 디렉터리 외부 위치로 생성된 테이블당 파일 및 일반 테이블스페이스 파일의 위치가 innodb_directories 인수 값에 추가되어야 한다. 그렇지 않으면 InnoDB는 복구 중에 이러한 파일을 찾을 수 없어 오류가 발생한다. 테이블스페이스 파일 위치를 보려면 정보 스키마 FILES 테이블을 쿼리한단.

실행 취소 로그는 더 이상 시스템 테이블스페이스에 상주하지 않는다. MySQL 8.0에서 실행 취소 로그는 기본적으로 두 개의 실행 취소 테이블스페이스에 있다. 자세한 내용은 아래 링크를 참고한다.

l   Undo Tablespaces : https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html

MySQL 5.7에서 MySQL 8.0으로 업그레이드하면 MySQL 5.7 인스턴스에 존재하는 모든 실행 취소 테이블스페이스가 제거되고 두 개의 새로운 기본 실행 취소 테이블스페이스로 대체된다. 기본 실행 취소 테이블스페이스는 innodb_undo_directory 변수에 의해 정의된 위치에 생성된다. innodb_undo_directory 변수가 정의되지 않은 경우 데이터 디렉터리에 실행 취소 테이블스페이스가 생성된다. MySQL 5.7에서 MySQL 8.0으로 업그레이드하려면 MySQL 5.7 인스턴스의 실행 취소 테이블스페이스가 비어 있고 안전하게 제거될 수 있도록 느린 종료가 필요하다. 이전 MySQL 8.0 릴리스에서 MySQL 8.0.14 이상으로 업그레이드하는 경우 innodb_undo_tablespaces 설정이 2보다 큰 결과로 업그레이드 전 인스턴스에 존재하는 실행 취소 테이블스페이스는 사용자 정의 실행 취소 테이블스페이스로 처리된다. 업그레이드 후 각각 ALTER UNDO TABLESPACE 및 DROP UNDO TABLESPACE 구문을 사용하여 삭제되었다. MySQL 8.0 릴리스 시리즈 내에서 업그레이드할 때 항상 느린 종료가 필요한 것은 아니며, 이는 기존 실행 취소 테이블스페이스에 실행 취소 로그가 포함될 수 있음을 의미한다. 따라서 기존 실행 취소 테이블스페이스는 업그레이드 프로세스에 의해 제거되지 않는다.

MySQL 8.0.17부터 CREATE TABLESPACE ... ADD DATAFILE 절은 순환 디렉터리 참조를 허용하지 않는다. 예를 들어, 다음 명령문의 순환 디렉터리 참조(/../)는 허용되지 않는다. 제한사항에 대한 예외는 Linux에서 존재하며, 이전 디렉토리가 심볼릭 링크인 경우 순환 디렉토리 참조가 허용된다. 예를 들어, 위 예의 데이터 파일 경로는 any_directory가 심볼릭 링크인 경우 허용된다. (데이터 파일 경로가 '../'로 시작하는 것은 여전히 허용된다.) 업그레이드 문제를 방지하려면 MySQL 8.0.17 이상으로 업그레이드하기 전에 테이블스페이스 데이터 파일 경로에서 순환 디렉터리 참조를 제거하고, 테이블스페이스 경로를 검사하려면 정보 스키마 INNODB_DATAFILES 테이블을 쿼리한다.

MySQL 8.0.14에 도입된 회귀로 인해 분할된 테이블이 있고 lower_case_table_names=1로 설정된 인스턴스의 경우 MySQL 5.7 또는 MySQL 8.0.14 이전의 MySQL 8.0 릴리스에서 MySQL 8.0.16으로의 대소문자 불일치 문제로 인해 시스템 전체 업그레이드가 실패한다.

MySQL은 테이블 파티션의 테이블스페이스 이름과 파일 이름을 구성할 때 구분 기호 문자열을 사용한다. 다음과 같이 " #p# " 구분 기호 문자열은 파티션 이름 앞에 오고 " #sp# " 구분 기호 문자열은 하위 파티션 이름 앞에 위치한다. MySQL 업그레이드 작업 전 아래 상황을 확인하고 수정한다.

l   소문자 구분 기호와 파티션 이름을 보장하기 위해 디스크와 Data Dirctionray의 파일 이름을 파티션 한다.

l   이전 버그 수정으로 인해 발생한 관련 문제에 대한 데이터 사전의 파티션 메타데이터이다.

l   이전 버그 수정으로 인해 발생한 관련 문제에 대한 InnoDB 통계 데이터이다.

l   테이블스페이스 가져오기 작업 중에 디스크의 파티션 테이블스페이스 파일 이름을 확인하고 필요한 경우 소문자 구분 기호와 파티션 이름을 확인하기 위해 수정한다.

MySQL 8.0.21부터는 시작 시 또는 MySQL 5.7에서 업그레이드할 때 테이블스페이스 데이터 파일이 알 수 없는 디렉터리에 있는 것으로 발견되면 오류 로그에 경고가 기록된다. 알려진 디렉터리는 datadir, innodb_data_home_dir 및 innodb_directories 변수에 의해 정의된 디렉터리이다. 디렉터리를 알리려면 해당 디렉터리를 innodb_directories 설정에 추가한다. 디렉터리를 알리면 복구 중에 데이터 파일을 찾을 수 있다. 자세한 내용은 아래 링크를 참고한다.

l   Tablespace Discovery During Crash Recovery : https://dev.mysql.com/doc/refman/8.0/en/innodb-recovery.html#innodb-recovery-tablespace-discovery

MySQL 8.0.30부터 innodb_redo_log_capacity 변수는 리두 로그 파일이 차지하는 디스크 공간의 양을 제어한다. 이 변경으로 인해 리두 로그 파일의 기본 수와 해당 위치도 변경되었다. MySQL 8.0.30부터 InnoDB는 데이터 디렉토리의 #innodb_redo 디렉토리에 32개의 리두 로그 파일을 유지한다. 이전에 InnoDB는 기본적으로 데이터 디렉터리에 두 개의 리두 로그 파일을 생성했으며, 리두 로그 파일의 수와 크기는 innodb_log_files_in_group 및 innodb_log_file_size 변수에 의해 제어되었다. 이 두 변수는 이제 더 이상 사용되지 않는다.

innodb_redo_log_capacity 설정이 정의되면 innodb_log_files_in_group 및 innodb_log_file_size 설정이 무시된다. 그렇지 않으면 해당 설정은 innodb_redo_log_capacity 설정(innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity)을 계산하는 데 사용된다. 해당 변수가 설정되지 않은 경우 리두 로그 용량은 innodb_redo_log_capacity 기본값인 104857600바이트(100MB)로 설정된다.

MySQL 5.7.35 이전에는 중복 또는 압축 행 형식이 있는 테이블의 인덱스에 대한 크기 제한이 없었다. MySQL 5.7.35부터 제한은 767바이트이며, 5.7.35 이전의 MySQL 버전에서 MySQL 8.0으로 업그레이드하면 액세스할 수 없는 테이블이 생성될 수 있다. 중복 또는 압축 행 형식의 테이블에 767바이트보다 큰 인덱스가 있는 경우 MySQL 8.0으로 업그레이드하기 전에 인덱스를 삭제하고 다시 생성해야 한다. 이러한 부분에 문제가 발생하면 아래와 같은 오류 메시지가 나타난다.

[SQL Changes]

MySQL 8.0.13부터 GROUP BY 절에 대해 더 이상 사용되지 않는 ASC 또는 DESC 한정자가 제거되었다. 이전에 GROUP BY 정렬에 의존했던 쿼리는 이전 MySQL 버전과 다른 결과를 생성할 수 있다. 지정된 정렬 순서를 생성하려면 ORDER BY 절을 사용해야 한다. GROUP BY 절에 ASC 또는 DESC 한정자를 사용하는 MySQL 8.0.12 이하에서 해당 형식의 쿼리를 사용한다면 수정해야 한다. 그렇지 않으면 MySQL 8.0.13 이상 복제본 서버로의 복제와 마찬가지로 MySQL 8.0.13 이상으로의 업그레이드가 실패할 수 있다.

MySQL 5.7에서는 예약되지 않았던 일부 키워드가 MySQL 8.0에서는 예약어로 사용된다. 이로 인해 이전에 식별자로 사용된 단어가 불법이 될 수 있다. 변경된 예약어는 아래 링크를 참고한다.

l   Keywords and Reserved Words : https://dev.mysql.com/doc/refman/8.0/en/keywords.html

업그레이드한 후에는 애플리케이션 코드에 지정된 최적화 프로그램 힌트를 테스트하여 원하는 최적화 전략을 달성하는 데 힌트가 여전히 필요한지 확인하는 것이 좋다. 최적화 기능 향상으로 인해 특정 최적화 기능 힌트가 불필요해질 수 있다. 어떤 경우에는 불필요한 최적화 힌트가 역효과를 낳을 수도 있다.

MySQL 5.7에서 CONSTRAINT 기호 절 없이 InnoDB 테이블에 대한 FOREIGN KEY 정의를 지정하거나 기호 없이 CONSTRAINT 키워드를 지정하면 InnoDB가 생성된 제약 조건 이름을 사용하게 된다. 이 동작은 생성된 이름 대신 FOREIGN KEY index_name 값을 사용하는 InnoDB를 사용하여 MySQL 8.0에서 변경되었다. 제약 조건 이름은 스키마(데이터베이스)별로 고유해야 하기 때문에 변경으로 인해 스키마별로 고유하지 않은 외래 키 인덱스 이름으로 인해 오류가 발생한다. 이러한 오류를 방지하기 위해 새로운 제약 조건 명명 동작은 MySQL 8.0.16에서 되돌려졌으며 InnoDB는 다시 한번 생성된 제약 조건 이름을 사용한다. InnoDB와의 일관성을 위해 MySQL 8.0.16 이상 기반의 NDB 릴리스는 CONSTRAINT 기호 절이 지정되지 않거나 기호 없이 CONSTRAINT 키워드가 지정된 경우 생성된 제약 조건 이름을 사용한다. MySQL 5.7 및 이전 MySQL 8.0 릴리스를 기반으로 하는 NDB 릴리스는 FOREIGN KEY index_name 값을 사용했다. 이러한 변경 사항으로 인해 이전 외래 키 제약 조건 명명 동작에 의존하는 응용 프로그램에 대한 비호환성이 발생할 수 있다.

IFNULL() 및 CASE()와 같은 MySQL 흐름 제어 함수에 의한 시스템 변수 값 처리는 MySQL 8.0.22에서 변경되었다. 이제 시스템 변수 값은 상수가 아닌 동일한 문자 및 데이터 정렬의 열 값으로 처리된다. 이전에 성공했던 시스템 변수와 함께 이러한 함수를 사용하는 일부 쿼리는 나중에 잘못된 데이터 정렬 혼합으로 인해 거부될 수 있다. 이러한 경우 시스템 변수를 올바른 문자 집합과 데이터 정렬로 캐스팅해야 한다.

MySQL 8.0.28은 이전 MySQL 8.0 릴리스에서 CONVERT() 함수가 때때로 BINARY 값을 이진이 아닌 문자 집합으로 잘못 변환하는 것을 허용하는 문제를 수정했다. 이 동작에 의존할 수 있는 응용 프로그램을 확인하고 필요한 경우 업그레이드 전에 수정해야 한다. 특히 CONVERT()가 인덱스 생성 열에 대한 표현식의 일부로 사용된 경우 함수 동작의 변경으로 인해 MySQL 8.0.28로 업그레이드한 후 인덱스가 손상될 수 있다. 이러한 문제를 예방하기 위해 아래 목록을 적용해 볼 수 있다. 사전에 입력 데이터의 유효성을 검사할 수 없는 경우 MySQL 8.0.28로 업그레이드를 수행할 때까지 인덱스를 다시 생성하거나 테이블을 다시 작성해서는 안된다.

l   업그레이드를 수행하기 전에 잘못된 입력 데이터를 수정

l   인덱스를 삭제한 다음 다시 생성

l   ALTER TABLE 테이블 FORCE를 사용하여 테이블을 강제로 재구축

l   MySQL 소프트웨어를 업그레이드

[Changed Server Defaults]

아래표는 변경된 서버의  기본값이 요약되어 있다.