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

[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 문을 사용하여 전환할 수 있다.

ALTER USER user IDENTIFIED WITH caching_sha2_password BY 'password';

 

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

[mysqld] default_authentication_plugin=mysql_native_password

 

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

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를 사용하여 계정 인증 플러그인과 비밀번호를 변경한다.

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

 

 

[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 파일에서 아래 명령을 사용하여 서버를 재시작 한다.

[mysqld] character_set_server=latin1 collation_server=latin1_swedish_ci

 

복제된 설정에서 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 뷰 이름을 참조하는 스크립트가 있다면 새로운 이름으로 업데이트 해야 한다.

Old Name	New Name
INNODB_SYS_COLUMNS	INNODB_COLUMNS
INNODB_SYS_DATAFILES	INNODB_DATAFILES
INNODB_SYS_FIELDS	INNODB_FIELDS
INNODB_SYS_FOREIGN	INNODB_FOREIGN
INNODB_SYS_FOREIGN_COLS	INNODB_FOREIGN_COLS
INNODB_SYS_INDEXES	INNODB_INDEXES
INNODB_SYS_TABLES	INNODB_TABLES
INNODB_SYS_TABLESPACES	INNODB_TABLESPACES
INNODB_SYS_TABLESTATS	INNODB_TABLESTATS
INNODB_SYS_VIRTUAL	INNODB_VIRTUAL

 

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 테이블을 쿼리한단.

SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES \G

 

실행 취소 로그는 더 이상 시스템 테이블스페이스에 상주하지 않는다. 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으로 업그레이드하기 전에 인덱스를 삭제하고 다시 생성해야 한다. 이러한 부분에 문제가 발생하면 아래와 같은 오류 메시지가 나타난다.

mysql> ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

 

 

[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]

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

Option/Parameter	Old Default	New Default
Server changes
character_set_server	latin1	utf8mb4
collation_server	latin1_swedish_ci	utf8mb4_0900_ai_ci
explicit_defaults_for_timestamp	OFF	ON
optimizer_trace_max_mem_size	16KB	1MB
validate_password_check_user_name	OFF	ON
back_log	-1 (autosize) changed from : back_log = 50 + (max_connections / 5)	-1 (autosize) changed to : back_log = max_connections
max_allowed_packet	4194304 (4MB)	67108864 (64MB)
max_error_count	64	1024
event_scheduler	OFF	ON
table_open_cache	2000	4000
log_error_verbosity	3 (Notes)	2 (Warning)
local_infile	ON (5.7)	OFF
InnoDB changes
innodb_undo_tablespaces	0	2
innodb_undo_log_truncate	OFF	ON
innodb_flush_method	NULL	fsync (Unix), unbuffered (Windows)
innodb_autoinc_lock_mode	1 (consecutive)	2 (interleaved)
innodb_flush_neighbors	1 (enable)	0 (disable)
innodb_max_dirty_pages_pct_lwm	0 (%)	10 (%)
innodb_max_dirty_pages_pct	75 (%)	90 (%)
Performance Schema changes
performance-schema-instrument='wait/lock/metadata/sql/%=ON'	OFF	ON
performance-schema-instrument='memory/%=COUNTED'	OFF	COUNTED
performance-schema-consumer-events-transactions-current=ON	OFF	ON
performance-schema-consumer-events-transactions-history=ON	OFF	ON
performance-schema-instrument='transaction%=ON'	OFF	ON
Replication changes
log_bin	OFF	ON
server_id	0	1
log-slave-updates	OFF	ON
expire_logs_days	0	30
master-info-repository	FILE	TABLE
relay-log-info-repository	FILE	TABLE
transaction-write-set-extraction	OFF	XXHASH64
slave_rows_search_algorithms	INDEX_SCAN, TABLE_SCAN	INDEX_SCAN, HASH_SCAN
slave_pending_jobs_size_max	16M	128M
gtid_executed_compression_period	1000	0
Group Replication changes
group_replication_autorejoin_tries	0	3
group_replication_exit_state_action	ABORT_SERVER	READ_ONLY
group_replication_member_expel_timeout	0	5

 

 

[Server Defaults]

Character_set_server 시스템 변수 및 명령줄 옵션 --character-set-server의 기본값이 latin1에서 utf8mb4로 변경되었다. MySQL 5.7에서 MySQL 8.0으로 업그레이드해도 기존 데이터베이스 개체의 문자 집합은 변경되지 않는다. 하지만 Character_set_server를 명시적으로 설정하지 않는 한(이전 값 또는 새 값으로) 새 스키마는 기본적으로 utf8mb4를 사용한다. 가능하면 utf8mb4로 전환하는 것이 좋다.

 

collation_server 시스템 변수 및 명령줄 인수 --collation-server의 기본값이 latin1_swedish_ci에서 utf8mb4_0900_ai_ci로 변경되었다. 이는 서버의 기본 데이터 정렬, 즉 문자 집합의 문자 순서이다. 각 문자 집합에는 가능한 데이터 정렬 목록이 제공되므로 데이터 정렬과 문자 집합 사이에는 링크가 있다. 5.7에서 8.0으로 업그레이드해도 기존 데이터베이스 개체의 데이터 정렬은 변경되지 않지만 새 개체에는 적용된다.

 

licit_defaults_for_timestamp 시스템 변수의 기본값이 OFF(MySQL 레거시 동작)에서 ON(SQL 표준 동작)으로 변경되었다. 이 옵션은 원래 5.6에 도입되었으며 5.6 및 5.7에서는 OFF 되었다가 8.0에서 다시 ON으로 변경되었다.

 

Optimizer_trace_max_mem_size 시스템 변수의 기본값이 16KB에서 1MB로 변경되었다. 이전 기본값으로 인해 모든 중요 쿼리에 대해 최적화 프로그램 추적이 잘렸다. 이러한 변경으로 인해 대부분의 쿼리에 유용한 최적화 프로그램 추적이 보장된다.

 

verify_password_check_user_name 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, verify_password 플러그인이 활성화되면 기본적으로 현재 세션 사용자 이름과 일치하는 비밀번호를 거부한다.

 

back_log 시스템 변수의 자동 크기 조정 알고리즘이 변경되었다. 자동 크기(-1) 값은 이제 max_connections 값으로 설정됩니다. 이는 50 + (max_connections / 5)로 계산된 값보다 크다. back_log는 서버가 들어오는 요청을 따라잡을 수 없는 상황에서 들어오는 IP 연결 요청을 대기열에 추가한다. 최악의 경우, 동시에 재연결을 시도하는 클라이언트 수가 max_connections인 경우 모두 버퍼링될 수 있으며 거부-재시도 루프가 방지된다.

 

max_allowed_packet 시스템 변수의 기본값이 4194304(4M)에서 67108864(64M)로 변경되었다. 이 더 큰 기본값의 주요 이점은 max_allowed_packet보다 큰 삽입 또는 쿼리에 대한 오류를 수신할 가능성이 적다는 것이다. 이전 동작으로 되돌리려면 max_allowed_packet=4194304로 설정한다.

 

max_error_count 시스템 변수의 기본값이 64에서 1024로 변경되었다. 이는 MySQL이 1000개의 행에 닿는 UPDATE 문과 같은 더 많은 수의 경고를 처리하고 그 중 많은 경고가 변환 경고를 제공하도록 보장한다. 이 변경 사항은 정적 할당이 없으므로 많은 경고를 생성하는 문의 메모리 소비에만 영향을 미친다.

 

event_scheduler 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, 이벤트 스케줄러는 기본적으로 활성화되어 있다. 이는 "유휴 트랜잭션 종료"와 같은 SYS의 새로운 기능을 활성화하는 것이다.

 

table_open_cache 시스템 변수의 기본값이 2000에서 4000으로 변경되었다. 이는 테이블 액세스 시 세션 동시성을 높이는 것으로 사소한 변경 사항이다.

 

log_error_verbosity 시스템 변수의 기본값이 3(참고)에서 2(경고)로 변경되었다. 목적은 기본적으로 MySQL 8.0 오류 로그를 덜 장황하게 만드는 것이다.

 

 

[InnoDB Defaults]

innodb_undo_tablespaces 시스템 변수의 기본값이 0에서 2로 변경되었다. InnoDB에서 사용하는 실행 취소 테이블스페이스 수를 구성한다. MySQL 8.0에서 innodb_undo_tablespaces의 최소값은 2이며 더 이상 시스템 테이블스페이스에 롤백 세그먼트를 생성할 수 없다. 따라서 이는 5.7 동작으로 다시 되돌릴 수 없는 경우로, 이 변경의 목적은 실행 취소 로그(다음 항목 참조)를 자동으로 자르고 mysqldump와 같은 (가끔) 긴 트랜잭션에 사용되는 디스크 공간을 회수할 수 있도록 하는 것이다.

 

innodb_undo_log_truncate 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 활성화되면 innodb_max_undo_log_size에 정의된 임계값을 초과하는 실행 취소 테이블스페이스가 잘림으로 표시된다. 실행 취소 테이블스페이스만 잘라낼 수 있다. 시스템 테이블스페이스에 있는 실행 취소 로그 자르기는 지원되지 않는다. 5.7에서 8.0으로 업그레이드하면 실행 취소 테이블스페이스를 사용하도록 시스템이 자동으로 변환된다. 시스템 테이블스페이스 사용은 8.0에서 옵션이 아니다.

 

innodb_flush_method 시스템 변수의 기본값은 Unix 계열 시스템에서는 NULL에서 fsync로, Windows 시스템에서는 NULL에서 unbuffered로 변경되었다. 이는 실질적인 영향을 주지 않는것으로 용어 및 옵션 정리에 가깝다. Unix의 경우 이는 5.7에서도 기본값이 fsync였기 때문에 문서 변경일 뿐이다(기본 NULL은 fsync를 의미함). 마찬가지로 Windows에서 innodb_flush_method 기본값 NULL은 5.7에서 async_unbuffered를 의미했으며 8.0에서는 기본 unbuffered로 대체되었다. 이는 기존 기본 innodb_use_native_aio=ON과 결합하여 동일한 효과를 갖는다.

 

호환되지 않는 변경 innodb_autoinc_lock_mode 시스템 변수의 기본값이 1(연속)에서 2(인터리브)로 변경되었다. 기본 설정이 인터리브 잠금 모드로 변경된 것은 MySQL 5.7에서 발생한 기본 복제 유형이 명령문 기반에서 행 기반 복제로 변경된 것을 반영한다. 명령문 기반 복제에는 주어진 SQL 문 시퀀스에 대해 자동 증가 값이 예측 가능하고 반복 가능한 순서로 할당되도록 연속 자동 증가 잠금 모드가 필요한 반면, 행 기반 복제는 SQL 문의 실행 순서에 민감하지 않는다. 따라서 이 변경 사항은 명령문 기반 복제와 호환되지 않는 것으로 알려져 있으며 순차 자동 증분에 의존하는 일부 응용 프로그램이나 사용자 생성 테스트 모음을 손상시킬 수 있다. innodb_autoinc_lock_mode=1을 설정하여 이전 기본값을 복원할 수 있다.

 

innodb_flush_neighbors 시스템 변수의 기본값은 1(활성화)에서 0(비활성화)으로 변경된다. 이는 빠른 IO(SSD)가 이제 배포의 기본값이기 때문에 수행된다. 대부분의 사용자에게는 이로 인해 성능이 약간 향상될 것으로 예상된다. 느린 하드 드라이브를 사용하는 사용자는 성능 손실을 경험할 수 있으므로 innodb_flush_neighbors=1을 설정하여 이전 기본값으로 되돌리는 것이 좋다.

 

innodb_max_dirty_pages_pct_lwm 시스템 변수의 기본값이 0(%)에서 10(%)으로 변경되었다. innodb_max_dirty_pages_pct_lwm=10을 사용하면 InnoDB는 버퍼 풀의 10% 이상이 수정된('Dirty') 페이지를 포함할 때 플러시 활동을 증가시킨다. 이 변경의 목적은 보다 일관된 성능을 제공하는 대신 최대 처리량을 약간 낮추는 것이다.

 

innodb_max_dirty_pages_pct 시스템 변수의 기본값이 75(%)에서 90(%)으로 변경되었다. 이 변경 사항은 innodb_max_dirty_pages_pct_lwm에 대한 변경 사항과 결합되어 원활한 InnoDB 플러시 동작을 보장하고 플러시 버스트를 방지한다. 이전 동작으로 되돌리려면 innodb_max_dirty_pages_pct=75 및 innodb_max_dirty_pages_pct_lwm=0으로 설정한다.

 

 

[Performance Schema Defaults]

성능 스키마 MDL(메타 데이터 잠금) 계측은 기본적으로 켜져 있다. Performance-schema-instrument='wait/lock/metadata/sql/%=ON'에 대한 컴파일된 기본값이 OFF에서 ON으로 변경되었다. 이는 SYS에 MDL 지향 뷰를 추가하기 위한 활성화 도구이다.

 

성능 스키마 메모리 계측은 기본적으로 켜져 있다. Performance-schema-instrument='memory/%=COUNTED'에 대한 컴파일된 기본값이 OFF에서 COUNTED로 변경되었다. 서버 시작 후 계측이 활성화된 경우 집계 결과가 올바르지 않고 할당이 누락되었다가 여유 공간이 확보되면 마이너스 결과 값이 발생할 수 있으므로 이는 중요하다.

 

성능 스키마 트랜잭션 계측은 기본적으로 켜져 있습니다. Performance-schema-consumer-events-transactions-current=ON, Performance-schema-consumer-events-transactions-history=ON 및 Performance-schema-instrument='transaction%=ON'에 대한 컴파일된 기본값이 OFF에서 ON으로 변경되었다.

 

 

[Replication Defaults]

log_bin 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 즉, 바이너리 로깅이 기본적으로 활성화되어 있다. 거의 모든 프로덕션 설치에는 복제 및 특정 시점 복구에 사용되는 바이너리 로그가 활성화되어 있다. 따라서 기본적으로 바이너리 로그를 활성화하면 하나의 구성 단계가 제거되고 나중에 활성화하려면 mysqld를 다시 시작해야 한다. 기본적으로 이를 활성화하면 더 나은 테스트 적용 범위가 제공되고 성능 회귀를 더 쉽게 발견할 수 있다. server_id도 설정해야 한다. 8.0의 기본 동작은 ./mysqld --log-bin --server-id=1을 실행한 것과 같다. 8.0을 사용하고 있고 5.7 동작을 원하는 경우 ./mysqld --skip-log-bin --server-id=0을 실행할 수 있다.

 

server_id 시스템 변수의 기본값이 0에서 1로 변경되었다(log_bin=ON으로의 변경과 결합). 이 기본 ID로 서버를 시작할 수 있지만 실제로 중복된 서버 ID를 방지하려면 배포 중인 복제 인프라에 따라 서버 ID를 설정해야 한다.

 

log-slave-updates 시스템 변수의 기본값이 OFF에서 ON으로 변경되었다. 이로 인해 복제본은 복제된 이벤트를 자체 바이너리 로그에 기록한다. 이 옵션은 그룹 복제에 필요하며 오늘날 표준이 된 다양한 복제 체인 설정에서 올바른 동작을 보장한다.

 

expire_logs_days 시스템 변수의 기본값이 0에서 30으로 변경되었다. 새로운 기본값 30은 mysqld가 30일보다 오래된 사용되지 않은 바이너리 로그를 주기적으로 제거하도록 한다. 이 변경은 복제 또는 복구 목적에 더 이상 필요하지 않은 바이너리 로그에 과도한 양의 디스크 공간이 낭비되는 것을 방지하는 데 도움이 된다. 이전 값 0은 자동 바이너리 로그 제거를 비활성화한다.

 

master_info_repository 및 Relay_log_info_repository 시스템 변수의 기본값이 FILE에서 TABLE로 변경된다. 따라서 8.0에서는 복제 메타데이터가 기본적으로 InnoDB에 저장된다. 이렇게 하면 기본적으로 충돌 방지 복제를 시도하고 달성하기 위한 안정성이 향상된다.

 

transaction-write-set-extraction 시스템 변수의 기본값이 OFF에서 XXHASH64로 변경되었다. 이 변경으로 인해 기본적으로 트랜잭션 쓰기 세트가 활성화된다. 트랜잭션 쓰기 세트를 사용하면 소스가 쓰기 세트를 생성하기 위해 약간 더 많은 작업을 수행해야 하지만 결과는 충돌 감지에 도움이 된다. 이는 그룹 복제에 대한 요구 사항이며 새로운 기본값을 사용하면 소스에서 바이너리 로그 쓰기 집합 병렬화를 쉽게 활성화하여 복제 속도를 높일 수 있다.

 

slave_rows_search_algorithms 시스템 변수의 기본값이 INDEX_SCAN, TABLE_SCAN에서 INDEX_SCAN, HASH_SCAN으로 변경되었다. 이 변경 사항은 기본 키 없이 테이블에 변경 사항을 적용하기 위해 복제본 적용자가 수행해야 하는 테이블 검색 횟수를 줄여 행 기반 복제 속도를 높인다.

 

slave_pending_jobs_size_max 시스템 변수의 기본값이 16M에서 128M으로 변경되었다. 이 변경으로 인해 다중 스레드 복제본에 사용할 수 있는 메모리 양이 늘어난다.

 

gtid_executed_compression_기간 시스템 변수의 기본값이 1000에서 0으로 변경되었다. 이 변경으로 인해 mysql.gtid_executed 테이블의 압축은 필요할 때만 암시적으로 발생한다.

 

 

[Group Replication Defaults]

group_replication_autorejoin_tries의 기본값이 0에서 3으로 변경되었다. 즉, 자동 재참여가 기본적으로 활성화되어 있음을 의미한다. 이 시스템 변수는 그룹이 추방되거나 group_replication_unreachable_majority_timeout 설정에 도달하기 전에 그룹의 대다수에 연결할 수 없는 경우 구성원이 그룹에 자동으로 다시 참여하기 위해 시도하는 횟수를 지정한다.

 

group_replication_exit_state_action의 기본값이 ABORT_SERVER에서 READ_ONLY로 변경되었다. 예를 들어 네트워크 오류가 발생한 후 구성원이 그룹을 종료하면 인스턴스가 종료되지 않고 읽기 전용이 된다.

 

group_replication_member_expel_timeout의 기본값이 0에서 5로 변경되었다. 그룹과의 연락이 두절된 것으로 의심되는 구성원은 5초 감지 기간 이후 5초 후에 제명 책임을 지게 된다.

 

innodb_dedicated_server라는 새 옵션의 경우 개발 서버나 개인 랩탑의 경우 ON을 OFF로 설정한다. 그 이유는 사용할 수 있는 모든 메모리를 사용하기 때문에 랩탑 같은 일반적인 공유 환경에서 메모리 부족 문제가 발생할 수 있기 때문이다. 하지만 프로덕션 환경의 경우 innodb_dedicated_server를 ON으로 설정하는 것이 좋다. ON으로 설정하면 다음 InnoDB 변수(명시적으로 지정하지 않은 경우)는 사용 가능한 메모리 innodb_buffer_pool_size, innodb_log_file_size 및 innodb_flush_method를 기반으로 자동 크기 조정된다. 작세한 내용은 아래 링크를 참고한다.

l   Enabling Automatic Configuration for a Dedicated MySQL Server : https://dev.mysql.com/doc/refman/8.0/en/innodb-dedicated-server.html

 

 

 

Conclusion

대부분의 기본값은 개발 및 프로덕션 환경 모두에 적합하지만, 항상 예외는 발생할 수 있기 때문에 각자의 환경에 맞게 기본값을 적절히 수정해서 사용할 수 있도록 한다. MySQL 8.0에는 각 시스템 변수에 대해 가장 최근에 설정된 소스와 해당 값 범위를 보여주는 성능 스키마 Variable_info 테이블이 있다. 이는 구성 변수와 그 값에 대해 알아야 할 모든 것에 대한 SQL 액세스를 제공한다.

 

 

 

[참고자료]

l   Changes in MySQL 8.0 :  https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html

 

 

 

 

 

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

 

MySQL, 업그레이드 고려사항, MySQL8 변경사항