MySQL 8.0.19 릴리스 노트
MySQL 8.0.19 Community Server 릴리스 노트를 한국어로 번역하고, DBA가 참고해야 할 핵심 내용을 함께 정리하였습니다.
DBA를 위한 핵심 내용
MySQL 8.0.19는 복제 보안·운영 안정성, 업그레이드 시 파티션/대소문자 처리, 히스토그램 통계 수집 비용 개선이 DBA 관점의 핵심입니다. 공개 자료 기준으로 8.0.19 자체에 널리 알려진 단일 대형 운영 회귀는 확인하지 못했지만, 후속 보안 공지에서는 8.0.19 이하가 Replication/InnoDB DoS·무결성 영향 취약점의 영향 범위에 포함됩니다. 따라서 신규 구축보다는 상위 패치 릴리스로의 업그레이드 전 단계로 보는 것이 안전합니다. (NVD MySQL 8.0.19 검색)
- 복제 채널에
REQUIRE_ROW_FORMAT이 추가되어 로우 기반 이벤트만 허용할 수 있습니다.PRIVILEGE_CHECKS_USER와 함께 사용하면 임시 테이블 생성,LOAD DATA INFILE등 문 기반 이벤트가 만드는 공격면을 줄일 수 있으며, Group Replication 채널에는 업그레이드 시 자동 적용됩니다. slave_preserve_commit_order=1을 바이너리 로그 없이도 사용할 수 있어 읽기 복제본에서 커밋 순서를 보존하면서 binlog I/O·디스크 비용을 줄일 수 있습니다. 다만 문 기반 복제와 트랜잭션/비트랜잭션 엔진이 섞인 롤백 케이스는 여전히 주의해야 합니다.- Group Replication 내부 세션이
max_connections한도에 포함되지 않게 되어 연결 포화 상태에서 Group Replication 작업 또는 서버가 중단되는 위험이 줄었습니다. Group Replication/복제 TLSv1.3 ciphersuite 설정도 보강되어 보안 정책이 엄격한 환경에서 운영 제어가 쉬워졌습니다. - 파티션 tablespace 파일명 구분자와 파티션 이름이 소문자 기준으로 정리됩니다. 5.7→8.0 업그레이드, Windows/macOS/Linux 간 이동,
lower_case_table_names가 얽힌 환경에서는 사전 백업과 리허설이 필요합니다. - InnoDB 히스토그램 통계 샘플링이 전체 테이블 스캔을 피하도록 개선되어 대형 테이블의
ANALYZE TABLE ... UPDATE HISTOGRAM비용이 줄어듭니다. 통계 갱신 작업을 운영 시간대에 수행하는 환경에서는 체감 효과가 큽니다. - 정수 표시 폭,
YEAR(4),hash_joinoptimizer switch/hint, X Protocol의xplugin네임스페이스 등 사용 중단·제거 항목이 있습니다. 스키마 비교 도구, ORM, 모니터링 쿼리, X DevAPI 클라이언트 호환성을 점검해야 합니다.
계정 관리 관련 사항
- MySQL은 이제 잘못된 비밀번호로 인해 연속 로그인 실패가 너무 많이 발생하면 임시 계정 잠금이 발생하도록 관리자가 사용자 계정을 설정할 수 있게 합니다. 필요한 실패 횟수와 잠금 시간은
CREATE USER및ALTER USER문장의FAILED_LOGIN_ATTEMPTS및PASSWORD_LOCK_TIME옵션을 사용하여 계정별로 설정할 수 있습니다. Password Management를 참조하십시오. (Bug #27733694, Bug #90169, WL #13515)
Audit Log 관련 사항
ANALYZE TABLE문은 이제readaudit 이벤트를 생성합니다. (Bug #29625461)- Audit log 연결 이벤트는 이제 클라이언트가 전달한 모든 연결 속성을 포함합니다. 연결 속성 로깅은 새 스타일 XML 로그 파일 형식 및 JSON 형식에서 지원되지만, 이전 스타일 XML 형식에서는 지원되지 않습니다. Audit Log File Formats를 참조하십시오. (WL #11378)
컴파일 관련 사항
- Microsoft Windows: Windows에서 명령줄로 빌드할 때 CMake의 최소 버전은 이제 3.15입니다. (Bug #30332632, Bug #96954)
-DMYSQL_MAINTAINER_MODE는 이제 GCC의 경우-Wshadow=local, Clang의 경우-Wshadow-uncaptured-local을 포함합니다. (Bug #30099556)
설정 관련 사항
-
GCC에서 프로파일 기반 최적화(PGO)를 실험하기 위한 새로운
FPROFILE_GENERATE및FPROFILE_USECMake 옵션을 사용할 수 있습니다. 사용 방법에 대한 정보는 MySQL 소스 배포판의cmake/fprofile.cmake를 참조하십시오. 이러한 옵션은 GCC 8 및 9, 그리고 Clang에서 테스트되었습니다.FPROFILE_USE를 활성화하면WITH_LTO(링크 시간 최적화)도 활성화됩니다. (Bug #30089834, Bug #96314, Bug #30133324, Bug #96410, Bug #30164113, Bug #96486) -
시스템이 생성한 스키마에 속하는
InnoDB테이블의 로우 작업을 계산하기 위해Innodb_system_rows_read,Innodb_system_rows_inserted,Innodb_system_rows_deleted상태 변수가 추가되었습니다. 새로운 상태 변수는 기존Innodb_rows_read,Innodb_rows_inserted,Innodb_rows_deleted상태 변수와 유사하며, 기존 상태 변수는 사용자가 생성한 스키마와 시스템이 생성한 스키마 모두에 속하는InnoDB테이블의 작업을 계산합니다.새로운 상태 변수는
relay_log_info_repository및master_info_repository변수가TABLE로 설정된 복제 환경에서 유용하며, 이 경우 시스템이 생성한mysql스키마에 속하는slave_master_info,slave_replay_log_info,slave_worker_info테이블에서 수행되는 작업으로 인해 슬레이브의 로우 작업 수가 더 높아집니다. 마스터와 슬레이브의 로우 작업 수를 유효하게 비교하기 위해, 이제 새로운 상태 변수가 제공하는 계산 데이터를 사용하여 시스템이 생성한 스키마의 테이블에 대한 작업을 제외할 수 있습니다.기여해 주신 Facebook에 감사드립니다. (Bug #27724674, Bug #90148)
사용 중단 및 제거 관련 사항
-
thread_pool플러그인은 Performance Schema 테이블의 정수 컬럼 정의에서 표시 폭을 사용했습니다. 이로 인해 정수 컬럼 표시 폭이 이제 사용 중단되었기 때문에 오류 로그에 경고가 기록되었습니다. (Bug #30597673) -
정수 데이터 타입에 대한 표시 폭 지정은 MySQL 8.0.17에서 사용 중단되었으며, 이제 출력에 데이터 타입 정의를 포함하는 명령문은 다음 예외를 제외하고 정수 타입에 대한 표시 폭을 더 이상 표시하지 않습니다:
- 타입이
TINYINT(1)입니다. MySQL Connectors는TINYINT(1)컬럼이BOOLEAN컬럼에서 비롯되었다고 가정합니다. 이 예외를 통해 해당 가정을 계속 유지할 수 있습니다. - 타입에
ZEROFILL속성이 포함되어 있습니다.
이 변경 사항은 테이블, 뷰, 저장 루틴에 적용되며,
SHOW CREATE및DESCRIBE명령문의 출력과INFORMATION_SCHEMA테이블의 출력에 영향을 줍니다.DESCRIBE명령문 및INFORMATION_SCHEMA쿼리의 경우, 이전 MySQL 8.0 버전에서 생성된 객체에 대해서는 데이터 딕셔너리에 이미 저장된 정보가 변경되지 않으므로 출력이 영향을 받지 않습니다. 이 예외는 MySQL 5.7에서 8.0으로의 업그레이드에는 적용되지 않으며, 이 경우 모든 데이터 딕셔너리 정보가 다시 생성되어 데이터 타입 정의에 표시 폭이 포함되지 않습니다. (Bug #30556657, Bug #97680, WL #13528) - 타입이
-
hash_joinOptimizer 스위치(optimizer_switch시스템 변수 참조)를 설정해도 더 이상 효과가 없습니다.HASH_JOIN및NO_HASH_JOINOptimizer 힌트에도 동일하게 적용됩니다. Optimizer 스위치와 Optimizer 힌트는 이제 모두 사용 중단되었으며, MySQL의 향후 릴리스에서 제거될 수 있습니다.또한 이 변경 사항은
SELECT DISTINCT... WITH ROLLUP이 항상 모든 고유 로우를 반환하지는 않던 문제도 수정합니다. (Bug #27549694, Bug #30471809) -
MySQL 5.7.14에서 X Protocol의
StmtExecute요청을 위해mysqlx네임스페이스 파라미터가 도입되어xplugin파라미터를 대체했으며, 이에 따라xplugin파라미터는 사용 중단되었습니다. X 플러그인은 하위 호환성을 위해 사용 중단된xplugin네임스페이스를 계속 지원했습니다. MySQL 8.0.19에서는 이제xplugin네임스페이스가 제거되었습니다. 이 릴리스부터xplugin네임스페이스를 사용하면 알 수 없는 네임스페이스의 경우와 같이 오류 메시지가 반환됩니다.xplugin네임스페이스에 대해 수신된StmtExecute요청 수를 계산하던 X 플러그인의Mysqlx_stmt_execute_xplugin상태 변수는 MySQL 8.0.19부터 더 이상 사용되지 않습니다. (WL #13057) -
YEAR(2)데이터 타입에 대한 지원은 MySQL 5.7.5에서 제거되어, 연도 값 데이터에 대한 유효한 명세로YEAR및YEAR(4)만 남았습니다.YEAR와YEAR(4)는 의미상 동일하므로 표시 너비를 지정할 필요가 없기 때문에, 이제YEAR(4)는 사용 중단되었으며 이에 대한 지원은 향후 MySQL 버전에서 제거될 예정입니다. 출력에 데이터 타입 정의를 포함하는 문은 더 이상YEAR에 대한 표시 너비를 표시하지 않습니다. 이 변경 사항은 테이블, 뷰 및 저장 루틴에 적용되며,SHOW CREATE및DESCRIBE문의 출력과INFORMATION_SCHEMA테이블의 출력에 영향을 줍니다.DESCRIBE문 및INFORMATION_SCHEMA쿼리의 경우, 이전 MySQL 8.0 버전에서 생성된 객체에 대해서는 이미 데이터 딕셔너리에 저장된 정보가 변경되지 않기 때문에 출력이 영향을 받지 않습니다. 이 예외는 MySQL 5.7에서 8.0으로 업그레이드하는 경우에는 적용되지 않으며, 이 경우 모든 데이터 딕셔너리 정보가 다시 생성되어 데이터 타입 정의에 표시 너비가 포함되지 않습니다.YEAR에 대한 (문서화되지 않은)UNSIGNED속성도 이제 사용 중단되었으며, 이에 대한 지원은 향후 MySQL 버전에서 제거될 예정입니다. (WL #13537)
오류 처리
- XA에 대한 크래시 복구와 관련된 오류 메시지는 비-XA 크래시 복구 메시지와 구분되도록 XA 컨텍스트를 나타내기 위해 수정되었습니다. (Bug #30578290, Bug #97743)
- 이전에는
LOCAL기능이 비활성화된 상태에서LOAD DATA LOCAL을 사용하려고 하면 서버가 다음 오류 메시지를 반환했습니다: The used command is not allowed with this MySQL version. 이는 오류 조건이 MySQL 버전과 관련이 없기 때문에 오해의 소지가 있었습니다. 이제 서버는ER_CLIENT_LOCAL_FILES_DISABLED오류 코드와 다음 메시지를 반환합니다: Loading local data is disabled; this must be enabled on both the client and server side. (Bug #30375698, Bug #29377985, Bug #94396)
SQL 함수 및 연산자 관련 사항
-
이전에는 로드 가능 함수가 문자열 인수 또는 반환 값의 캐릭터셋이나 콜레이션을 고려하지 않았습니다. 결과적으로 문자열 인수와 반환 값은 바이너리 문자열로 처리되었으며, 이는 단일 바이트 문자를 포함하는 문자열 인수만 안정적으로 처리될 수 있음을 의미했습니다.
로드 가능 함수의 동작은 기본적으로 여전히 동일하지만, 로드 가능 함수를 작성하기 위한 인터페이스가 확장되어 문자열 인수의 캐릭터셋과 콜레이션을 확인하고, 특정 캐릭터셋과 콜레이션을 가진 문자열을 반환할 수 있게 되었습니다. 이러한 기능은 로드 가능 함수 작성자에게 선택 사항이며, 원하는 경우 이를 활용할 수 있습니다. Loadable Function Character Set Handling을 참조하십시오.
MySQL과 함께 배포되는 로드 가능 함수 중 다음 기능 및 확장과 관련된 함수는 새로운 기능을 활용하도록 수정되었습니다: MySQL Enterprise Audit, MySQL Enterprise Firewall, MySQL Enterprise Data Masking and De-Identification, MySQL Keyring(범용 keyring 함수만 해당), 그리고 Group Replication. 이 수정은 의미가 있는 경우에만 적용됩니다. 예를 들어 암호화된 데이터를 반환하는 함수는 문자 문자열이 아니라 바이너리 문자열을 반환하도록 의도된 것입니다.
로드 가능 함수의 캐릭터셋 기능은
mysql_udf_metadata컴포넌트 서비스를 사용하여 구현됩니다. 이 서비스에 대한 정보는 https://dev.mysql.com/doc/index-other.html 에서 제공되는 MySQL Server Doxygen 문서를 참조하십시오(s_mysql_mysql_udf_metadata및udf_metadata_imp를 검색하십시오). MySQL Keyring 함수의 소스 코드는 Community 소스 배포판에서 사용할 수 있으며, 자신의 함수를 캐릭터셋 인식 가능하도록 수정하려는 서드파티 로드 가능 함수 작성자를 위한 예제로 검토할 수 있습니다. (WL #12370)
INFORMATION_SCHEMA 관련 사항
-
INFORMATION_SCHEMA에는 역할 정보를 노출하는 몇 가지 새로운 테이블이 포함됩니다:ADMINISTRABLE_ROLE_AUTHORIZATIONS: 현재 사용자가 부여할 수 있는 역할입니다. The INFORMATION_SCHEMA ADMINISTRABLE_ROLE_AUTHORIZATIONS Table을 참조하십시오.APPLICABLE_ROLES: 현재 사용자에게 적용 가능한 역할입니다. The INFORMATION_SCHEMA APPLICABLE_ROLES Table을 참조하십시오.ENABLED_ROLES: 현재 세션 내에서 활성화된 역할입니다. The INFORMATION_SCHEMA ENABLED_ROLES Table을 참조하십시오.ROLE_COLUMN_GRANTS: 현재 사용자에 대한 역할의 컬럼 권한입니다. The INFORMATION_SCHEMA ROLE_COLUMN_GRANTS Table을 참조하십시오.ROLE_ROUTINE_GRANTS: 현재 사용자에 대한 역할의 루틴 권한입니다. The INFORMATION_SCHEMA ROLE_ROUTINE_GRANTS Table을 참조하십시오.ROLE_TABLE_GRANTS: 현재 사용자에 대한 역할의 테이블 권한입니다. The INFORMATION_SCHEMA ROLE_TABLE_GRANTS Table을 참조하십시오.
(WL #10895)
Keyring 관련 사항
- MySQL keyring을 사용하여 민감한 데이터를 범용으로 저장하기 위한 새로운
SECRET키 타입을 사용할 수 있습니다. keyring은SECRET데이터를 저장 및 검색할 때 바이트 스트림으로 암호화하고 복호화합니다.SECRET키 타입은 모든 keyring 플러그인에서 지원됩니다. Supported Keyring Key Types and Lengths를 참조하십시오. (WL #12859)
로깅 관련 사항
- 이제
SIGUSR1신호는 서버가 오류 로그, 일반 쿼리 로그 및 느린 쿼리 로그를 플러시하도록 합니다.SIGUSR1의 한 가지 용도는 서버에 연결하지 않고 로그 순환을 구현하는 것입니다(로그를 플러시하려면RELOAD권한이 있는 계정이 필요합니다).SIGUSR1에 대한 서버 응답은SIGHUP에 대한 응답의 하위 집합이므로,SIGUSR1은 스레드 및 호스트 캐시 플러시와 오류 로그에 상태 보고서 쓰기 같은 다른SIGHUP효과 없이 특정 로그를 플러시하는 더 “가벼운” 신호로 사용할 수 있습니다. Unix Signal Handling in MySQL을 참조하십시오. (WL #13689)
패키징 관련 사항
- 시스템
curl라이브러리에 링크하지 않고curl을 포함하는 바이너리 패키지는curl7.66.0을 사용하도록 업그레이드되었습니다. (Bug #30356844) - MySQL에 번들로 포함된
zstd라이브러리가 버전 1.3.3에서 1.4.3으로 업그레이드되었습니다. MySQL은 연결 압축을 지원하기 위해zstd라이브러리를 사용합니다. (Bug #30236685) - OpenSSL 공유 라이브러리가 포함되는 패키지 유형의 경우, 패키지에 OpenSSL이 필요한 MySQL 전용 라이브러리가 해당 위치에 있으면 이제
lib/private아래에도 포함됩니다. (Bug #29966296)
SQL 문법 관련 사항
-
중요한 변경: MySQL은 이제 SQL 표준에 따라 명시적 테이블 절과 테이블 값 생성자를 지원합니다. 이들은 이제 각각
TABLE문과VALUES문으로 구현되었으며, 각각을 여기에서 간략히 설명합니다:-
TABLE table_name은SELECT * FROM table_name과 동일하며, 동일한SELECT문이 허용되는 모든 위치에서 사용할 수 있습니다. 여기에는 조인, 유니언,INSERT... SELECT문,REPLACE문,CREATE TABLE... SELECT문, 그리고 서브쿼리가 포함됩니다.TABLE과 함께ORDER BY를 사용할 수 있으며,TABLE은 선택적OFFSET이 있는LIMIT도 지원합니다. 이러한 절은SELECT에서와 같은 방식으로TABLE문에서 동작합니다. 다음 두 문은 같은 결과를 생성합니다:TABLE t ORDER BY c LIMIT 10 OFFSET 3; SELECT * FROM t ORDER BY c LIMIT 10 OFFSET 3; -
VALUES는VALUES키워드 뒤에 쉼표로 구분된 일련의 로우 생성자(ROW())가 오는 형태로 구성됩니다. 이는 SQL 준수 방식으로INSERT문 또는REPLACE문에 로우 값을 제공하는 데 사용할 수 있습니다. 예를 들어, 다음 두 문은 동일합니다:INSERT INTO t1 VALUES ROW(1,2,3), ROW(4,5,6), ROW(7,8,9); INSERT INTO t1 VALUES (1,2,3), (4,5,6), (7,8,9);또한 테이블에서 선택하는 것과 마찬가지로
VALUES테이블 값 생성자에서 선택할 수 있으며, 이때 테이블 별칭을 제공해야 한다는 점을 유의해야 합니다. 컬럼 별칭을 사용하여 다음과 같이 개별 컬럼을 선택할 수도 있습니다:mysql> SELECT a,c FROM (VALUES ROW(1,2,3), ROW(4,5,6)) AS t(a,b,c); +---+---+ | a | c | +---+---+ | 1 | 3 | | 4 | 6 | +---+---+이러한
SELECT문은 일반적으로 이러한 문을 사용할 수 있을 것으로 기대되는 조인, 유니온, 서브쿼리 및 기타 구문에서 사용할 수 있습니다.
자세한 정보와 예시는 TABLE Statement, VALUES Statement, 그리고 INSERT... SELECT Statement, CREATE TABLE... SELECT Statement, JOIN Clause, UNION Clause, Subqueries를 참조하십시오. (Bug #77639, WL #10358)
-
-
이전에는 재귀 공통 테이블 표현식(CTE)의 재귀
SELECT부분에서LIMIT을 사용할 수 없었습니다. 이제 이러한 경우 선택적OFFSET절과 함께LIMIT이 지원됩니다. 이러한 재귀 CTE의 예시는 다음과 같습니다:WITH RECURSIVE cte AS ( SELECT CAST("x" AS CHAR(100)) AS a FROM DUAL UNION ALL SELECT CONCAT("x",cte.a) FROM cte WHERE LENGTH(cte.a) < 10 LIMIT 3 OFFSET 2 ) SELECT * FROM cte;이 문은 mysql 클라이언트에서 다음 출력을 생성합니다:
+-------+ | a | +-------+ | xxx | | xxxx | | xxxxx | +-------+이러한 방식으로
LIMIT을 지정하면 요청된 로우 수만 생성되므로, 가장 바깥쪽SELECT에서 그렇게 하는 것보다 CTE 실행을 더 효율적으로 만들 수 있습니다.자세한 정보는 Recursive Common Table Expressions를 참조하십시오. (Bug #92857, Bug #28816906, WL #12534)
-
MySQL 8.0.16에서
CHECK제약 조건이 구현되었을 때,ALTER TABLE은 체크 제약 조건을 수정하기 위한 표준 SQL에 대한 MySQL 확장으로DROP CHECK및ALTER CHECK문법을 지원했지만, 모든 유형의 기존 제약 조건을 수정하기 위한 더 일반적인(그리고 SQL 표준인)DROP CONSTRAINT및ALTER CONSTRAINT문법은 지원하지 않았습니다. 이제 해당 문법이 지원되며, 제약 조건 유형은 제약 조건 이름에서 결정됩니다. (WL #12787) -
MySQL은 이제 삽입될 로우 및 해당 컬럼에 대해
INSERT INTO... ON DUPLICATE KEY UPDATE문장의VALUES및SET절에서 alias를 지원합니다. 다음과 같은 문장을 고려하십시오:INSERT INTO t VALUES (9,5), (7,7), (11,-1) ON DUPLICATE KEY UPDATE a = a + VALUES(a) - VALUES(b);삽입된 로우에 alias
new를 사용하면, 이제ON DUPLICATE KEY UPDATE절에서 로우 alias를 다시 참조하여 다음과 같이 문장을 다시 작성할 수 있습니다:INSERT INTO t VALUES (9,5), (7,7), (11,-1) AS new ON DUPLICATE KEY UPDATE a = a + new.a - new.b;동일한 로우 alias를 사용하고, 추가로 삽입된 로우의 컬럼에 대해 컬럼 alias
m및n을 사용하면, 여기 표시된 것처럼 로우 alias를 생략하고 컬럼 alias만 사용할 수 있습니다:INSERT INTO t VALUES (9,5), (7,7), (11,-1) AS new(m,n) ON DUPLICATE KEY UPDATE a = a + m - n;로우 alias는 테이블 이름과 달라야 하며, 컬럼 alias는 서로 달라야 합니다.
자세한 정보와 예시는 INSERT... ON DUPLICATE KEY UPDATE Statement를 참조하십시오. (WL #6312)
sys 스키마 관련 사항
-
sys스키마 객체는 더 이상 사용 중단된sys.format_bytes(),sys.format_time(), 및sys.ps_thread_id()저장 함수를 호출하지 않도록 다시 구현되었습니다. 대신, Performance Schema 데이터를 형식화하거나 조회하는 MySQL 8.0.16에서 구현된 동등한 내장 SQL 함수를 호출합니다(Section 32, “Changes in MySQL 8.0.16 (2019-04-25)” 참조).sys.format_bytes(),sys.format_time(), 및sys.ps_thread_id()는 향후 MySQL 버전에서 제거될 예정이므로, 이를 사용하는 애플리케이션은sys함수와 내장 함수 사이의 몇 가지 사소한 차이를 염두에 두고 대신 내장 함수를 사용하도록 조정해야 합니다. Performance Schema Functions를 참조하십시오. (WL #13439)
Thread Pool 관련 사항
- 기본적으로 thread pool 플러그인은 언제든 각 그룹에서 실행 중인 스레드가 최대 하나가 되도록 보장하려고 시도합니다. 기본 알고리즘은 정체된 스레드를 고려하며, 일시적으로 더 많은 활성 스레드를 허용할 수 있습니다. 이제 플러그인은 그룹당 활성 스레드 수를 제어하기 위한 새로운
thread_pool_max_active_query_threads시스템 변수를 구현합니다.thread_pool_max_active_query_threads가 0이면 기본 알고리즘이 적용됩니다.thread_pool_max_active_query_threads가 0보다 크면 그룹당 활성 스레드 수에 제한을 둡니다. Thread Pool Operation을 참조하십시오. (WL #12915)
X 플러그인 관련 사항
- X Plugin은 GCC 9를 사용하는 Debian에서 컴파일할 수 없었습니다. 이 문제에 대한 우회 방법을 제공하기 위해
--no-as-needed링커 옵션이 추가되었습니다. (Bug #30445201) - X Protocol을 사용하여 Information Schema 테이블
TRIGGERS를 쿼리하면 오류가 반환되거나 일부 로우가 반환되지 않을 수 있었습니다. (Bug #30318917)
추가되거나 변경된 기능
-
Group Replication: 복제 슬레이브에 대한 복제 연결과 분산 복구를 위한 Group Replication 연결은 이제 TLSv1.3 프로토콜에 대한 전체 클라이언트 측 설정 옵션을 가집니다. TLSv1.3 지원은 사용할 수 있었지만 이러한 설정 옵션은 사용할 수 없었던 MySQL 릴리스에서, 이러한 연결 유형에 TLSv1.3이 사용된 경우 연결의 클라이언트(복제 슬레이브 또는 분산 복구를 시작한 참여 Group Replication 멤버)를 설정할 수 없었습니다. 이는 연결의 서버(복제 마스터 또는 분산 복구의 제공자였던 기존 Group Replication 멤버)가 기본적으로 활성화된 TLSv1.3 ciphersuite 중 적어도 하나의 사용을 허용해야 했음을 의미했습니다. MySQL 8.0.19부터 이러한 연결에 대해 원하는 경우 기본이 아닌 ciphersuite만 포함하여 임의로 선택한 ciphersuite를 지정하는 데 설정 옵션을 사용할 수 있습니다.
새 설정 옵션은 다음과 같습니다:
- Group Replication 시스템 변수
group_replication_recovery_tls_version및group_replication_recovery_tls_ciphersuites.group_replication_recovery_tls_version은 분산 복구 연결에서 클라이언트 인스턴스(참여 멤버)의 연결 암호화를 위해 허용되는 TLS 프로토콜 목록을 지정합니다.group_replication_recovery_tls_ciphersuites는 해당 연결에 TLSv1.3이 사용될 때 허용되는 ciphersuite 목록을 지정합니다. CHANGE MASTER TO명령의MASTER_TLS_CIPHERSUITES옵션으로, 복제 마스터에 대한 연결을 위해 복제 슬레이브가 허용하는 TLSv1.3 ciphersuite 목록을 지정합니다. (CHANGE MASTER TO명령에는 이미 해당 연결에 허용되는 TLS 프로토콜 버전을 지정하는MASTER_TLS_VERSION옵션이 있었습니다.)
(Bug #29960735, WL #13392)
- Group Replication 시스템 변수
-
Group Replication: Group Replication 플러그인은 SQL API 작업을 수행하기 위해 내부 세션을 사용하여 MySQL Server와 상호 작용합니다. 이전에는 이러한 세션이
max_connections서버 시스템 변수로 지정된 클라이언트 연결 제한에 포함되었습니다. Group Replication이 시작되거나 작업 수행을 시도할 때 서버가 이 제한에 도달한 상태이면, 해당 작업은 성공하지 못했고 Group Replication 또는 서버 자체가 중지될 수 있었습니다. MySQL 8.0.19부터 MySQL Server와의 Group Replication 상호 작용은 내부 세션을 별도로 처리하는 새로운 컴포넌트 서비스를 사용하며, 이는 해당 세션이max_connections제한에 포함되지 않고 서버가 이 제한에 도달한 경우에도 거부되지 않음을 의미합니다. (Bug #29635001, WL #13378) -
Microsoft Windows: 이전에는 mysql 명령줄 클라이언트의
system(\!) 명령이 Unix 시스템에서만 작동했습니다. 이제 Windows에서도 작동합니다. 예를 들어,system cls또는\! cls를 사용하여 화면을 지울 수 있습니다. (Bug #11765690, Bug #58680, WL #13391) -
JSON: 하나 이상의 JSON 컬럼을 포함하는 테이블에
CHECK제약 조건을 지정하기 위해JSON_SCHEMA_VALID()를 사용하고 유효성 검사 실패가 발생하는 경우, MySQL은 이제 이러한 실패의 이유에 대한 자세한 정보를 제공합니다. 이 정보를 포함하는 새로운 오류ER_JSON_SCHEMA_VALIDATION_ERROR_WITH_DETAILED_REPORT가 구현되었으며,INSERT문이 서버에 의해 거부될 때SHOW WARNINGS를 실행하여 mysql 클라이언트에서 확인할 수 있습니다.자세한 정보와 예시는 JSON_SCHEMA_VALID() and CHECK constraints를 참조하십시오. 더 일반적인 정보는 CHECK Constraints도 참조하십시오. (WL #13195)
-
Debian 패키지는 이제 수동 mysqld 실행을 더 잘 지원하는 보다 일반적인 systemd 지원을 포함합니다. (Bug #29702050, Bug #95163)
-
중복 키 오류 정보가 키의 테이블 이름을 포함하도록 확장되었습니다. 이전에는 중복 키 오류 정보에 키 값과 키 이름만 포함되었습니다. 기여해 주신 Facebook에 감사드립니다. (Bug #28686224, Bug #925308, WL #12589)
-
mysql 클라이언트가 대화형 모드에서 동작할 때, 이제
--binary-as-hex옵션이 기본적으로 활성화됩니다. 또한 옵션이 암시적으로 또는 명시적으로 활성화된 경우status(또는\s) 명령의 출력에는 다음 라인이 포함됩니다:Binary data as: Hexadecimal16진수 표기법을 비활성화하려면
--skip-binary-as-hex를 사용하십시오. (Bug #24432545, WL #13038) -
MySQL은 이제
'2019-12-11 10:40:30-05:00','2003-04-14 03:30:00+10:00','2020-01-01 15:35:45+05:30'같은 시간대 오프셋이 있는 datetime 리터럴을 지원합니다. 이러한 오프셋은 해당 값을TIMESTAMP및DATETIME컬럼에 삽입할 때 적용되지만 저장되지는 않습니다. 즉, 값을 조회할 때 오프셋은 표시되지 않습니다.시간대 오프셋에 대해 지원되는 범위는
-13:59부터+14:00까지이며 양 끝값을 포함합니다. 특수 값'SYSTEM'을 포함하여'CET'또는'America/Argentina/Buenos_Aires'같은 시간대 이름은 datetime 리터럴에서 지원되지 않습니다. 또한 이 문맥에서는 10보다 작은 시간 값에 선행 0이 필요하며, MySQL은 오프셋'-00:00'을 유효하지 않은 값으로 거부합니다.시간대 오프셋이 있는 datetime 리터럴은 prepared statement에서 파라미터 값으로도 사용할 수 있습니다.
이 작업의 일부로
time_zone시스템 변수에 허용되는 숫자 값 범위가 변경되어, 이제 마찬가지로-13:59부터+14:00까지이며 양 끝값을 포함합니다.추가 정보와 예시는 The DATE, DATETIME, and TIMESTAMP Types 및 MySQL Server Time Zone Support를 참조하십시오. (Bug #83852, Bug #25108148, WL #10828)
-
MySQL 8.0.19부터 X Protocol 연결을 통해 전송되는 메시지에 압축이 지원됩니다. 서버와 클라이언트가 사용할 압축 알고리즘에 동의하면 연결을 압축할 수 있습니다. 기본적으로 X Protocol은
deflate,lz4,zstd압축 알고리즘에 대한 지원을 알립니다. 새mysqlx_compression_algorithms시스템 변수를 허용하는 알고리즘만 포함하도록 설정하여 이러한 알고리즘 중 일부를 허용하지 않을 수 있습니다. 클라이언트가 기능 협상 중에 압축을 요청하지 않으면 X Protocol은 항상 압축되지 않은 연결을 허용합니다. X Protocol의 허용된 압축 알고리즘 목록은 MySQL Server가 알리는 압축 알고리즘 목록과 독립적으로 동작하며, X Protocol은 MySQL Server의 압축 설정을 사용하는 방식으로 폴백하지 않습니다. 새 X Plugin 상태 변수를 사용하여 X Protocol의 메시지 압축 효과를 모니터링할 수 있습니다. (WL #9252, WL #13442) -
멀티스레드 슬레이브(
slave_parallel_workers가 0보다 큰 값으로 설정된 복제 슬레이브)의 경우,slave_preserve_commit_order=1을 설정하면 트랜잭션이 슬레이브의 릴레이 로그에 나타나는 것과 동일한 순서로 슬레이브에서 실행되고 커밋되어, 마스터에서와 동일한 트랜잭션 히스토리가 슬레이브에 보존됩니다. 이전에는 이 설정을 사용하려면 슬레이브에서 바이너리 로깅과 슬레이브 업데이트 로깅을 활성화해야 했으며, 관련 실행 비용과 디스크 공간 요구 사항이 있었습니다. 이제slave_preserve_commit_order=1을 바이너리 로그와 슬레이브 업데이트 로깅이 없는 슬레이브에 설정할 수 있습니다. 이를 통해 바이너리 로깅의 오버헤드 없이 슬레이브에서 커밋 순서를 보존하고 트랜잭션 시퀀스의 간격을 방지할 수 있습니다.문 기반 복제가 사용 중이고, 마스터에서 롤백되는 non-XA 트랜잭션에 트랜잭션 스토리지 엔진과 비트랜잭션 스토리지 엔진이 모두 참여하는 경우 슬레이브에서 커밋 순서를 보존하는 데 제한이 발생할 수 있습니다. 일반적으로 마스터에서 롤백되는 non-XA 트랜잭션은 슬레이브로 복제되지 않지만, 이 특정 상황에서는 해당 트랜잭션이 슬레이브로 복제될 수 있습니다. 이 경우 바이너리 로깅이 없는 멀티스레드 슬레이브는 트랜잭션 롤백을 처리하지 않으므로, 이 경우 슬레이브의 커밋 순서가 트랜잭션의 릴레이 로그 순서와 달라집니다. (WL #7846)
-
MySQL 8.0.18 릴리스에는 복제된 트랜잭션이 적용될 때 MySQL이 권한 검사를 수행할 대상인
PRIVILEGE_CHECKS_USER계정을 복제 채널에 지정하는 기능이 도입되었습니다(CHANGE MASTER TO문 사용).PRIVILEGE_CHECKS_USER계정을 사용하면 권한이 있는 작업 또는 원치 않는 작업의 무단 사용이나 우발적 사용으로부터 복제 채널을 보호하는 데 도움이 됩니다. 복제 채널이 권한 검사로 보호되는 경우 로우 기반 바이너리 로깅 사용을 강력히 권장합니다.MySQL 8.0.19에서는 복제 채널에 대한 새 설정
REQUIRE_ROW_FORMAT이 추가되었으며, 이 설정은 채널이 로우 기반 복제 이벤트만 허용하도록 합니다. 권한 검사로 보호되는 복제 채널에 로우 기반 바이너리 로깅을 강제하거나, 이러한 방식으로 보호되지 않는 채널의 보안을 강화하기 위해CHANGE MASTER TO문을 사용하여REQUIRE_ROW_FORMAT을 지정할 수 있습니다.REQUIRE_ROW_FORMAT은 로우 기반 복제 이벤트만 허용함으로써 복제 어플라이어가 임시 테이블 생성 및LOAD DATA INFILE요청 실행과 같은 작업을 수행하지 못하게 하며, 이는 일부 알려진 공격 벡터로부터 복제 채널을 보호합니다.REQUIRE_ROW_FORMAT이 설정된 경우 복제 마스터에서 로우 기반 바이너리 로깅(binlog_format=ROW)을 사용해야 합니다.Group Replication은 이미 로우 기반 바이너리 로깅을 요구하므로, MySQL 8.0.19부터 Group Replication 채널은
REQUIRE_ROW_FORMAT이 설정된 상태로 자동 생성되며, 해당 채널에 대해 이 옵션을 변경할 수 없습니다. 또한 이 설정은 업그레이드 시 모든 Group Replication 채널에 적용됩니다.mysqlbinlog에는 mysqlbinlog의 출력에 대해 로우 기반 복제 이벤트를 강제하는 새
--require-row-format옵션이 있습니다. 이 옵션으로 생성된 이벤트 스트림은REQUIRE_ROW_FORMAT옵션을 사용하여 보호되는 복제 채널에서 허용됩니다. (WL #12968) -
MySQL은 테이블 파티션의 테이블스페이스 이름과 파일 이름을 구성할 때 구분자 문자열을 사용합니다. “
#p#” 구분자 문자열은 파티션 이름 앞에 오고, “#sp#” 구분자 문자열은 다음과 같이 서브파티션 이름 앞에 옵니다:schema_name.table_name#p#partition_name#sp#subpartition_name table_name#p#partition_name#sp#subpartition_name.ibd역사적으로 구분자 문자열은 Linux와 같은 대소문자 구분 파일 시스템에서는 대문자(
#P#및#SP#)였고, Windows와 같은 대소문자 비구분 파일 시스템에서는 소문자(#p#및#sp#)였습니다. 대소문자 구분 파일 시스템과 대소문자 비구분 파일 시스템 간에 데이터 디렉터리를 마이그레이션할 때 발생하는 문제를 방지하기 위해, 이제 구분자 문자열은 모든 파일 시스템에서 소문자입니다. 대문자 구분자 문자열은 더 이상 사용되지 않습니다.또한 대문자 또는 소문자로 지정할 수 있는 사용자 지정 파티션 또는 서브파티션 이름을 기반으로 생성되는 파티션 테이블스페이스 이름과 파일 이름은 이제 대소문자 비구분을 보장하기 위해
lower_case_table_names설정과 관계없이 소문자로 생성되고 내부적으로 저장됩니다. 예를 들어 테이블 파티션이PART_1이라는 이름으로 생성되면, 테이블스페이스 이름과 파일 이름은 소문자로 생성됩니다:schema_name.table_name#p#part_1 table_name#p#part_1.ibd업그레이드 중에 MySQL은 이제 필요한 경우 다음을 확인하고 수정합니다:
- 소문자 구분자와 파티션 이름을 보장하기 위해 디스크와 데이터 딕셔너리의 파티션 파일 이름.
- 이전 버그 수정으로 인해 도입된 관련 문제에 대한 데이터 딕셔너리의 파티션 메타데이터.
- 이전 버그 수정으로 인해 도입된 관련 문제에 대한
InnoDB통계 데이터.
테이블스페이스 임포트 작업 중에는 소문자 구분자와 파티션 이름을 보장하기 위해 디스크의 파티션 테이블스페이스 파일 이름이 확인되고 필요한 경우 수정됩니다. (WL #13352)
참조: 다음도 참조하십시오: Bug #26925260, Bug #29823032, Bug #30012621, Bug #29426720, Bug #30024653.
-
히스토그램 통계 생성을 목적으로
InnoDB데이터를 효율적으로 샘플링하는 지원이 추가되었습니다. 스토리지 엔진이 자체 구현을 제공하지 않을 때 MySQL에서 사용하는 기본 샘플링 구현은 전체 테이블 스캔이 필요하며, 이는 큰 테이블에서 비용이 많이 듭니다.InnoDB샘플링 구현은 전체 테이블 스캔을 피하여 샘플링 성능을 향상시킵니다.sampled_pages_read및sampled_pages_skippedINNODB_METRICS카운터를 사용하여InnoDB데이터 페이지의 샘플링을 모니터링할 수 있습니다. Histogram Statistics Analysis를 참조하십시오. (WL #8777)
수정된 버그
-
중요한 변경: 다음 문자열 함수에 대해 캐릭터셋 해석이 변경되었습니다:
REPLACE(str, from_str, to_str)SUBSTRING_INDEX(str, delim, count)TRIM([{BOTH | LEADING | TRAILING} [remstr] FROM] str)
이전에는 이러한 함수에 대한 모든 인수의 캐릭터셋 정보가 집계되었으며, 이로 인해 올바른 형식이 아닌 결과가 발생할 수 있었습니다. 이 동작은 입력과 출력이 모두 올바른 형식이라고 가정하는
LPAD()에서도 문제를 일으켰습니다. 이제 나열된 세 함수는 각각 항상str에서 사용되는 캐릭터셋을 사용하며, 실행 시점에 다른 모든 인수를 이 캐릭터셋으로 변환합니다. 이러한 변환 중 하나라도 실패하면 함수는 오류를 반환합니다. (Bug #30114420)참조: 이 문제는 다음의 회귀입니다: Bug #28197977.
-
중요한 변경: 서브쿼리 구체화는 더 이상 내부 타입과 외부 타입의 엄격한 일치를 요구하지 않습니다. 이제 다음 조건 중 하나가 참이면 서로 다른 타입을 구체화할 수 있습니다:
-
내부 타입은 숫자입니다(외부 타입을 숫자로 캐스트하는 방법이 항상 있기 때문입니다).
- 내부 타입은 시간형입니다(외부 타입을 시간형으로 캐스트하는 방법이 항상 있기 때문입니다).
- 두 타입이 모두 문자열입니다.
(Bug #13960580)
-
NDB Cluster: 일부 NDB 로깅 옵션에 대해 비밀번호 마스킹이 불완전했습니다. (Bug #97335, Bug #30453137)
-
InnoDB: 시작 시 특정 내부 데이터 구조의 초기화는
max_connections설정에서 파생된 내부 변수에 따라 달라집니다.InnoDB는 시작 후SET PERSIST를 사용하여max_connections설정이 수정되었을 때 내부 데이터 구조의 크기를 조정하지 못했습니다. (Bug #30628872) -
InnoDB: GCC 9.2.0으로 MySQL을 컴파일할 때
os_file_get_parent_dir경고가 발생했습니다. (Bug #30499288, Bug #97466) -
InnoDB: null 참조를 사용하여 large object (LOB) 값에 액세스하려고 하면 어설션 실패가 발생했습니다. 이 문제가 발생하지 않도록, LOB 참조에 액세스하기 전에 해당 참조가 null인지 확인하는 검사가 추가되었습니다. (Bug #30499064)
-
InnoDB: 데이터 디렉터리를 업그레이드한 후 assertion failure가 발생했습니다. 준비된 XA 트랜잭션이 여전히 존재했으며, 이로 인해 undo 테이블스페이스가 업그레이드되지 못했습니다. 준비된 트랜잭션 변경 사항을 포함하는 undo 테이블스페이스는 모든 준비된 XA 트랜잭션이 커밋되거나 롤백될 때까지 활성 상태로 유지되어야 합니다.
준비된 XA 트랜잭션은 재시작 후 명시적 undo 테이블스페이스 잘라내기 작업이 완료되는 것도 방해했습니다. (Bug #30489497)
-
InnoDB: Linux에서 대문자 테이블 이름(파티션된 경우 또는 그렇지 않은 경우)을 사용하는 MySQL 5.7 인스턴스를 macOS의 MySQL 8.0으로 업그레이드하려고 하면 assertion failure가 발생했습니다. MySQL 8.0의 파티션 파일 형식 변경으로 인해 데이터 디렉터리를 다른 플랫폼으로 마이그레이션할 수 없었으며, 업그레이드 시점에
lower_case_table_names설정이 변경되어 업그레이드 실패가 발생할 수 있었습니다. 이제 이러한 상황에서 실패가 발생하는 대신 오류가 보고됩니다. (Bug #30450968, Bug #30450979) -
InnoDB: macOS에서 대문자 테이블 이름을 사용하는 MySQL 5.7 인스턴스를 MySQL 8.0으로 업그레이드하려고 할 때 실패가 발생했습니다. 대문자 테이블 이름이 소문자로 정규화되지 않았습니다. 다음 오류가 보고되었습니다: Table is not found in InnoDB dictionary 및 Error in fixing SE data errors. (Bug #30450944)
-
InnoDB: Windows에서 대문자 파티션된 테이블 이름이 있는 MySQL 5.7 인스턴스를 MySQL 8.0으로 업그레이드하려고 할 때 실패가 발생했습니다. 테이블을 열면 null 포인터가 반환되었고, 이로 인해 테이블을 닫을 때 세그멘테이션 오류가 발생했습니다. (Bug #30450918)
-
InnoDB: Windows에서 대문자 파티션된 테이블 이름이 있는 MySQL 5.7 인스턴스를 MySQL 8.0으로 업그레이드하려고 할 때 mysqld 예외가 발생했습니다. (Bug #30447790)
-
InnoDB: Windows에서 대문자 이름으로 정의된 general tablespace가 포함된 MySQL 5.7 인스턴스를 MySQL 8.0으로 업그레이드하려고 할 때 실패가 발생했습니다. 다음 오류가 보고되었습니다: Error in fixing SE data 및 Failed to Populate DD. (Bug #30446798)
-
InnoDB: LOB 관련 코드에 로컬 미니트랜잭션(mtrs)이 도입되어 복구 중 assertion 실패가 발생했습니다. (Bug #30417719)
-
InnoDB: Windows에서 대문자 파티션된 테이블 이름이 있는 MySQL 5.7 인스턴스를 Linux의 MySQL 8.0으로 업그레이드하려고 할 때 실패가 발생했습니다. MySQL 8.0의 파티션 파일 형식 변경으로 인해 데이터 디렉터리를 다른 플랫폼으로 마이그레이션할 수 없었습니다. 이제 실패 대신 오류가 보고됩니다. (Bug #30411118)
-
InnoDB: 동일한 압축 LOB 데이터를 반복적으로 업데이트하면 테이블스페이스 파일 크기가 증가했습니다. (Bug #30353812)
-
InnoDB:
temptable_max_ram한도에 도달했을 때 TempTable 스토리지 엔진이 디스크 기반 스토리지로 폴백하는 대신 잘못하여 메모리 부족 오류를 보고했습니다. (Bug #30314972, Bug #96893) -
InnoDB: 암호화된 테이블을 임포트하고 서버를 재시작한 후 해당 테이블에 액세스하려고 하면 다음 오류가 반환되었습니다: ERROR 3185 (HY000): Can't find master key from keyring, please check in the server log if a keyring plugin is loaded and initialized successfully. 테이블스페이스 키가 대상 마스터 키로 암호화된 후 디스크에 기록되지 않았습니다. (Bug #30313734)
-
InnoDB: SQL 문을 파싱하고 외래 키 관련 DDL 검사를 수행하던 내부
InnoDBdict_create_foreign_constraints()함수가 제거되었습니다. 이 함수는 MySQL 8.0에서 데이터 딕셔너리가 도입되고 이후 외래 키 관련 DDL 검사가 SQL 계층으로 이동함에 따라 중복된 기능이 되었습니다.dict_create_foreign_constraints()함수 제거는 다음 외래 키 문제도 해결했습니다:- 정규화된 참조 테이블 이름에서 점(“.”) 주변의 공백은
InnoDB파서에서 허용되지 않았습니다.
- 정규화된 참조 테이블 이름에서 점(“.”) 주변의 공백은
-
동일한
ALTER TABLE문에서 외래 키를 추가하고 파티셔닝을 제거하는 것이 허용되지 않았습니다.InnoDB파서는 새 테이블 버전이 더 이상 파티셔닝되지 않았다는 것을 감지하지 못했습니다.- 외래 키 제약 조건이 “AUX”라는 이름의 스키마 안에 있는 테이블을 참조할 수 없었습니다. 참조된 테이블 이름을 파싱하는 함수가 AUX와 같은 특수 이름이 인코딩된다는 것을 인식하지 못했습니다.
- 외래 키 정의의 조건부 주석이 무시되었습니다.
또한
ALTER TABLE문 실행의 초기 단계에서 테이블에 같은 이름의 외래 키를 여러 개 생성하려는 시도를 감지하기 위한 검사가 SQL 계층에 추가되었습니다. (Bug #30287895, Bug #22364336, Bug #28486106, Bug #28703793, Bug #16904122, Bug #92567, Bug #11754659, Bug #46293) -
InnoDB: 공간 인덱스의 비리프 페이지를 병합하려고 할 때 비교 함수가 두 레코드가 같다고 판단했습니다. 이 함수는 이러한 예기치 않은 조건을 처리할 수 없었으며, 그 결과 긴 세마포어 대기와 최종적인 어설션 실패가 발생했습니다. (Bug #30287668)
-
InnoDB: 대형 객체(LOB) 페이지를 해제하는 데 필요한 로컬로 획득된 래치가, 페이지가 해제되기 전에 후속 호출자가 동일한 페이지에 대한 래치 획득을 시도한 경우 교착 상태를 발생시킬 수 있었습니다. 마찬가지로 롤백 관련 작업 중 압축 또는 비압축 LOB에 획득된 래치가 래치 획득 순서 문제로 인해 교착 상태를 발생시킬 수 있었습니다. (Bug #30258536)
참조: 이 문제는 다음의 회귀입니다: Bug #29846292.
-
InnoDB: 압축된 LOB 페이지를 purge하던 purge 스레드와 삭제 표시된 레코드를 사용하는 업데이트 스레드 사이의 경합 조건으로 인해 어설션 실패가 발생했습니다. (Bug #30197056)
-
InnoDB: 소스 및 대상 테이블이 서로 다른
DATA DIRECTORY절로 정의되어 실패한 테이블스페이스 가져오기 작업이 충분히 설명적이지 않은 스키마 불일치 오류를 보고했습니다. 또한.cfg파일이 없으면 동일한 작업에서 어설션 실패가 발생했습니다. 이제 두 경우 모두 데이터 디렉터리 불일치로 인해 가져오기 작업이 종료되기 전에 더 유용한 오류 메시지가 보고됩니다. (Bug #30190199, Bug #30190227, Bug #20644698, Bug #76142) -
InnoDB: 버퍼 풀보다 큰 LOB 값을 purge하려고 할 때 purge 작업이 실패했습니다. (Bug #30183982)
-
InnoDB: 외부에 저장된 LOB 데이터를 인라인 저장소로 이동한 업데이트 작업이 이전 LOB 데이터를 purge 가능으로 표시하지 못했습니다. (Bug #30178056, Bug #96466)
-
InnoDB:
ALTER TABLE... IMPORT TABLESPACE작업에서 사용하는.cfg메타데이터 파일에 인덱스 키 파트 정렬 순서 정보가 저장되지 않았습니다. 따라서 인덱스 키 파트 정렬 순서는 기본값인 오름차순으로 간주되었습니다. 그 결과 가져오기 작업에 관련된 한 테이블이DESC인덱스 키 파트 정렬 순서로 정의되어 있고 다른 테이블은 그렇지 않은 경우, 레코드가 의도하지 않은 순서로 정렬될 수 있었습니다. 이 문제를 해결하기 위해.cfg파일 형식이 인덱스 키 파트 정렬 순서 정보를 포함하도록 업데이트되었습니다. (Bug #30128418) -
InnoDB: 수정되는 레코드에 트리 구조 수정이 필요한지 감지하는
btr_cur_will_modify_tree()함수에서 사용되는 기준이 충분하지 않았습니다. (Bug #30113362) -
InnoDB: 시작 시 스페이스 ID를 가져오기 위해 수행되는 테이블스페이스 파일 스캔으로 인해, 테이블 수가 많은 인스턴스에서 시작이 느렸습니다. 테이블스페이스 파일 수가 50,000개를 초과하는 경우에만 멀티스레드 스캔이 시작되었으며, 스페이스 ID를 가져오기 위해 세 개의 테이블스페이스 페이지를 읽었습니다. 시작 시간을 개선하기 위해 이제 테이블스페이스 파일 스캔에 추가 스레드가 할당되며, 스페이스 ID를 가져오기 위해 첫 번째 테이블스페이스 페이지만 읽습니다. 테이블스페이스의 첫 번째 페이지에서 스페이스 ID를 찾을 수 없는 경우, 이전과 같이 스페이스 ID를 확인하기 위해 세 페이지를 읽습니다. (Bug #30108154, Bug #96340)
-
InnoDB: case-insensitive 파일 시스템에서 동일한 테이블스페이스 ID에 대해 여러 파일이 발견되었음을 나타내는 오류와 함께 시작이 실패했습니다. 파일 경로 비교에서
innodb_data_home_dir및datadir경로가 서로 다른 대소문자를 가지고 있어 동일한 경로임을 인식하지 못했습니다. (Bug #30040815) -
InnoDB: 파티션된 테이블과
lower_case_table_names=1설정이 있는 Linux의 MySQL 8.0.13 인스턴스를 MySQL 8.0.14 또는 MySQL 8.0.15로 업그레이드한 후,mysql.innodb_index_stats및mysql.innodb_table_stats영구 Optimizer 통계 테이블에 접근할 때 스토리지 엔진 오류가 발생했습니다. 영구 Optimizer 통계 테이블에 중복 항목이 포함되어 있었습니다. (Bug #30012621)참조: 이 문제는 다음 버그의 회귀입니다: Bug #26925260.
-
InnoDB:
CREATE TABLESPACE가 테이블스페이스가 이미 존재함을 나타내는 오류와 함께 실패했습니다. 이 오류는 DDL이 실패했지만 트랜잭션 커밋 전에 롤백이 비활성화되어 관련 변경 사항이 롤백되지 않았던 선행CREATE TABLESPACE작업의 실패로 인해 발생했습니다. 이제 트랜잭션이 성공적으로 커밋된 후 롤백이 비활성화됩니다. (Bug #29959193, Bug #95994) -
InnoDB: 가져온 테이블스페이스에 속한 변경된 페이지가 추적되지 않았습니다. (Bug #29917343)
-
InnoDB: case-insensitive 파일 시스템에서 MySQL 5.7에서 MySQL 8.0으로 업그레이드할 때 테이블스페이스 이름 충돌로 인해 업그레이드 중 full-text search 보조 테이블의 이름 변경이 실패했습니다. (Bug #29906115)
-
InnoDB: 버퍼 풀보다 큰 LOB 값을 삽입한
INSERT작업의 롤백으로 인해 데드락이 발생했습니다. (Bug #29846292, Bug #95572) -
InnoDB: 세션 임시 테이블에 대해 불필요한 암시적 secondary 인덱스 잠금을 명시적 secondary 인덱스 잠금으로 변환하는 것을 금지하여 코드 회귀를 해결했습니다. (Bug #29718243)
-
InnoDB: 테이블스페이스 가져오기 작업에서 delete-marked 레코드를 제거하는 동안 커서가 손상된 페이지에 위치하면 assertion이 발생했습니다. 이제 가져오기 작업은 손상된 페이지를 만나면 assertion을 발생시키는 대신 종료되고 오류를 보고합니다. (Bug #29454828, Bug #94541)
-
InnoDB: Delete marked 로우는 부분 롤백이 완료되기 전에 외부 읽기 잠금을 획득할 수 있었습니다. 외부 읽기 잠금은 부분 롤백 중에 암시적 잠금을 명시적 잠금으로 변환하지 못하게 하여 assertion 실패를 발생시켰습니다. (Bug #29195848)
-
InnoDB: undo tablespace truncate 작업이 진행 중일 때 서버 종료가 발생한 후, 시작 시 undo tablespace 페이지에 대해 doublewrite 페이지를 복원할 수 없다는 경고 메시지가 출력되었습니다. truncate 중인 undo tablespace에 대해서는 더 이상 경고 메시지가 출력되지 않습니다. (Bug #28590016)
-
InnoDB: 읽기 전용 모드(
innodb_read_only=ON)에서SHOW CREATE TABLE출력에 외래 키 제약 조건에 대한 정보가 포함되지 않았습니다. (Bug #21966795, Bug #78754) -
Partitioning: MySQL 8.0.16 이하에서 하위 파티셔닝된 테이블이 있는 데이터베이스를 업그레이드한 다음
ALTER TABLE ADD COLUMN을 실행하면 assertion 또는 오류가 발생했습니다. (Bug #30360695, Bug #97054) -
Partitioning: 파티셔닝된 테이블을 MySQL 5.7에서 8.0으로 업그레이드하는 동안, 파티셔닝 함수에서 prefix key를 사용한 경우 prefix 길이가 무시되고 대신 전체 컬럼 길이가 고려되었습니다. 그 결과 파티션 필드 길이가 너무 큰 것으로 확인되어 테이블이 업그레이드 대상에서 잘못 거부될 수 있었습니다. (Bug #29941988, Bug #95921)
-
Partitioning:
ALTER TABLE... EXCHANGE PARTITION으로 인해 인덱스가 손상될 수 있었습니다. 이는 서버가 파티셔닝된 테이블에서 인덱스가 생성되는 순서가 파티셔닝되지 않은 테이블의 순서와 동일하다고 가정했기 때문입니다. 이로 인해 잘못된 인덱스 데이터가 교환되었습니다. (Bug #29706669) -
Replication: 슬레이브의 관련 테이블에 마스터보다 더 많은 컬럼이 있는 경우 복제 채널에 대해 권한 검사가 수행될 때 어설션이 발생했습니다. 이제 이 검사는 테이블 정의의 컬럼 수가 아니라 이벤트의 컬럼 수를 참조합니다. (Bug #30343310)
-
Replication:
mysql.slave_relay_log_info테이블에 보관되는 복제 연결 매개변수는 이제RESET SLAVE를 실행한 후START SLAVE를 실행하기 전에 서버 크래시 또는 의도적인 재시작이 발생하는 경우에도 보존됩니다. 이 동작은 복제 권한 검사를 위한PRIVILEGE_CHECKS_USER계정 설정(MySQL 8.0.18에서 도입됨) 및REQUIRE_ROW_FORMAT설정(MySQL 8.0.19에서 도입됨)에 적용됩니다. 서버에relay_log_info_repository=FILE이 설정되어 있는 경우(기본값이 아니며 사용 중단됨), 이 상황에서는 복제 연결 매개변수가 보존되지 않는다는 점에 유의하십시오. (Bug #30311908) -
Replication: ACL 권한을 가지지 않아야 하는
PRIVILEGE_CHECKS_USER계정을 지정하여 복제 채널이 보호되는 경우, 해당 채널로 복제되는GRANT문으로 인해 복제 적용자가 중지됩니다. 이 상황에서 동작은 올바랐지만 assertion이 발생하고 있었습니다. 이제 해당 assertion은 제거되었습니다. (Bug #30273684) -
Replication: 멀티스레드 복제 슬레이브의 경우, 이제
slave_preserve_commit_order=1을 설정하면 관련 객체가 존재하지 않을 때IF EXISTS절이 있는 구문의 순서가 보존됩니다. 이전에는 이러한 업데이트가 릴레이 로그에서 그보다 앞선 트랜잭션보다 먼저 커밋될 수 있었으며, 이로 인해 슬레이브의 릴레이 로그에서 실행된 트랜잭션 시퀀스에 간격이 생길 수 있었습니다. (Bug #30262096) -
Replication: 복제 채널에 대해 권한 검사가 수행될 때,
sql_require_primary_key시스템 변수의 세션 값을 설정하는 데 필요한 권한이 검사되지 않았습니다. 이제 이 검사가 수행됩니다. (Bug #30254917) -
Replication: 실패한 복제 그룹 멤버가 소수 그룹에 다시 참여하려고 시도했지만 그렇게 하는 것이 허용되지 않았을 때 메모리 누수가 발생할 수 있었습니다. (Bug #30162547, Bug #96471)
-
Replication: 그룹 멤버가 복제 그룹에 다시 조인하면, 이미 그룹에서 수신한 트랜잭션이 있는지 해당
group_replication_applier채널의 릴레이 로그를 확인하고 이를 적용하는 방식으로 분산 복구 프로세스를 시작합니다. 그런 다음 조인하는 멤버는 기존 온라인 멤버로부터 상태 전송을 시작하며, 이는 원격 클로닝 작업으로 시작될 수 있습니다. 이전에는 원격 클로닝 작업이 시작될 때group_replication_applier채널이 명시적으로 중지되지 않았으므로, 그 시점에 applier가 기존 트랜잭션을 계속 적용하고 있을 가능성이 있었고, 이로 인해 오류가 발생할 수 있었습니다. 이제 원격 클로닝 작업이 요청되기 전에group_replication_applier채널이 중지되고, 분산 복구 프로세스가 donor의 바이너리 로그로부터 상태 전송으로 이동할 때 다시 시작됩니다. (Bug #30152028, Bug #96447) -
Replication: 멤버의 XCom 포트가 차단된 동안
STOP GROUP_REPLICATION이 실행되면 XCom 스레드가 중단되고 종료가 완료되지 않았습니다. 이제 이 상황에서는 XCom이 종료됩니다. (Bug #30139794) -
Replication: 슬레이브 상태 로그인
mysql.slave_relay_log_info(릴레이 로그 정보 로그) 및mysql.slave_worker_info(슬레이브 워커 로그)는 이제 로컬 또는 원격 클로닝 작업 중에 도너에서 수신자로 복사됩니다. 슬레이브 상태 로그는 클로닝 작업 후 복제를 올바르게 재개하는 데 사용할 수 있는 정보를 보관하며, 여기에는 복제를 다시 시작할 릴레이 로그 위치,PRIVILEGE_CHECKS_USER계정 설정, 새REQUIRE_ROW_FORMAT설정이 포함됩니다. 릴레이 로그 자체는 도너에서 수신자로 복사되지 않으며, 이러한 테이블에 보관된 릴레이 로그에 대한 정보만 복사된다는 점에 유의하십시오. 또한 서버에서relay_log_info_repository=FILE이 설정된 경우(기본값이 아니며 사용 중단되었습니다) 슬레이브 상태 로그는 클론되지 않으며,TABLE이 설정된 경우에만 클론된다는 점에도 유의하십시오.이 패치 이전에는 클로닝 작업으로 프로비저닝된 복제 슬레이브에서 다음 복제 관련 동작이 발생했습니다:
- 기본 복제 채널이 슬레이브의 유일한 채널인 경우, 릴레이 로그 정보가 누락되어 초기화되지 않은 것으로 간주되었기 때문에 시작에 실패했습니다.
-
공여자에 있는 복제 채널에 적용되었던 모든
PRIVILEGE_CHECKS_USER계정 설정은 없었으며 다시 지정해야 했습니다.MASTER_AUTO_POSITION옵션으로 지정된CHANGE MASTER TO문에서 GTID 자동 위치 지정을 사용한 복제 채널은 복제를 자동으로 재개할 수 있었습니다.CHANGE MASTER TO문에서MASTER_LOG_FILE및MASTER_LOG_POS옵션으로 지정된 바이너리 로그 파일 위치 기반 복제를 사용한 복제 채널은 올바르게 재개하기 위해 복제를 다시 시작하기 전에MASTER_LOG_FILE및MASTER_LOG_POS옵션을 수동으로 다시 적용해야 했습니다. 채널이 서버 시작 시 복제를 자동으로 시작하도록 설정된 경우, 옵션을 다시 적용하지 않으면 처음부터 복제를 시작하려고 시도했습니다. 따라서 클로닝 작업에 의해 이미 슬레이브로 복사된 데이터를 복제하려고 시도할 가능성이 높았으며, 이로 인해 복제가 중지되고 슬레이브의 데이터가 손상될 수 있었습니다.
이 변경으로, 이제 클로닝 작업으로 프로비저닝된 복제 슬레이브에서 다음과 같은 복제 관련 동작이 발생합니다:
-
복제 기본 채널은 이제 그렇게 하도록 설정된 경우 클로닝 작업 후 항상 시작할 수 있습니다.
- 이제 모든 채널은 기증자의
PRIVILEGE_CHECKS_USER계정 설정 및REQUIRE_ROW_FORMAT설정을 가집니다. - GTID 자동 위치 지정을 사용하는 복제 채널(
CHANGE MASTER TO문장의MASTER_AUTO_POSITION옵션으로 지정됨)은 여전히 복제를 자동으로 재개할 수 있습니다. GTID 자동 위치 지정을 사용하는 Group Replication 채널의 경우, 복제가 최적으로 재개되도록 보장하기 위해 이제RESET MASTER문장의 내부 동등 항목이 사용됩니다.
- 이제 모든 채널은 기증자의
-
바이너리 로그 파일 위치 기반 복제를 사용하는 복제 채널은 이제 클론 후 올바른
MASTER_LOG_FILE및MASTER_LOG_POS옵션이 설정됩니다. 릴레이 로그 자체는 클론되지 않으므로, 이제 이러한 채널은 복제를 다시 시작하기 전에 클론된 릴레이 로그 정보를 사용하여 릴레이 로그 복구 프로세스를 수행하려고 시도합니다. 단일 스레드 슬레이브(slave_parallel_workers가 0으로 설정됨)의 경우, 다른 문제가 없으면 릴레이 로그 복구가 성공해야 하며, 이를 통해 채널이 복제를 올바르게 재개할 수 있습니다. 멀티스레드 슬레이브(slave_parallel_workers가 0보다 큼)의 경우, 릴레이 로그 복구는 일반적으로 자동으로 완료될 수 없기 때문에 실패할 가능성이 높지만, 유용한 오류 메시지가 발행되며 데이터는 손상되지 않습니다.(Bug #29995256, Bug #30510766)
-
Replication: 슬레이브에서 릴레이 로그의 크기를 제한하도록
relay_log_space_limit시스템 변수가 설정되어 있고, coordinator 스레드가 이 제한 및 로그의 끝 위치와 관련된 잠금을 획득한 경우, 멀티스레드 복제 슬레이브에서 내부 데드락이 발생할 수 있었습니다. (Bug #29842426) -
Replication: 복제 슬레이브가 마스터 로그 파일 이름과 마스터 로그 위치를 지정하지 않은
CHANGE MASTER TO문을 사용하여 설정된 후,START SLAVE가 실행되기 전에 종료되고, 이후--relay-log-recovery옵션이 설정된 상태로 다시 시작되면 복제가 시작되지 않았습니다. 이는 릴레이 로그 복구가 시도되기 전에 receiver 스레드가 시작되지 않았기 때문에, 마스터 로그 파일 이름과 마스터 로그 위치를 제공할 로그 회전 이벤트가 릴레이 로그에 없어서 발생했습니다. 이제 이 상황에서 슬레이브는 릴레이 로그 복구를 건너뛰고 경고를 로그에 기록한 다음, 복제 시작을 진행합니다. (Bug #28996606, Bug #93397) -
Group Replication: 멤버가 복제 그룹에 참여하거나 다시 참여할 때, Group Replication이 분산 복구 프로세스에서 오류를 감지하면(이 과정에서 참여하는 멤버는 기존 온라인 멤버로부터 상태 전송을 받습니다), 자동으로 새 donor로 전환하고 상태 전송을 다시 시도합니다. 참여하는 멤버가 포기하기 전에 다시 시도하는 횟수는
group_replication_recovery_retry_count시스템 변수로 설정됩니다. Performance Schema 테이블replication_applier_status_by_worker는 마지막 재시도를 유발한 오류를 표시합니다. 이전에는 그룹 멤버가 병렬 복제 applier 스레드(slave_parallel_workers시스템 변수로 설정됨)로 설정된 경우에만 이 오류가 표시되었습니다. 그룹 멤버가 단일 applier 스레드로 설정된 경우에는 각 재시도 후 내부RESET SLAVE작업에 의해 오류가 지워졌으므로, 이를 확인할 수 없었습니다. 단일 또는 여러 applier 스레드가 있는지와 관계없이SHOW SLAVE STATUS명령의 출력에 대해서도 마찬가지였습니다. 이제 분산 복구를 다시 시도한 후RESET SLAVE작업이 더 이상 수행되지 않으므로, 마지막 재시도를 유발한 오류를 항상 확인할 수 있습니다. (Bug #30517160, Bug #30517172, Bug #97540) -
Group Replication: 복제 그룹 멤버가
STOP GROUP_REPLICATION이 실행되었기 때문이든 오류 때문이든 그룹을 떠날 때, Group Replication은 이제 이전 그룹 멤버가 그룹에 남아 있는 멤버에게 원치 않는 바이너리 로그 데이터를 보낼 수 없도록 바이너리 로그 덤프 스레드를 중지합니다. (Bug #30315614) -
Group Replication: 복제 작업을 사용한 프로비저닝,
RESET MASTER실행, 또는 릴레이 로그에서 부분 트랜잭션 제거 중 하나 이후에 Group Replication이 시작될 때, 서버의 원치 않는 상태를 지우기 위해 내부적으로RESET SLAVE ALL이 사용되었습니다. 그러나 MySQL 8.0.18에서는 이로 인해 Group Replication 채널에 지정된 모든PRIVILEGE_CHECKS_USER계정이 제거되었습니다. 이제 대신RESET SLAVE가 사용되며, 이는 계정을 제거하지 않습니다. (Bug #30262225) -
Group Replication: Group Replication이 single-primary 모드에서 실행 중이고 새 프라이머리 서버가 선출될 때, 이 시점에 기록되는 메시지는 이제 새로 선출된 프라이머리 서버의
gtid_executed세트와 복제 applier가 검색한 GTID 세트를 제공합니다. (Bug #30049310) -
Group Replication: 복제 그룹 멤버가 예기치 않게 중지된 후 즉시 다시 시작되는 경우(예를 들어
mysqld_safe로 시작되었기 때문),group_replication_start_on_boot=on이 설정되어 있으면 해당 멤버는 자동으로 그룹에 다시 참여하려고 시도합니다. 이전에는 재시작 및 다시 참여 시도가 해당 멤버의 이전 인스턴스가 그룹에서 축출되기 전에 발생하면 멤버가 다시 참여할 수 없었습니다. 이제 이 시나리오에서 Group Replication은 Group Communication System (GCS) 기능을 자동으로 사용하여 해당 멤버에 대한 다시 참여 시도를 10회 재시도하며, 각 재시도 사이에는 5초 간격을 둡니다. 이는 대부분의 경우를 처리하고 이전 인스턴스가 그룹에서 축출될 충분한 시간을 제공하여 멤버가 다시 참여할 수 있게 합니다.group_replication_member_expel_timeout시스템 변수가 멤버가 축출되기 전 더 긴 대기 기간을 지정하도록 설정된 경우에는 자동 다시 참여 시도가 여전히 성공하지 못할 수 있다는 점에 유의하십시오. (Bug #29801773) -
macOS: macOS에서
-DWITH_SSL=system으로 MySQL을 설정하면 mysql_config 출력에 정적 SSL 라이브러리에 대한 내부 CMake 이름이 잘못 포함되었습니다. (Bug #30541879, Bug #97632) -
macOS: Ninja를 사용하는 macOS 빌드는 심볼릭 링크를 여러 번 생성하려고 시도하는 오류와 함께 실패할 수 있었습니다. (Bug #30368985)
-
Microsoft Windows; JSON: Windows 플랫폼에서 다중 값 인덱스에 사용된 메모리가 해당 인덱스를 포함하는 테이블이 삭제된 후 해제되지 않았습니다. (Bug #30227756)
-
Microsoft Windows: Windows에서 Strawberry Perl이 설치된 경우
-DWITH_SSL=system이 설치된 OpenSSL 헤더를 찾지 못했습니다. (Bug #30359287) -
Microsoft Windows: Windows에서 시스템 OpenSSL 라이브러리로 이어지는 경로 이름에 공백이 포함된 경우
-DWITH_SSL=system옵션이 작동하지 않았습니다. 이제 이 문제가 처리됩니다. 또한 다른 플랫폼에서와 마찬가지로-DWITH_SSL=yes는-DWITH_SSL=system처럼 처리됩니다. (Bug #30261942, Bug #96739) -
Microsoft Windows: MSVC 2019가 컴파일 오류에 대해 깨진 소스 파일 이름을 생성했습니다. 이를 수정하기 위해
CMake설정에 우회 방법이 구현되었습니다. (Bug #30255096, Bug #96720) -
JSON: 캐릭터 문자열 요소를 해당 캐릭터 문자열의
utf8mb4표현과 동일한 바이트 시퀀스를 포함하는 바이너리 문자열로 교체하여JSON컬럼의 값을 업데이트해도 효과가 없었습니다.이 문제의 근본 원인은 MySQL 8.0.17에서 다중 값 인덱스 구현으로 도입된 JSON 문자열과 JSON opaque 값 간 비교 동작의 변경이었으며, 그 이전에는 JSON 문자열과 JSON opaque 값이 결코 같은 것으로 간주되지 않았습니다. 변경 후에는 바이너리 데이터가 일치하면 같은 것으로 간주되었습니다.
이 변경 사항에 대한 분석 결과, 해당 변경이 필요하지 않은 것으로 나타났습니다. 또한 새 동작은 JSON 값 비교에 관한 기존 문서와 충돌했습니다. 이 문제는 원래 동작을 복원하여 수정되었습니다. (Bug #30348554)
-
JSON:
JSON_TABLE()을 사용한 뷰가 JSON 경로 인수가 인코딩된 캐릭터셋을 보존하지 않았습니다. 이는 뷰가 정의된 캐릭터셋과 다른 캐릭터셋이 적용된 상태에서 뷰가 평가되는 경우, 잘못된 결과를 생성할 수 있음을 의미했습니다. 이 문제는 이러한 경우JSON_TABLE()이 원래 캐릭터셋을 보존하도록 보장하여 수정되었습니다. (Bug #30310265) -
JSON: JSON 컬럼에 함수형 인덱스를 추가하면 문자열 비교에 사용되는 콜레이션이 변경되어, 해당 컬럼을 선택하는 동일한 쿼리가 반환하는 결과가 인덱스 없이 얻은 결과와 달라졌습니다. (Bug #29723353)
-
JSON: 저장 프로시저 실행 중에는
JSON_TABLE()의 첫 번째 인수가const였지만 준비 중에는 그렇지 않은 경우, 이후 문이 다시 실행될 때 해당 인수가 다시 평가되지 않아 프로시저의 첫 번째 실행 이후에는 매번 빈 결과가 반환되었습니다. (Bug #97097, Bug #30382156) -
JSON: 일부 경우, 예를 들어 쿼리가
FORCE INDEX를 사용할 때 테이블을 읽는 비용은DBL_MAX입니다. 이는 출력될 때2e308로 올림 처리되었으며, 이 값은 JSON 파서에 너무 크기 때문에SELECT JSON_EXTRACT(trace, '$**.table_scan') FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE와 같은 쿼리를 사용하여 optimizer trace의 일부를 추출할 수 없었습니다. 이제 이러한 경우1.5e308보다 큰 값은 대신 내림 처리되어1e308으로 출력됩니다. (Bug #96751, Bug #30226767) -
MySQL 5.7에서 MySQL 8.0으로 업그레이드한 후,
CLONE INSTANCE작업이 다음 오류와 함께 실패했습니다: ERROR 3862 (HY000): Clone Donor Error: 1016: Can't open file: './undo001'. 업그레이드 프로세스가 고아 인메모리 undo 테이블스페이스를 남겼습니다. 기여해 주신 Satya Bodapati에게 감사드립니다. (Bug #30602218, Bug #97784, Bug #30239255, Bug #96637) -
MySQL Optimizer의 해시 조인 알고리즘은 중간 결과를 저장하기 위해 조인 버퍼를 사용합니다. 이 버퍼가 오버플로되면, 서버는 이를 원활하게 처리하기 위해 해시 조인 피연산자 중 하나를 임시 파일에 쓰는 spill-to-disk 알고리즘을 사용합니다. 피연산자 중 하나가 pushed join 작업의 멤버인 테이블인 경우, 이 전략은 pushed join 조상 중 하나가 조인 평가에서 현재 로우일 때마다 모든 자식 결과 로우가 nested-loop 읽기를 사용해야 한다는 pushed join 요구 사항과 충돌했으며, 이로 인해 일부 경우 잘못된 쿼리 결과가 반환될 수 있었습니다. (Bug #30573733)
-
INFORMATION_SCHEMA.VIEWS테이블에 대한 접근이 올바른 사용자로 적절히 제한되지 않았습니다. (Bug #30542333) -
해시 조인 중 조회에 사용되는 해시 값을 생성할 때, 서버가
PAD SPACE속성을 준수하지 않았으며, 이는PAD SPACE콜레이션을 사용할 때'foo'와'foo '가 일치하지 않았음을 의미합니다. 이는 모든 문자열을 가능한 가장 긴 문자열과 같은 길이가 될 때까지 패딩하도록 수정되었으며, 여기서 가능한 가장 긴 문자열은CHAR(N)또는VARCHAR(N)의 데이터 타입 길이 지정자N에서 추론됩니다. (Bug #30535541) -
보조 엔진에서
DECIMAL컬럼을 포함하는 큰 결과 집합을 검색할 때, 텍스트 프로토콜을 통한 전송을 위해 컬럼 값을 문자열로 변환하는 작업이 병목으로 작용했습니다. 이러한 변환을 담당하는 함수의 성능은 내부 테스트에 반영된 바와 같이 일부 경우 최대 50%까지 개선되었습니다. (Bug #30528427) -
FORMAT_PICO_TIME()함수가 여러 로우를 처리하도록 호출되었을 때, 한 로우에서NULL인수가 발견되면 그 이후의 모든 결과가NULL로 설정되었습니다. (Bug #30525561) -
Performance Schema 이벤트의 시간이 측정될 때, 타이머 시작 값과 종료 값이 같은 이벤트의 경우
events_xxx테이블에 보고되는 이벤트 지속 시간이 0이 아니라NULL일 수 있었습니다. (Bug #30525560) -
괄호로 묶인 쿼리에
LIMIT절을 추가하면 괄호 안의 잠금 절이 억제되었습니다. 예를 들어, 이 쿼리는 테이블을 잠그지 않았습니다:(SELECT ... FOR UPDATE) LIMIT ...;괄호로 묶인 쿼리 바깥에
LIMIT절을 추가하는 것은 괄호 안의LIMIT절을 재정의하도록 의도되었습니다. 그러나 바깥쪽LIMIT은 괄호 안의ORDER BY도 억제했습니다. 예를 들어, 이 쿼리에서는ORDER BY가 억제되었습니다:(SELECT ... ORDER BY ... LIMIT a) LIMIT b;이제 내부 잠금 및
ORDER BY절은 외부LIMIT절에 의해 억제되지 않습니다. (Bug #30521098, Bug #30521803) -
Optimizer가 조기 평가를 위해 상수 테이블에 대한 조건을 추출할 때, 저장 함수와 관련된 조건을 포함하여 평가 비용이 높은
WHERE조건은 포함하지 않습니다. 추출된 조건이 const 테이블만 관련되어 있어 true로 평가되면, 전체WHERE조건이 잘못 제거되었습니다. 이제 이러한 경우에는WHERE조건을 제거하기 전에 비용이 높은 조건에 대한 검사가 수행됩니다. (Bug #30520714) -
lateral materialized derived 테이블이
DISTINCT를 사용할 때, derived 테이블이 예상대로 각 외부 로우마다 다시 materialize되지 않았습니다. (Bug #30515233) -
EXPLAIN ANALYZE는WITH RECURSIVE를 사용하는 common table expression에서 올바르게 작동하지 않았습니다. (Bug #30509580) -
GNU gold 로더는 일부 플랫폼에서 메모리 고갈을 유발할 수 있었습니다. 이제 기본적으로 Intel 64-bit 플랫폼에서만 사용됩니다. (Bug #30504760, Bug #96698)
-
일부 Linux 플랫폼에서는
clock_gettime()대신libstdc++가 시스템 호출을 사용하여EXPLAIN ANALYZE의 오버헤드가 높게 발생했습니다. (Bug #30483025) -
Solaris 11.4에서 LDAP 인증 플러그인을 빌드할 수 없었습니다. (Bug #30482553)
-
MEMBER OF()연산자를 사용하는 쿼리가 항상 올바르게 처리되지는 않았습니다. (Bug #30477993) -
이후 수정된 VC++ 2013 버그에 대한 Boost 우회 방법으로 인해 Visual Studio에서 Boost 컴파일이 실패했습니다. 이제 해당 우회 방법은 MySQL과 함께 Boost를 컴파일할 수 있도록 패치되었습니다. (Bug #30474056, Bug #97391)
-
보조 엔진에서 많은 정수를 포함하는 큰 결과 집합을 가져올 때, 텍스트 프로토콜을 통해 전송하기 위해 정수를 문자열로 변환하는 작업이 병목으로 작용할 수 있었습니다. 이 문제를 방지하기 위해 이러한 변환을 수행하는 내부 함수의 성능이 개선되었습니다. (Bug #30472888)
-
Docker 패키지에 LDAP 인증 플러그인이 누락되어 있었습니다. (Bug #30465247)
-
mysys/my_handler_errors.h오류 메시지의 오타를 수정했습니다. 기여해 주신 Nikolai Kostrigin에게 감사드립니다. (Bug #30462329, Bug #97361) -
innodb_force_recovery가 활성화되어 있는 동안 GTID 테이블을 업데이트하면 디버그 어설션 실패가 발생했습니다. (Bug #30449531, Bug #97312) -
MySQL이 Protobuf 3.10을 대상으로 컴파일되지 못했습니다. (Bug #30428543, Bug #97246)
-
시스템 시작 중 버퍼링된 로그 라인이 손실될 수 있었습니다. (Bug #30422941, Bug #97225)
-
mysql.user시스템 테이블의 이름이 변경된 경우 서버가 종료될 수 있었습니다. (Bug #30418070) -
호스트 이름 없이 지정된 역할을 취소하면 서버 종료가 발생할 수 있었습니다. (Bug #30416389)
-
semijoin 내부의 다른 테이블이 해당 테이블에 의존할 때 semijoin 테이블을 끌어낼지 여부를 결정하는 경우, 베이스 테이블인 semijoin 테이블만 고려되었으며, 중첩 조인에 있는 테이블은 무시되었습니다. (Bug #30406241)
References: See also: Bug #12714094, Bug #11752543, Bug #43768.
-
Ubuntu 플랫폼의 AppArmor 프로파일이 OpenSSL 설정을 읽을 수 없었습니다. (Bug #30375723)
-
일부 Fedora 30 패키지에는 기존 MySQL 설치를 업그레이드할 때 문제를 일으킬 수 있는 obsoletes 정보가 누락되어 있었습니다. (Bug #30348549, Bug #96969)
-
ALTER SCHEMA문에서 기본 암호화만 변경하면 스키마 기본 캐릭터셋과 콜레이션이 시스템 기본값으로 재설정되었습니다. (Bug #30344462, Bug #96994) -
AUTO_INCREMENT와DEFAULT값 표현식을 모두 사용하여 선언된 컬럼(허용되지 않는 조합)은 어설션을 발생시키거나 서버 종료를 유발할 수 있었습니다. (Bug #30331053) -
익명 사용자에 대한
SHOW GRANTS는 일부 조건에서 서버 종료를 초래할 수 있었습니다. (Bug #30329114) -
GREATEST()및LEAST()는 시간 값을 항상 올바르게 처리하지 않았습니다. (Bug #30326848)참고: 이 문제는 다음의 회귀입니다: Bug #25123839.
-
파티션 객체의 서브파티션 목록이 직렬화되지 않았으므로 직렬화된 딕셔너리 정보(SDI)에 포함되지 않았습니다. 이 문제를 해결하기 위해 서브파티션 딕셔너리 정보의 직렬화 및 역직렬화 지원이 추가되었습니다. 이 버그의 패치에는 사소한 SDI 코드 리팩터링 및 형식 변경도 포함됩니다. 형식 변경으로 인해 SDI 버전 번호가 증가했습니다. (Bug #30326020, Bug #96943)
-
ANALYZE TABLE실행 후, 지정된 쿼리에 대한 옵티마이저 트레이스는 다른 쿼리가 그 이전에 실행되었을 때뿐만 아니라ANALYZE TABLE이후에도 달라졌습니다. (Bug #30321546) -
innodb_buffer_pool_instances는SET PERSIST또는PERSIST_ONLY를 사용하여 설정된 경우 서버 시작 시 올바르게 초기화되지 않았습니다. (Bug #30318828) -
낮은
max_allowed_packet값으로 인해 다음 오류가 발생했습니다: ERROR 1153 (08S01) at line 1: Got a packet bigger than 'max_allowed_packet' bytes. 오류 메시지는 클로닝 작업에 필요한 최소max_allowed_packet값을 나타내도록 수정되었습니다. (Bug #30315486, Bug #96891) -
서버 코드가 오류 로그에 기록되도록 의도된 오류 코드를 클라이언트에 보내려고 할 때 어설션이 발생할 수 있었습니다. 이러한 경우는 클라이언트에 보내도록 의도된 코드를 보내도록 수정되었습니다. (Bug #30312874)
-
뷰 정의의 본문에 조인과 여러 서브셀렉트가 포함된 경우
CREATE VIEW가 항상 성공하지는 않았습니다. (Bug #30309982)참조: 이 문제는 다음의 회귀입니다: Bug #25466100.
-
SLES 12 RPM 패키지의 의존성 정보가 잘못되어 MySQL 설치 실패가 발생했습니다. (Bug #30308305)
-
hash join 청크 파일에서
GEOMETRY데이터를GEOMETRY컬럼으로 복원할 때, 서버가 데이터를 컬럼으로 복사하지 않고 임시 버퍼에 있던 데이터에 대한 포인터를 대신 저장했으며, 이는 이 버퍼가 재사용되는 즉시GEOMETRY컬럼이 임의의 데이터를 가리킨다는 것을 의미했습니다. 이제 서버는 hash join을 실행할 때 항상 이 버퍼의 데이터를GEOMETRY컬럼으로 복사합니다. (Bug #30306279) -
COPY알고리즘을 사용하는 일부ALTER TABLE작업이 표현식 기본값이 있는 컬럼을 올바르게 처리하지 못했습니다. (Bug #30302907, Bug #96864) -
CONV()함수가 반환할 적절한 문자 수를 항상 올바르게 처리하지 못했습니다. (Bug #30301543) -
파서 재귀 검사가 스택 오버플로를 방지하기에 충분하지 않았습니다. (Bug #30299881)
-
서브쿼리가 발생한 조건이 항상 false였기 때문에 해당 서브쿼리를 제거하는 작업은 resolution 중에 수행될 것으로 예상되었지만, 서브쿼리에 어떤 테이블도 포함되지 않은 경우 서버는 이를 resolve하는 동안 실행했습니다. 이로 인해 서브쿼리가 아직 최적화되지 않고 resolve만 되고 있는지 확인하는 후속 검사가 실패했습니다. 이제 이러한 경우 서버는 서브쿼리가 이미 실행되었는지도 확인합니다. (Bug #30273827)
-
디버그 빌드의 경우, 유효하지 않은 expression default가 있는 컬럼을 빈 임시 테이블에 추가하려는 시도에서 assertion이 발생했습니다. (Bug #30271792)
-
iterator tree를 구성하면 비계층 구조가 생성될 수 있으며, 예를 들어
a LEFT JOIN b LEFT JOIN c의b와c가 semijoin의 오른쪽도 구성하는 경우 이런 일이 발생할 수 있습니다. iterator executor는 전체 쿼리 위에 weedout을 추가하여 이를 해결하며, 이는 row ID와 상호작용하는 iterator에도 해당 ID를 저장하고 복원해야 함을 의미합니다. 이러한 모든 경우에 이 작업이 수행되지는 않아 잘못된 결과가 발생했습니다. 이제 top-level weedout의 추가는 영향을 받는 iterator가 구성되기 전에, 이 작업이 수행된다는 사실이 알려지는 즉시 항상 iterator에 전달됩니다. (Bug #30267889) -
SQL 계층과 데이터 딕셔너리 사이의 외래 키 처리 코드 중복이 제거되었습니다. 부수 효과로, 일부 오류 메시지가 이제 더 많은 정보를 제공하고 명확해졌습니다. (Bug #30267236, Bug #96765)
-
시작 중에 서버가 지속 변수에 대한 잘못된 옵션 값을 부적절하게 처리하여 서버 종료가 발생할 수 있었습니다. (Bug #30263773)
-
구체화된 세미조인이 포함된 일부 쿼리에서, iterator executor를 사용할 때 조건이 구체화 외부에서 평가되어 비효율적인 쿼리 실행 계획이 사용되었고, 때로는 잘못된 결과도 생성되었습니다. (Bug #30250091)
-
CHECK제약 조건에서 사용되는 컬럼의 이름을 변경하는ALTER TABLE문은 잘못된 오류 메시지를 발생시킬 수 있었습니다. (Bug #30239721) -
SELECT문의 경우, 잠금 절 앞의INTO var_name절은 적법하지만 파서가 이를 거부했습니다. (Bug #30237291, Bug #96677) -
동일한 세션 내에서
LOCK INSTANCE FOR BACKUP문이 이전에 실행되었고,FLUSH TABLES WITH READ LOCK문에 대해 지정된(암시적 또는 명시적으로) 동일한 데이터베이스를 대상으로 다른 세션에서 동시에ALTER DATABASE문이 실행 중인 경우,FLUSH TABLES WITH READ LOCK이 데드락을 발생시켰습니다. (Bug #30226264) -
slow query 로깅은 classic 클라이언트/서버 프로토콜을 사용하지 않은 연결에서 서버 종료를 초래할 수 있었습니다. (Bug #30221187)
-
명시적 이름 없이 외래 키를 추가하는 문은 prepared statement 또는 저장 프로그램에서 다시 실행될 때 부당한 중복 외래 키 이름 오류와 함께 실패했습니다. (Bug #30214965, Bug #96611)
참조: 이 문제는 다음의 회귀입니다: Bug #30171959.
-
AUTO_INCREMENT컬럼이 있지만AUTO_INCREMENT값을 지정하지 않는 테이블에 여러 세션이 동시에INSERT... ON DUPLICATE KEY UPDATE문을 실행할 때, 삽입이 고유 인덱스 위반과 함께 실패할 수 있었습니다. (Bug #30194841, Bug #96578) -
클라이언트 프로그램이 플러그인 라이브러리 외부에서 인증 플러그인을 로드할 수 있었습니다. (Bug #30191834, Bug #30644258)
-
테이블 스캔과 인덱스 조회 간 전환할 때
AlternativeIterator가 핸들러를 재설정하지 않았으며, 이로 인해 assertion 실패가 발생할 수 있었습니다. (Bug #30191394) -
open_files_limit을 큰 값으로 설정하거나, 운영 체제 rlimit이 크지만RLIM_INF와 같지는 않은 값을 가진 경우에 이를 설정하면 서버의 메모리가 부족해질 수 있었습니다. 이 수정의 일부로, 이제 서버는 유효open_files_limit값을 최대 unsigned integer 값으로 제한합니다. (Bug #30183865, Bug #96525) -
정규화된
INFORMATION_SCHEMA테이블에 대한 참조는INFORMATION_SCHEMA가 지정된 대소문자에 따라 실패할 수 있었습니다. (Bug #30158484) -
실행 시간이 35일을 초과하는 느린 쿼리는
REPAIR TABLE작업이 필요할 정도로mysql.slow_log시스템 테이블을 손상시킬 수 있었습니다. (Bug #30113119, Bug #96373) -
MySQL은
NOTIFY_SOCKET환경 변수를 사용하여 지정된 소켓으로 systemd 알림 메시지를 보내는 것을 지원하지 않았으며, 해당 변수의 이름이 추상 네임스페이스 소켓인 경우가 이에 해당했습니다. (Bug #30102279) -
SET PERSIST_ONLY를 사용하여 boolean 시스템 변수를 숫자 값으로 설정하면 서버를 다시 시작할 수 없게 되는 결과가 발생했습니다. (Bug #30094645, Bug #30298191, Bug #96848) -
이전 문제에 대한 수정에서 두
TABLE_LIST생성자가 적절하지 않은 방식으로 결합되었습니다. 이 중 하나는 임시 테이블을 나타내는TABLE객체에서TABLE_LIST객체를 생성했습니다. 이전에는 테이블 이름이 별칭과 동일하게 만들어졌으며, 이것은TABLE객체에서 이름을 복사하도록 변경되었습니다. 임시 테이블의 경우 테이블 이름이 파일 경로라는 사실로 인해MDL_key이름의 제한을 초과할 수 있었으며, 이로 인해 assertion 실패가 발생했습니다. 수정 이전과 동일한 방식으로 동작하는 전용 생성자를 다시 도입하여 수정했습니다. (Bug #30083125)참조: 이 문제는 다음의 회귀입니다: Bug #27482976.
-
저장 함수 내에서 발생하는
UNIX_TIMESTAMP()오류의 경우, 이후 함수 호출에 대한 소수 초 자릿수가 올바르지 않을 수 있었습니다. (Bug #30034972, Bug #96166) -
공통 테이블 표현식에 비결정적 표현식(
RAND()을 사용한 표현식 등)이 포함되어 있고, 외부 쿼리에서 해당 공통 테이블 표현식이 두 번 이상 참조된 경우, 일부 경우에 병합되었습니다. 이로 인해 공통 테이블 표현식이 각 참조마다 다른 결과를 반환했습니다. 이제 이러한 경우 공통 테이블 표현식은 병합되지 않고 대신 구체화됩니다. (Bug #30026353) -
Linux에서
lower_case_table_names=1설정으로 시작된 MySQL의 디버그 빌드에서, MySQL 8.0.16에서 인플레이스 업그레이드한 후 파티셔닝된 테이블의 테이블스페이스를 폐기하면 심각한 오류가 발생했습니다. 데이터 딕셔너리에 저장된 파티션 테이블스페이스 이름이 유효하지 않았으며, MySQL 8.0.17에서 파티션 테이블스페이스를 위해 준비된 메타데이터 잠금 키가mysql.tablespaces테이블에 저장된 키와 일치하지 않았습니다. (Bug #30024653) -
KILL QUERY는 의도한 문 다음의 문을 종료할 수 있었습니다. (Bug #29969769) -
lower_case_table_names=2에서SHOW TABLES가 대문자 이름을 가진 테이블을 표시하지 못할 수 있었습니다. (Bug #29957361) -
생성 컬럼에 대해 유효하지 않은 표현식이 있는 테이블을 업그레이드하려는 시도에 대해 보고되는 오류 메시지가 충분한 정보를 제공하지 않았습니다. 이제 오류 메시지에는 생성 컬럼 이름과 생성 컬럼을 만드는 데 사용된 표현식이 포함됩니다. (Bug #29941887, Bug #95918)
-
확인할 수 없는 뷰를 표시하려는 시도가 오류 대신 서버 종료를 초래할 수 있었습니다. (Bug #29939279)
-
CREATE TABLE문에 대한 시간 리터럴의 잘못된 검사가 서버 종료로 이어질 수 있었습니다. (Bug #29906966, Bug #95794) -
시스템 리소스를 일시적으로 사용할 수 없는 동안 병렬 읽기 작업을 위해 스레드를 생성하려고 하면 시스템 오류가 발생했습니다. (Bug #29874480)
-
mysql.global_grants시스템 테이블에 예상치 못한 값을 쓰면 서버 종료가 발생할 수 있었습니다. (Bug #29873343) -
INFORMATION_SCHEMA.EVENTS테이블의LAST_EXECUTED값이 이벤트 시간대가 아니라 UTC로 잘못 보고되었습니다. (Bug #29871530, Bug #95649) -
서버 시작 시 명령줄에서
keyring_encrypted_file_password가 설정된 경우, 비밀번호 값이 시스템 유틸리티에 표시될 수 있었습니다. (Bug #29848634) -
MySQL 5.7에서 MySQL 8.0으로 업그레이드할 때
lower_case_table_names설정을 변경하면 스키마 또는 테이블 이름의 대소문자 불일치로 인해 실패가 발생할 수 있었습니다.lower_case_table_names=1인 경우, 이제 업그레이드 프로세스에서 테이블 및 스키마 이름을 검사하여 모든 문자가 소문자인지 확인합니다. 테이블 또는 스키마 이름에 대문자가 포함된 것으로 확인되면 업그레이드 프로세스가 오류와 함께 실패합니다. 관련 정보는 업그레이드를 위한 설치 준비를 참조하십시오. (Bug #29842749, Bug #95559) -
LOCK TABLES문이 적용 중일 때, 잠긴 테이블에 대한 메타데이터 변경으로 인해 세션 변수에 대한 Performance Schema 또는SHOW쿼리가opening_tables상태에서 중단될 수 있었습니다. (Bug #29836204, Bug #92387) -
불가능한 범위를 초래하는
A AND (B OR C [OR...])형식의WHERE조건을 사용하는SELECT로 인해 서버가 예기치 않게 종료되었습니다. (Bug #29770705) -
JSON 형식 Audit Log의 경우, 이제
id필드가 65535보다 큰 값을 포함할 수 있습니다. 이전에는 로깅 활동이 많은 경우 초당 65536개가 넘는 쿼리가 실행될 수 있었고,id값에 허용된 16비트를 초과했습니다. (Bug #29661920) -
불완전한 연결 패킷으로 인해 클라이언트가 인증 플러그인 이름을 올바르게 초기화하지 못할 수 있었습니다. (Bug #29630767)
-
파서의 메모리 부족 오류가 무시되어 서버가 종료될 수 있었습니다. (Bug #29614521)
-
Linux에서 Performance Schema 파일 계측이 비활성화되었다가 다시 활성화될 때 assertion이 발생할 수 있었습니다. (Bug #29607570)
-
CREATE TABLE문에서PRIMARY KEY로 정의된 컬럼의 경우, 표현식으로 제공된 기본값이 무시되었습니다. (Bug #29596969, Bug #94668) -
MySQL 8.0.16에서 추가된
TABLE_ENCRYPTION_ADMIN권한이 업그레이드 중 시스템 정의mysql.session사용자에게 잘못 부여되었습니다. (Bug #29596053, Bug #94888) -
OpenSSL로 암호화된 연결의 경우, 소켓 수준의 네트워크 I/O가 Performance Schema에 보고되지 않았습니다. 또한 서버가
IDLE상태에 있는 동안 수행된 네트워크 I/O가 Performance Schema에 보고되지 않았습니다. (Bug #29205129, Bug #30535558, Bug #97600) -
쿼리가 (세미조인 변환 또는 파생 테이블 병합으로 인해) 외부 쿼리 블록으로 병합된 서브쿼리를 사용하고, 그 서브쿼리 자체가 자신의 베이스 쿼리 블록과 다른 집계 쿼리 블록을 가진 집계 함수가 포함된 서브쿼리를 포함하는 경우, 해당 쿼리는 두 번째로 실행되거나
FLUSH TABLES가 먼저 실행되지 않으면 때때로 아무 로우도 반환하지 못할 수 있었습니다. 이는 병합 시 사용된 테이블과 관련된 정보 및 집계 함수에 대한 집계 정보가 올바르게 업데이트되지 않았기 때문입니다. 이 버그 보고서를 발생시킨 경우에는 스칼라 서브쿼리를 포함하는 비교 연산이 const-for-execution으로 간주되어 range optimizer가 이를 평가하려고 했으며, 스칼라 서브쿼리에 아직 읽히지 않은 외부 참조를 참조하는MIN()함수가 포함되어 있었다는 의미였습니다. 따라서 aggregator 객체가 채워질 때 초기화되지 않은 데이터를 기반으로 하였고, 예측할 수 없는 결과로 이어졌습니다. (Bug #28941154) -
mandatory_roles시스템 변수를 변경하면 동시 세션의SHOW GRANTS가 잘못된 결과를 생성할 수 있었습니다. (Bug #28699403) -
keyring_aws초기화 실패로 인해 SSL 소켓 초기화가 실패했습니다. (Bug #28591098) -
특정 조건에서
read_only또는super_read_only시스템 변수를 활성화해도SUPER권한이 없는 사용자가 실행한 동시 DDL 문을 차단하지 못했습니다. (Bug #28438114, Bug #91852) -
현재
GROUP BY플랜이 개선되어 모든 갭 속성이 동등 조건자의 논리합을 가질 수 있습니다. 이 개선 사항을 활용하려면 서로 다른 속성의 조건자는 여전히 서로 논리곱 관계여야 합니다.이 기여에 대해 Facebook에 감사드립니다. (Bug #28056998, Bug #15947433, WL #13066)
-
일부 경우
FLOOR()및CEILING()함수에 대한BIGINT인수가 잘못된 타입으로 확인되었습니다. (Bug #27125612) -
mysqlpump는 설계상 유효하지 않은 뷰를 포함하는 데이터베이스를 덤프하지 않고 종료하지만, 유효하지 않은 뷰가 존재하더라도 덤프할 데이터베이스 중 어느 것에도 속하지 않는 경우에도 실패했습니다. (Bug #27096081)
-
외래 키 정보는 이제
InnoDB가 아니라 데이터 딕셔너리에서 검색됩니다. (Bug #25583288) -
InnoDB테이블에 대한CREATE TABLE및ALTER TABLE문에서 사용된 외래 키 정의는 해당 문이 조건부 주석(예:/*!50101... */또는/*!... */)으로 감싸진 경우 무시되었습니다. (Bug #21919887, Bug #78631) -
--log-raw옵션은 이제 런타임에log_raw시스템 변수로 사용할 수 있습니다. 시스템 변수는 시작 시 옵션 값으로 설정되며, 비밀번호 마스킹 동작을 변경하기 위해 런타임에 설정할 수 있습니다. (Bug #16636373, Bug #68936) -
EXPLAIN ANALYZE는SELECT목록의 서브쿼리를 실행하지 않았으며, 따라서 시간 또는 비용 계산에서 이를 고려하지 않았습니다. (Bug #97296, Bug #30444266) -
외부 참조를 포함하는 내부 스칼라 서브쿼리는 오른쪽에 중첩된
SELECT표현식 집합을 사용할 때, 그와 동등한 단일SELECT를 사용할 때와 동일한 결과를 반환하지 않았습니다. (Bug #97063, Bug #30381092) -
구체화된 서브쿼리는 인덱스를 사용하는지 여부에 따라 서로 다른 결과를 산출할 수 있었습니다. (Bug #96823, Bug #30289052)
-
MAX_EXECUTION_TIME힌트를 사용하여 지정한 시간을 초과하여 쿼리가 종료되면, 생성되는 오류가 쿼리의 단계에 따라 달랐습니다. 특히 쿼리가 filesort 중에 종료되면 발생한 오류는ER_FILSORT_ABORT였지만, 이러한 경우 쿼리는 항상ER_QUERY_TIMEOUT으로 종료되어야 합니다. 이로 인해 이러한 오류를 포착하고 올바르게 처리하는 일이 불필요하게 어려웠습니다.이 수정은 오류 코드
ER_FILSORT_ABORT및ER_FILESORT_TERMINATED를 제거합니다. (Bug #96537, Bug #30186874) -
저장 프로시저에 member 또는 array라는 이름의 매개변수가 있고, 매개변수 이름에 따옴표 처리를 하지 않고 정의된 경우, 해당 저장 프로시저가 정의된 데이터베이스를 8.0.17 또는 8.0.18로 업그레이드할 수 없었습니다. (Bug #96288, Bug #30084237)
참조: 다음도 참조하십시오: Bug #96350, Bug #30103640.
-
COALESCE()또는IFNULL()같은 함수에BIGINT컬럼 값이 전달되었을 때, 이 함수의 음수 반환 값을UNSIGNED로 캐스팅하면 예기치 않게 0이 산출되었습니다.이 기여를 해 주신 Oleksandr Peresypkin께 감사드립니다. (Bug #95954, Bug #29952066)
-
인덱스가 있는 컬럼에 대해
MAX()를 사용하는 쿼리에 대해EXPLAIN출력은Select tables optimized away를 표시했지만, 동일한 컬럼에 대한MAX()가 사용자 함수에서 호출된 경우에는 대신Using index를 표시했습니다. (Bug #94862, Bug #29596977)