MySQL 8.0.30 릴리스 노트
MySQL 8.0.30 Community Server 릴리스 노트를 한국어로 번역하고, DBA가 참고해야 할 핵심 내용을 함께 정리하였습니다.
DBA를 위한 핵심 내용
MySQL 8.0.30은 redo log 구조 변경, GIPK 도입, XA 복구 개선, INSTANT ADD/DROP COLUMN 후속 수정, utf8 콜레이션 표기 변화가 포함된 운영 영향이 큰 릴리스입니다. 특히 redo log가 #innodb_redo 디렉터리의 32개 파일과 innodb_redo_log_capacity 중심으로 전환되므로 정상 종료 후 업그레이드, 백업/복구 도구 호환성, 모니터링 지표 변경을 반드시 확인해야 합니다. MySQL 8.0.29의 INSTANT ADD/DROP COLUMN 변화는 백업 도구에서도 별도 지원 이슈로 다뤄졌으므로, 8.0.30 적용 전 물리 백업 도구 버전과 복구 가능성을 검증하는 것이 안전합니다. (Percona XtraBackup 8.0.29 and INSTANT ADD/DROP Columns)
innodb_redo_log_capacity가 동적 설정을 지원하고, 기존innodb_log_files_in_group·innodb_log_file_size는 사용 중단되며 기본 redo 파일 위치와 개수가 변경됩니다. 업그레이드 전 정상 종료가 필요하고, 디스크 용량·백업 제외 경로·모니터링 쿼리를 갱신해야 합니다.sql_generate_invisible_primary_key=ON이면 기본 키 없는 InnoDB 테이블에my_row_id보이지 않는 primary key가 자동 생성됩니다. 복제 적용자에는 기본적으로 적용되지 않으므로 소스·레플리카 스키마 차이, dump 옵션--skip-generated-invisible-primary-key, ORM의 컬럼 인식 여부를 확인하십시오.- Classic Replication 및 Group Replication 토폴로지에서 XA 상태 전파와 복구 일관성이 강화되었습니다. 다만 동일 XID를 순차 재사용하는 패턴에는 알려진 제한이 있으므로 애플리케이션 XID 생성 정책을 점검하십시오.
utf8_콜레이션명이utf8mb3_접두사로 표시되도록 변경되어SHOW CREATE TABLE, Information Schema 기반 스키마 비교, 마이그레이션 diff 도구에 영향이 있을 수 있습니다. 실제 의미 변화보다 출력 변화에 따른 자동화 오탐을 주의하십시오.- 8.0.29 이후 INSTANT ADD/DROP COLUMN 관련 데이터 해석·복구·성능 문제가 다수 수정되었고, 히스토그램 선택도 하한, 조건 pushdown,
EXPLAIN ANALYZE, 뷰/파생 테이블 오답 수정도 포함됩니다. INSTANT DDL 사용 테이블과 복잡한 분석 쿼리는 백업 복구 및 결과 비교 테스트가 필수입니다. replica_parallel_workers=0,--skip-host-cache,--old-style-user-limits등이 사용 중단되었습니다. 복제 단일 스레드 적용이 필요하면replica_parallel_workers=1로 명시하고, host cache 및 오래된 사용자 제한 옵션 의존성을 정리하는 것이 좋습니다.
캐릭터셋 지원
-
중요한 변경 사항: 이전 변경 사항에서는 더 이상 사용되지 않는 이름에
utf8_접두사가 붙은 캐릭터셋의 이름을 대신utf8mb3_을 사용하도록 변경했습니다. 이번 릴리스에서는utf8_콜레이션도utf8mb3_접두사를 사용하도록 이름을 변경합니다. 이는 콜레이션 이름을 캐릭터셋의 이름과 일관되게 만들고, 더 이상 사용되지 않는 콜레이션 이름에 더 이상 의존하지 않으며,utf8mb3와utf8mb4의 차이를 명확히 하기 위한 것입니다. 이제utf8mb3_접두사를 사용하는 이름은SHOW CREATE TABLE과 같은SHOW문의 출력뿐만 아니라,COLLATIONS및COLUMNS테이블을 포함한 Information Schema 테이블의 컬럼에 표시되는 값에서도 이러한 콜레이션에 대해 독점적으로 사용됩니다. (Bug #33787300)참조: 다음도 참조하십시오: Bug #30624990.
-
중요한 변경 사항: 둘 이상의 언어가 동일한 콜레이션 정의를 가진 경우, MySQL은 해당 언어 중 하나에 대해서만 콜레이션을 구현했습니다. 이는 일부 언어가 다른 언어에 한정된
utf8mb4유니코드 9.0 콜레이션으로만 처리되었음을 의미했습니다. 이번 릴리스에서는 이전에 다른 언어의 언어별 콜레이션으로만 처리되었던 언어에 대해 언어별 콜레이션을 추가하여 이러한 문제를 수정합니다. 새 콜레이션은 다음과 같습니다:-
노르웨이어
- (Bokmål)
utf8mb4_nb_0900_ai_ci - (Bokmål)
utf8mb4_nb_0900_as_cs - (Nynorsk)
utf8mb4_nn_0900_ai_ci - (Nynorsk)
utf8mb4_nn_0900_as_cs
- (Bokmål)
-
라틴 문자를 사용하는 세르비아어:
utf8mb4_sr_latn_0900_ai_ciutf8mb4_sr_latn_0900_as_cs
-
라틴 문자를 사용하는 보스니아어:
utf8mb4_bs_0900_ai_ciutf8mb4_bs_0900_as_cs
-
불가리아어:
utf8mb4_bg_0900_ai_ciutf8mb4_bg_0900_as_cs
-
갈리시아어:
utf8mb4_gl_0900_ai_ciutf8mb4_gl_0900_as_cs
-
키릴 문자를 사용하는 몽골어:
utf8mb4_mn_cyrl_0900_ai_ciutf8mb4_mn_cyrl_0900_as_cs
자세한 내용은 언어별 콜레이션을 참조하십시오. (Bug #31885256, WL #14307)
-
컴파일 관련 사항
-
Enterprise Linux에서 CMAKE_C_FLAGS 및 CMAKE_CXX_FLAGS의 초기값이 수정되기 전에 사용되도록 ADD_LINUX_RPM_FLAGS를 수정했습니다. (Bug #34131794)
참조: 이 문제는 다음의 회귀입니다: Bug #33730302.
-
새로운 SHOW_SUPPRESSED_COMPILER_WARNINGS CMake 옵션을 추가했습니다. 억제된 컴파일러 경고를 표시하고, -Werror로 실패하지 않도록 하려면 이 옵션을 활성화하십시오. 기본값은 OFF입니다. (Bug #34046748)
-
macOS/ARM 지원을 추가했습니다. (Bug #34017614)
-
Windows에서 사용 중단 경고(C4996)는 /wd4996 명령줄 옵션으로 전역적으로 비활성화되었지만, 이제 사용 중단 경고는 적절한 경우 지역화된 수준에서 비활성화됩니다. (Bug #33975638)
-
Windows에서 생성되는 INFO_BIN 및 INFO_SRC 파일을 개선했습니다. (Bug #33972317, Bug #34052301)
-
std::filesystem을 사용하기 위해 -lstdc++fs를 포함하도록 GCC 8 지원을 개선했습니다. (Bug #33939798)
사용 중단 및 제거 관련 사항
-
Replication:
replica_parallel_workers시스템 변수(또는 이에 해당하는 서버 옵션--replica-parallel-workers)를 0으로 설정하는 것은 이제 사용 중단되었으며, 이렇게 하면 이제 경고가 발생합니다.경고 없이 동일한 결과(즉, 단일 스레드 사용)를 얻으려면 대신
replica_parallel_workers=1을 설정하십시오. (WL #13956) -
--skip-host-cache서버 옵션은 이제 사용 중단되었으며, 향후 릴리스에서 제거될 수 있습니다.대신
SET GLOBAL host_cache_size = 0같은 명령문을 사용하거나,my.cnf파일에서host_cache_size를 설정하십시오. (WL #14359) -
--old-style-user-limits옵션은 서버가 MySQL 5.0.3 이전과 같은 방식으로 사용자 제한을 적용하게 하며, 매우 오래된 릴리스와의 하위 호환성을 목적으로 합니다. 이 옵션은 이제 사용 중단되었으며, 이를 사용하면 이제 경고가 발생합니다. 이 옵션은 향후 MySQL 릴리스에서 제거될 것으로 예상해야 하며, 따라서 MySQL 애플리케이션이 이 옵션에 가질 수 있는 모든 의존성을 지금부터 제거하기 시작하는 것이 권장됩니다. (WL #13228)
Generated Invisible Primary Keys (GIPKs)
-
MySQL 8.0.30은 이제 GIPK 모드를 지원하며, 이는 명시적 기본 키 없이 생성되는 모든
InnoDB테이블에 생성된 보이지 않는 기본 키(GIPK)가 추가되도록 합니다. 이 개선 사항은InnoDB테이블에만 적용됩니다.GIPK 모드에 의해
InnoDB테이블에 추가되는 생성된 키 컬럼의 정의는 다음과 같습니다:my_row_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT INVISIBLE PRIMARY KEY생성된 기본 키의 이름은 항상
my_row_id입니다. GIPK 모드가 적용 중인 동안에는 명시적 기본 키를 포함하지 않는 한, 새InnoDB테이블을 생성하는CREATE TABLE문에서 이를 컬럼 이름으로 사용할 수 없습니다.GIPK는 기본적으로 활성화되지 않습니다. 이를 활성화하려면
sql_generate_invisible_primary_key서버 시스템 변수(이 릴리스에서 함께 도입됨)를ON으로 설정하십시오. 이 설정은 복제 적용자 스레드에는 영향을 주지 않습니다. 이는 소스에서 기본 키 없이 생성된 복제된 테이블에 대해 레플리카가 기본 키를 생성하지 않는다는 의미입니다.GIPK가 적용 중인 동안에는 한 가지 예외를 제외하고 생성된 보이지 않는 기본 키를 변경할 수 없습니다:
ALTER TABLE tbl CHANGE COLUMN my_row_id SET VISIBLE및ALTER TABLE tbl CHANGE COLUMN my_row_id SET INVISIBLE을 사용하여 GIPK의 가시성을 전환할 수 있습니다.기본적으로 생성된 보이지 않는 기본 키는
SHOW CREATE TABLE및SHOW INDEX의 출력에서 볼 수 있으며,COLUMNS및STATISTICS테이블과 같은 MySQL Information Schema 테이블에서도 볼 수 있습니다. 대신 이를 숨기려면show_gipk_in_create_table_and_information_schema를OFF로 설정할 수 있습니다.이 릴리스에서 추가된
--skip-generated-invisible-primary-key옵션을 사용하여 mysqldump 출력에서 생성된 보이지 않는 기본 키를 제외할 수 있습니다. mysqlpump도 이제 GIPK를 출력에서 제외하는--skip-generated-invisible-primary-key옵션을 지원합니다.자세한 정보와 예시는 Generated Invisible Primary Keys를 참조하십시오. MySQL의 보이지 않는 컬럼 지원에 대한 일반 정보는 Invisible Columns를 참조하십시오. (Bug #34092605, WL #13784)
Keyring 관련 사항
-
keyring_aws플러그인이 최신 AWS Encryption SDK for C(버전 1.9.186)를 사용하도록 업데이트되었습니다.keyring_aws_region변수는 새 SDK에서 지원하는 추가 AWS 리전을 지원합니다. 지원되는 AWS 리전 목록은 변수 설명을 참조하십시오. (WL #14547)
Performance Schema 관련 사항
-
InnoDB: InnoDB 읽기-쓰기 잠금에 대한 Performance Schema 계측에서 TRY(대기 없음) 작업의 잠금 획득 실패 및 성공이 잘못 계측되었습니다. (Bug #34131395)
-
Group Replication: Performance Schema는 이제 Group Replication 메모리 사용량의 성능 모니터링을 위한 계측을 제공합니다.
Performance Schema 메모리 계측을 사용한 Group Replication 메모리 사용량 모니터링을 참조하십시오. (WL #14726)
Pluggable Authentication 관련 사항
- SASL LDAP 플러그인이 Kerberos 설정 파일에서 읽은 Kerberos Key Distribution Center (KDC) 호스트 정보를 올바르게 파싱하지 못하여 SASL 인증 오류가 발생했습니다. (Bug #31862170)
보안 관련 사항
- 이제 지원되는 플랫폼에서 OpenSSL 3.0을 사용하여 MySQL 서버 패키지(mysqld +
libmysql+ 클라이언트 도구)를 컴파일할 수 있으며, 이는 서버 또는 클라이언트 프로그램의 동작을 변경하지 않아야 합니다. 추가 정보는 https://wiki.openssl.org/index.php/OpenSSL_3.0을 참조하십시오. (WL #14683)
공간 데이터 지원
- 이전에는 MySQL 8.0.13에서 추가된
ST_TRANSFORM()함수가 Cartesian Spatial Reference Systems를 지원하지 않았습니다. 이 릴리스부터 이 함수는 WGS 84 Pseudo-Mercator(SRID 3857)에 사용되는 Popular Visualisation Pseudo Mercator(EPSG 1024) 투영 방법을 지원합니다. (WL #11961)
SQL 문법 관련 사항
-
이제 실행할 수 없는
REVOKE문이 오류를 발생시킬지 경고를 발생시킬지 결정할 수 있습니다. 이는 간단한 설명과 함께 여기에 나열된 두 가지 새 문 옵션을 추가하여 구현됩니다:IF EXISTS는 대상 사용자 또는 역할이 존재하지 않는 한REVOKE가 오류가 아니라 경고를 발생시키도록 합니다.IGNORE UNKNOWN USER는 대상 사용자 또는 역할을 알 수 없지만 문이 그 외에는 성공하는 경우REVOKE가 오류 대신 경고를 발생시키도록 합니다.
제거할 단일 대상 사용자 또는 역할과 지정된 권한 또는 역할에 대해, 같은
REVOKE문에서IF EXISTS및IGNORE UNKNOWN USER옵션을 함께 사용하면, 문이 그 외에는 유효한 한 대상 사용자 또는 역할과 제거할 권한 또는 역할을 모두 알 수 없는 경우에도 문이 성공합니다(아무 작업도 하지 않고 경고를 발생시키더라도). 대상이 여러 개이거나, 제거할 권한 또는 역할이 여러 개이거나, 또는 둘 다인 경우, 문은 성공하며 유효한 제거 작업을 수행하고 유효하지 않은 항목에 대해서는 경고를 발행합니다.자세한 내용은 REVOKE Statement를 참조하십시오. (Bug #102232, Bug #32495441, WL #14690)
XA Transaction 관련 사항
-
Replication; Group Replication: 이전에는 복제 토폴로지의 서버 노드가
XA PREPARE,XA COMMIT또는XA ROLLBACK을 실행하는 동안 예기치 않게 중단된 경우 복구가 보장되지 않았습니다. 이 문제를 해결하기 위해, MySQL은 이제 서버 노드가 토폴로지에서 손실된 후 다시 복귀하는 경우 MySQL “classic” Replication 또는 MySQL Group Replication을 사용하여 토폴로지 전체에서 일관된 XA 트랜잭션 상태를 유지합니다. 이는 또한 서버 노드가 중단되고, 복구되고, 토폴로지에 다시 조인하는 경우 지정된 트랜잭션 내에서 작업을 수행하는 동안 노드가 서로 달라지지 않도록 XA 트랜잭션 상태가 이제 전파된다는 의미이기도 합니다.모든 다중 서버 복제 토폴로지(Group Replication을 사용하는 토폴로지 포함)의 경우 XA 트랜잭션 상태가 일관되게 전파되므로, 모든 서버가 항상 동일한 상태로 유지됩니다. 모든 크기의 이러한 토폴로지(바이너리 로깅이 활성화되어 있는 한 단일 서버 포함)의 경우, 이제 모든 서버가 예기치 않게 중단되고 토폴로지에서 이탈한 후 다시 조인하도록 만들어진 뒤에도 해당 서버를 일관된 상태로 복구할 수 있습니다.
이 향상 사항은 단일 서버의 경우 스토리지 엔진과 서버의 내부 트랜잭션 코디네이터(ITC) 사이에 2단계 XA prepare에 대한 지원을 추가하여 구현되며, prepare의 상태는 양쪽 모두에 유지됩니다. 이는 서버가 purge 이후 중단되더라도 상태를 잃을 위험 없이 ITC가 내부 로그를 안전하게 purge할 수 있음을 의미합니다. 단일 노드의 경우 스토리지 엔진과 바이너리 로그 사이에 실행 순서를 강제하면 해당 변경 사항이 스토리지 엔진에 표시되기 전에 GTID가 외부화되는 것을 방지합니다. 여러 서버로 구성된 토폴로지에서는 트랜잭션 상태가 로컬에서 일관되고 지속적임이 보장되기 전에 토폴로지로 브로드캐스트되지 않도록 합니다. 모든 경우에 XA 트랜잭션의 상태는 마지막으로 기록된 바이너리 로그 파일에서 추출되며 스토리지 엔진에서 얻은 트랜잭션 상태와 동기화됩니다.
이 릴리스의 알려진 문제는 동일한 트랜잭션 XID를 사용하여 XA 트랜잭션을 순차적으로 실행한 경우 발생할 수 있습니다. 이 동일한 XID를 사용하여
XA COMMIT... ONE PHASE를 처리하는 동안, 트랜잭션이 스토리지 엔진에서 prepared된 후 서버 작업에 중단이 발생하면 바이너리 로그와 스토리지 엔진 사이의 상태를 더 이상 신뢰할 수 있게 동기화할 수 없습니다.자세한 내용은 XA Transactions를 참조하십시오. (WL #11300)
추가되거나 변경된 기능
-
중요한 변경 사항: 시스템 curl 라이브러리에 링크하지 않고 curl을 포함하는 바이너리 패키지는 curl 7.83.1을 사용하도록 업그레이드되었습니다. (Bug #34138733)
-
중요한 변경 사항: OpenSSL 라이브러리가 번들로 제공되는 플랫폼의 경우, MySQL Server에 링크된 OpenSSL 라이브러리가 버전 1.1.1o로 업데이트되었습니다. OpenSSL 버전 1.1.1o에서 수정된 문제는 https://www.openssl.org/news/cl111.txt 및 https://www.openssl.org/news/vulnerabilities.html에 설명되어 있습니다. (Bug #34133985)
-
중요한 변경 사항:
authentication_fido플러그인과 함께 사용되는, MySQL에 포함된fido2라이브러리가 버전 1.8.0으로 업그레이드되었습니다. (이전에는 버전 1.5.0이 MySQL에 포함되었습니다.) (WL #15111) -
InnoDB: doublewrite 버퍼를 활성화하거나 비활성화하는
innodb_doublewrite시스템 변수에DETECT_ONLY및DETECT_AND_RECOVER라는 두 가지 새 설정이 추가되었습니다.DETECT_ONLY설정을 사용하면 데이터베이스 페이지 내용이 doublewrite 버퍼에 기록되지 않으며, 복구는 불완전한 페이지 쓰기를 수정하기 위해 doublewrite 버퍼를 사용하지 않습니다. 이 경량 설정은 불완전한 페이지 쓰기만 감지하기 위한 것입니다.DETECT_AND_RECOVER설정은 기존ON설정과 동일합니다. 자세한 내용은 Doublewrite Buffer를 참조하십시오.기여해 주신 Facebook에 감사드립니다. (Bug #32727919, Bug #103211, WL #14719)
-
InnoDB:
InnoDB는 이제 redo 로그 용량의 동적 설정을 지원합니다.innodb_redo_log_capacity시스템 변수는 redo 로그 파일이 차지하는 전체 디스크 공간을 늘리거나 줄이기 위해 런타임에 설정할 수 있습니다.이 변경으로 redo 로그 파일의 수와 기본 위치도 변경되었습니다. MySQL 8.0.30부터
InnoDB는 데이터 디렉터리의#innodb_redo디렉터리에 32개의 redo 로그 파일을 유지합니다. 이전에는InnoDB가 기본적으로 데이터 디렉터리에 두 개의 redo 로그 파일을 생성했으며, redo 로그 파일의 수와 크기는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). 이러한 변수 중 아무것도 설정되지 않은 경우, redo log 용량은innodb_redo_log_capacity기본값인 104857600바이트(100MB)로 설정됩니다.redo log 및 redo log 용량 크기 조정 작업을 모니터링하기 위해 여러 상태 변수가 제공됩니다.
일반적으로 모든 업그레이드에 요구되는 것처럼, 이 변경 사항은 업그레이드 전에 정상 종료를 필요로 합니다.
이 기능에 대한 자세한 내용은 Redo Log를 참조하십시오. (WL #12527)
-
Ubuntu 22.04 지원이 추가되었습니다. (Bug #34123545)
-
mysql스키마에 있는 몇몇 테이블의 기본 키 정의에서 컬럼 순서가 변경되어, 호스트 이름과 사용자 이름을 포함하는 컬럼이 기본 키의 시작 부분에 순서대로 함께 위치합니다. 이러한 테이블에 대한 ACL 쿼리는 호스트 이름과 사용자 이름만 사용하여 수행되며, 해당 컬럼이 순서대로 함께 있지 않으면 관련 레코드를 식별하기 위해 전체 테이블 스캔을 수행해야 합니다. 호스트 이름과 사용자 이름을 함께 배치하면 인덱스 조회를 사용할 수 있으므로,CREATE USER,DROP USER,RENAME USER문과 여러 권한을 가진 여러 사용자에 대한 ACL 검사 성능이 향상됩니다.변경된 테이블은
mysql.db,mysql.tables_priv,mysql.columns_priv및mysql.procs_priv입니다. MySQL 8.0.30 이상으로 업그레이드하면 이러한 테이블은 MySQL 업그레이드 프로세스의 두 번째 단계에서 수정됩니다. mysqldump 또는 mysqlpump와 같은 백업 또는 내보내기 유틸리티를 사용하여 논리적 업그레이드를 수행할 때--upgrade=FORCE옵션을 사용하십시오. 이 옵션은 테이블 구조가 검사되고 새 컬럼 순서로 다시 빌드되도록 보장합니다. (Bug #33644645, Bug #33637244, WL #14965) -
myisam_repair_threads시스템 변수와 myisamchk--parallel-recover옵션이 제거되었습니다. (Bug #31052408, WL #14938) -
새 mysqldump 옵션
--mysqld-long-query-time을 사용하면 mysqldump 세션에 대한long_query_time시스템 변수의 사용자 지정 값을 설정할 수 있습니다. 불필요한 로깅을 방지하기 위해, mysqldump의 쿼리가 슬로우 쿼리 로그 파일에 기록되기 전에 허용되는 경과 시간을 늘리려면 새 옵션을 사용하십시오. 기여해 주신 Facebook에 감사드립니다. (Bug #96369, Bug #96369, Bug #30110717, WL #13447) -
이제 오류 로그 컴포넌트는
InnoDB스토리지 엔진을 사용할 수 있게 되기 전에 시작 시 암시적으로 로드될 수 있습니다. 오류 로그 컴포넌트를 로드하는 이 새 메서드는log_error_services변수로 정의된 컴포넌트를 로드하고 활성화합니다.이전에는 오류 로그 컴포넌트를 먼저
INSTALL COMPONENT를 사용하여 설치해야 했으며, 로드할 컴포넌트 목록을InnoDB테이블인mysql.components테이블에서 읽었기 때문에InnoDB를 완전히 사용할 수 있게 된 후에만 로드되었습니다.오류 로그 컴포넌트의 암시적 로드는 다음과 같은 장점이 있습니다:
- 로그 컴포넌트가 시작 시퀀스 초기에 로드되어, 기록된 정보를 더 빨리 사용할 수 있게 됩니다.
- 시작 중 오류가 발생할 경우 버퍼링된 로그 정보의 손실을 방지하는 데 도움이 됩니다.
INSTALL COMPONENT를 사용하여 로그 컴포넌트를 로드할 필요가 없어, 오류 로그 설정이 단순해집니다.
이 기능에 대한 자세한 내용은 Error Log Configuration을 참조하십시오.
이전에
INSTALL COMPONENT를 사용하여 로드 가능한 로그 컴포넌트를 설치했으며, 시작 시 읽히는log_error_services설정(예: 옵션 파일)에서 해당 컴포넌트를 나열한 경우, 시작 경고를 방지하도록 설정을 업데이트해야 합니다. 자세한 내용은 Error Log Configuration Methods를 참조하십시오. (WL #14793) -
MySQL Enterprise Audit의 감사 로그 파일은 이제 선택적 데이터 필드로 확장되어 쿼리 시간, 송수신된 바이트 수, 클라이언트에 반환된 로우 수, 검사된 로우 수를 표시할 수 있습니다. 이 데이터는 조건에 부합하는 쿼리에 대해 슬로우 쿼리 로그에서 사용할 수 있으며, 감사 로그의 맥락에서도 마찬가지로 활동 분석을 위한 이상값을 탐지하는 데 도움이 됩니다. 이 데이터는 감사 로그 필터링 함수로 설정하는 새로운 컴포넌트 서비스를 통해 감사 로그에 전달됩니다. 확장된 데이터 필드는 감사 로그가 JSON 형식(
audit_log_format=JSON)일 때만 추가할 수 있으며, 이는 기본 설정이 아닙니다. (WL #14921) -
MySQL Server의
AES_ENCRYPT()및AES_DECRYPT()함수는 이제 함수에 전달하는 비밀번호 또는 암호 구문과 같은 정보에서 암호학적으로 강력한 비밀 키를 생성하기 위해 키 유도 함수(KDF)를 사용하는 기능을 지원합니다. 유도된 키는 데이터를 암호화하고 복호화하는 데 사용되며, MySQL Server 인스턴스에 남아 있고 사용자가 접근할 수 없습니다. KDF 사용은 함수 사용 시 직접 준비한 키를 지정하거나 더 단순한 방법으로 키를 유도하는 것보다 더 나은 보안을 제공하므로 적극 권장됩니다. 이 함수는 키 자료에 포함할 선택적 salt 및 컨텍스트별 정보를 지정할 수 있는 HKDF(OpenSSL 1.1.0부터 사용 가능)와, 선택적 salt를 지정하고 키를 생성하는 데 사용되는 반복 횟수를 설정할 수 있는 PBKDF2(OpenSSL 1.0.2부터 사용 가능)를 지원합니다. (WL #12669, WL #15188) -
새로운 시스템 상태 변수
Tls_library_version은 MySQL 인스턴스에 사용 중인 OpenSSL 라이브러리의 런타임 버전을 표시합니다. OpenSSL 버전은 TLSv1.3 지원과 같은 기능에 영향을 줍니다. (WL #13407) -
MySQL 8.0.30부터 MySQL Enterprise Encryption의 함수는
openssl_udf공유 라이브러리에서 설치되는 대신 컴포넌트에서 제공됩니다. 컴포넌트에서 제공되는 새로운 함수는 DSA 알고리즘 또는 Diffie-Hellman 키 교환 방법이 아니라 일반적으로 선호되는 RSA 알고리즘만 사용하며, 최소 키 크기에 대한 현재 모범 사례를 따릅니다. 또한 컴포넌트 함수는 다이제스트에 대한 SHA3 지원을 추가하며(OpenSSL 1.1.1이 사용 중인 경우), 서명에 다이제스트를 요구하지 않지만 이를 지원합니다.함수가
openssl_udf공유 라이브러리 파일에서 수동으로 설치된 이전 릴리스에서 MySQL 8.0.30으로 업그레이드하는 경우, 생성한 함수는 계속 사용할 수 있으며 지원됩니다. 그러나 이러한 레거시 함수는 이 릴리스부터 사용 중단되며, 대신 컴포넌트를 설치하는 것이 권장됩니다. 컴포넌트 함수는 이전 버전과 호환되므로, 레거시 함수에서 생성된 RSA 공개 키와 개인 키, 암호화된 데이터, 서명은 컴포넌트 함수와 함께 사용할 수 있습니다. 컴포넌트 함수가 레거시 함수에서 생성된 콘텐츠에 대해 복호화 및 검증을 지원하려면, 새로운 시스템 변수enterprise_encryption.rsa_support_legacy_padding을ON으로 설정해야 합니다(기본값은OFF입니다).컴포넌트 함수는 PKCS #8 형식의 공개 및 개인 RSA 키를 생성합니다. 이 함수는 최소 키 크기로 2048비트를 허용하며, 이는 현재 모범 사례에 적합한 최소 RSA 키 길이입니다. 시스템 변수
enterprise_encryption.maximum_rsa_key_size를 사용하여 최대 키 크기를 16384비트까지 설정할 수 있으며, 기본값은 최대 키 크기 4096비트입니다. (WL #15024) -
MySQL Server가
offline_mode시스템 변수 값을ON으로 변경하여 오프라인 모드로 설정될 때, 사용자가CONNECTION_ADMIN권한을 가진 연결은 종료되지 않습니다. 이전에는CONNECTION_ADMIN권한을 가진 연결을 확인하는 과정에서 다른 스레드에 접근해야 했으므로 경합 조건이 발생할 수 있었습니다. 이제 각 스레드의 플래그가 해당 스레드의 사용자에게CONNECTION_ADMIN권한이 있는지 여부를 캐시합니다. 사용자 권한이 변경되면 이 플래그가 갱신됩니다. 서버에 대해 오프라인 모드가 활성화되면 다른 스레드의 보안 컨텍스트가 아니라 각 스레드에 대해 이 플래그를 확인합니다. 이 변경으로 해당 작업은 스레드 안전하게 됩니다.또한 오프라인 모드가 활성화될 때, 사용자가
SYSTEM_USER권한을 가진 연결은 해당 작업을 실행하는 사용자도SYSTEM_USER권한을 가진 경우에만 이제 종료됩니다.SYSTEM_VARIABLES_ADMIN권한만 가지고SYSTEM_USER권한은 없는 사용자는offline_mode시스템 변수를ON으로 설정하여 오프라인 모드를 활성화할 수 있습니다. 그러나 이들이 작업을 실행할 때는, 사용자가CONNECTION_ADMIN권한을 가진 세션에 더해, 사용자가SYSTEM_USER권한을 가진 모든 세션도 연결 상태로 유지됩니다. 이는 작업 시점의 기존 연결에만 적용됩니다.SYSTEM_USER권한은 있지만CONNECTION_ADMIN권한은 없는 사용자는 오프라인 모드인 시스템에 새 연결을 만들 수 없습니다. (WL #14317)
수정된 버그
-
InnoDB:
TRUNCATE TABLE작업이ALGORITHM=INSTANT를 사용하여 삭제된 컬럼에 대한 데이터 딕셔너리 항목을 제거하지 못했습니다.기여해 주신 Marcelo Altmann에게 감사드립니다. (Bug #34302445)
-
InnoDB: 즉시 추가된 컬럼이 있는 테이블에서 nullable 컬럼 계산이 잘못되어 데이터가 잘못 해석되었습니다. (Bug #34243694)
-
InnoDB: MySQL 8.0.29로 업그레이드한 후 즉시 추가된 컬럼이 있는 테이블에 액세스하려고 할 때 실패가 발생했습니다. (Bug #34233264)
-
InnoDB: 즉시 추가된 컬럼의 물리적 위치만 로깅되었으며, 이는 인덱스 복구에 충분하지 않았습니다. 컬럼의 논리적 위치도 필요했습니다. (Bug #34181432)
-
InnoDB:
InnoDB소스의field_phy_pos디버그 변수는 cascading update 작업 중 자식 테이블에 대해 업데이트되지 않았습니다. (Bug #34181419) -
InnoDB: InnoDB 소스의
rec_get_instant_row_version_old()함수 일부 인스턴스가 로우 버저닝을 확인하지 않았습니다. (Bug #34173616) -
InnoDB: 로그 버퍼에서 바이트를 읽는 InnoDB 소스의
read_2_bytes()함수가 null 포인터를 반환했습니다. (Bug #34173425) -
InnoDB: 특정 잠금 시나리오에서 암시적 잠금이 예상대로 명시적 잠금으로 변환되지 않아
lock_rec_has_expl(LOCK_X | LOCK_REC_NOT_GAP, block, heap_no, trx) 디버그 assertion 실패가 발생했습니다. (Bug #34123159) -
InnoDB: 테이블에 즉시 추가된 컬럼이 있는지 확인하는 검사가 각 컬럼에 대해 수행되어, 컬럼 수가 많은 테이블에서
ADD및DROP COLUMN작업의 성능에 영향을 주었습니다. 이제 이 검사는 테이블당 한 번 수행됩니다. (Bug #34112147) -
InnoDB: 많은 수의 잠금 요청과 다수의 timeout을 생성하는 워크로드로 인해 긴 세마포어 대기 실패가 발생했습니다. 이 문제를 해결하기 위해 exclusive 전역 잠금 시스템 래치 수를 줄이는 최적화가 구현되었습니다. (Bug #34097862)
-
InnoDB: 단일 로그 쓰기 호출에서 기록된 여러 블록 중 첫 번째 블록에 설정되었던 redo log 블록 헤더의
m_flush_bit는 이점을 제공하지 않았으며 제거되었습니다. (Bug #34091444) -
InnoDB: 사용되지 않는 코드와 불필요한 검사의 제거를 포함하여 clang-tidy 및 cppcheck 경고를 수정했습니다. (Bug #33957087)
-
InnoDB: redo log 파일 mini-transaction(
mtr)의 복구가 작은innodb_log_buffer_size설정을 가진 MySQL Server 인스턴스에서 디버그 assertion 실패를 발생시켰습니다.기여해 주신 Mengchu Shi에게 감사드립니다. (Bug #33945602)
-
InnoDB:
WITH_VALGRIND소스 설정 옵션으로 컴파일하면Wunused-variable경고가 발생했습니다. (Bug #33899862) -
InnoDB: lock-free 해시 테이블(
ut_lock_free_hash_t)과 관련된 여러 문제가 해결되었습니다. (Bug #33830934) -
InnoDB: 보조 인덱스가 있는 생성 컬럼에 대한 쿼리로 인해 실패가 발생했습니다. 생성 컬럼의 위치를 나타내는 필드 번호가 유효하지 않았습니다. (Bug #33825077)
-
InnoDB: 다중 값 인덱스 컬럼이 있는 로우를 업데이트하고 삽입할 때 메모리 사용량이 예상보다 컸습니다. 각 로우 업데이트에 대해 다중 값 컬럼용으로 할당된 메모리가 파일 핸들이 해제될 때까지 유지되었습니다. (Bug #33766482)
-
InnoDB:
InnoDB소스의UT_LOCATION_HERE구조가 일관되게 사용되지 않았습니다. (Bug #33436161) -
InnoDB: 생성 컬럼의 값을 계산할 때 다중 값 인덱스 컬럼에서 값 배열을 가져오는 데 필요한 테이블 객체를 사용할 수 없었습니다. (Bug #32725063)
-
InnoDB: Windows 32-bit 시스템의 4GB 테이블스페이스 파일 크기 제한이 제거되었습니다. 이 제한은 테이블스페이스를 확장하는 동안 수행된 잘못된 계산 때문이었습니다. (Bug #28934351)
-
InnoDB:
InnoDB소스의 해시 및 난수 생성기 함수가 개선되었습니다. (Bug #16739204, Bug #23584861) -
InnoDB: 폐기된 테이블스페이스가 있는 테이블에 대한
DROP TABLE작업으로 인해 불필요한 assertion failure가 발생했습니다. (Bug #107207, Bug #34135187) -
InnoDB: 다중 값 인덱스를 추가한 후
JSON컬럼이 있는 테이블에 대한 쿼리가 부분 결과 집합만 반환했습니다. (Bug #106621, Bug #33917625) -
InnoDB: 여러 바이너리 대형 객체 값을 가진 레코드를 purge할 때 mini-transaction (mtr) 충돌로 인해 삽입 실패가 발생했습니다. (Bug #105592, Bug #33574272)
-
InnoDB: 동시성이 높은 인스턴스에서 adaptive hash index (AHI)를 활성화하면 해시 인덱스가 빌드되는 동안 일시적인 AHI search latch 경합이 발생했습니다.
패치를 제공해 준 Tencent의 CDB Team 소속 Zhou Xinjing에게 감사드립니다. (Bug #100512, Bug #31750840)
-
Packaging: SASL LDAP clientside 플러그인이 Windows용 MySQL Community 패키지에서 누락되었습니다.
-
복제: 레플리카에 추가 기본 키가 있었기 때문에 소스와 레플리카 간에 테이블 정의가 달라진 경우, 해당 테이블에 소스와 레플리카 모두에 존재하는 인덱스가 있으면 레플리카에서 업데이트와 삭제가 실패했습니다. InnoDB 테이블의 기본 키는 모든 인덱스에 자동으로 포함되며, 복제 적용기는 인덱스를 검색하기 위해 키의 모든 부분에 대한 값이 이벤트에 포함되어 있어야 합니다. 이전에는 적용기가 모든 사용자 정의 키 부분이 존재하는지 확인했지만, 해당 확인은 자동으로 포함된 숨겨진 기본 키를 포함하지 않았습니다. 이제 적용기는 인덱스를 사용하여 데이터를 검색하기 전에 사용자 정의 키 부분과 자동으로 포함된 키 부분이 모두 이벤트에 존재하는지 검증합니다. (Bug #34122738)
-
복제:
transaction_write_set_extraction시스템 변수가 활성화된 경우(기본값) MySQL Replication이 트랜잭션에서 추출하는 쓰기 세트는 기본 키, 고유 키, 외래 키에서 추출됩니다. 이는 트랜잭션 간의 종속성과 충돌을 감지하는 데 사용됩니다. 이전에는 다중 컬럼 외래 키와 관련된 쓰기 세트가 각 컬럼을 별도의 외래 키로 잘못 식별했습니다. 이제 이 문제가 수정되어 외래 키 쓰기 세트에 참조된 모든 키 컬럼이 포함됩니다. (Bug #34095747, Bug #34144531) -
Replication: 로우 기반 복제가 사용 중일 때, 복제본은 슬레이브의 추가 컬럼과 관련된 문제를 방지하려는 시도로 소스에서 보낸 SQL 모드 값을 때때로 재정의할 수 있었습니다. 극단적인 경우 이로 인해 데이터 불일치가 발생할 수 있었습니다. 복제본이 이제 가능한 경우 소스의 SQL 모드를 보존하도록 문제가 수정되었습니다. (Bug #33945038)
-
Replication: MySQL의 반동기 복제는
net_read_timeout시스템 변수 값을 따르지 않았으며 읽기 제한 시간을 1밀리초로 강제했습니다. 이로 인해 MySQL 시스템의 다른 연결은 올바르게 작동하는 동안, 해당 함수에서 승인 메시지의 부분 읽기가 발생하고 패킷이 순서와 다르게 도착할 수 있었습니다. 이제net_read_timeout시스템 변수 값이 반동기 복제용 연결에 적용됩니다. (Bug #101056, Bug #31976209) -
Replication:
--replicate-same-server-id옵션을 사용하여 복제본이 자체 서버 ID를 가진 이벤트를 건너뛰지 않도록 했을 때, 로그 파일이 로테이션되면 복제가 오류와 함께 중지되었습니다. 이제 로그 로테이션 이벤트는 옵션의 현재 값을 확인하고 적용합니다. (Bug #89375, Bug #27492990) -
Group Replication: Performance Schema 테이블
replication_group_member_stats의COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE컬럼이 이미 적용된 뷰 변경 이벤트(View_change_log_event)와 관련된 트랜잭션을 지속적으로 표시할 수 있었습니다. 이러한 이벤트는 Group Replication 어플라이어 채널에 큐잉되지만 Group Replication 복구 채널에서 적용되어, 카운터 감소가 손실될 수 있는 경쟁 조건을 유발했습니다. 이제 카운트 증가는 더 적합한 지점에서 수행되며, 어플라이어가 사용 중이 아닐 때COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE의 카운터도 이제 0으로 설정됩니다. (Bug #33602354, Bug #33674059) -
Group Replication: 멤버가 호환되지 않는 설정을 확인한 뒤 그로 인해 그룹을 떠나는 조인 중인 멤버와 같이, 멤버가 서비스 인프라와 상호 작용할 때 Group Replication에서 데드락이 발생할 수 있었습니다. 이 문제는 이제 수정되었습니다. (Bug #32688091)
-
Group Replication: 동일한 서버의 이전 인카네이션이 아직 존재하는 동안 멤버가 Group Replication 토폴로지에 다시 조인하려고 할 때 기록되는 메시지가 정보성 관련 사항에서 경고 메시지로 상향되었습니다. (Bug #32651024)
-
API: 이전에 MySQL 클라이언트 라이브러리를 사용하여 서버로 자동 재연결을 수행하던 애플리케이션은 서버가 업그레이드된 후 다음 mysql_query 오류를 받았습니다:
[4031] The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior. (Bug #105229, Bug #34007830)
-
조건을 파생 테이블로 푸시다운하는 작업이 모든 경우에 올바르게 처리되지 않았습니다. (Bug #34311090)
-
set 작업이 있는 파생 테이블로 조건을 푸시다운한 후, 항상 참인 불리언 조건을 폴딩하는 동안, set 작업이 있는 파생 테이블로 조건을 푸시다운하는 중 복사본을 만들 때 복제된 조건에 대해
abort_on_null을 true로 설정하지 않아 재작성 결과가 올바르지 않았습니다. (Bug #34298238) -
뷰 정의에서 유효하지 않은
ORDER BY표현식을 처리할 때 오류 반환이 누락되어 디버그 빌드에서 assert가 발생했습니다. (Bug #34239456) -
MySQL Server가 최신 버전의 Visual Studio 2022로 컴파일되지 않았습니다. (Bug #34231639)
-
조건 푸시다운 중 시스템 변수를 복제하려고 할 때, 서버가 복제된 표현식의 올바른 컨텍스트를 확인하지 못하는 경우가 있었습니다.
이를 방지하기 위해, 시스템 변수를 사용하는 파생 테이블이거나 파생 테이블의 기본 표현식에 시스템 변수가 포함된 경우 파생 테이블로의 조건 푸시다운을 허용하지 않습니다. (Bug #34205559)
-
Enterprise Linux 9 (EL9) 지원이 추가되었습니다. (Bug #34190004)
-
macOS 11에서 MySQL Server는 예기치 않은 서버 중단이 발생한 경우 코어 덤프를 생성하기 위한 올바른 entitlement를 가지고 있지 않았습니다. 빌드가 코어 덤프를 생성할 수 있도록 빌드 옵션 WITH_DEVELOPER_ENTITLEMENTS가 추가되었습니다. (Bug #34163987)
-
libevent-devel 또는 libedit-devel이 없는 시스템에서 '-DWITH_LIBEVENT=system' 및 '-DWITH_EDITLINE=system'에 대한 오류 처리가 개선되었습니다. (Bug #34131334, Bug #34123545)
-
MySQL 8.0.29의 Bug #33830493 수정은
SET PERSIST문을 사용하여 시스템 변수 설정을 기록한 직후 MySQL 인스턴스가 예기치 않게 중지되거나 재시작된 경우 설정 파일mysqld-auto.cnf가 비어 있는 상태로 남을 수 있으며, 이 경우 서버 재시작을 진행할 수 없는 상황을 처리했습니다. 이제 지속된 시스템 변수는 백업 파일에 기록되며, 쓰기가 성공했음이 확인된 후에만mysqld-auto.cnf로 이름이 변경되어 원래mysqld-auto.cnf파일이 계속 사용 가능한 상태로 남습니다. 재시작 시 유효한 내용이 있는 백업 파일이 발견되면 서버는 해당 파일에서 읽습니다. 그렇지 않으면mysqld-auto.cnf파일이 사용되고 백업 파일은 삭제됩니다. 이 수정에서는 파일이 디스크로 플러시되지 않았으므로, 문제가 여전히 발생할 수 있었습니다. 이 패치는 해당 작업을 추가합니다. (Bug #34122866) -
-DENABLE_GCOV CMake 옵션이 수정되었습니다. (Bug #34113243)
-
MySQL 8.0.29에서 도입된
SENSITIVE_VARIABLES_OBSERVER권한은 이제 업그레이드 중SYSTEM_VARIABLES_ADMIN권한을 가진 사용자에게 부여됩니다. 이전에는 업그레이드 중 어떤 데이터베이스 사용자에게도 이 권한이 부여되지 않았습니다. (Bug #34068378) -
left join을 사용한 뷰에서 select를 수행하면 결과가 반환되지 않았습니다. (Bug #34060289)
-
특정 상황에서
TRUNCATE performance_schema.accounts가global_status에 중복된 카운트를 발생시켰습니다.이는 일부 호스트가 인스트루먼트되지 않은 경우 발생했습니다. 예를 들어,
performance_schema_hosts_size가 낮은 값으로 설정된 경우입니다.기여해 주신 Yuxiang Jiang 및 Tencent 팀에 감사드립니다. (Bug #34057013, Bug #106939)
-
특정 조건에서
EXPLAIN ANALYZE가 존재하지 않는 이터레이터에 접근을 시도할 수 있었습니다. (Bug #34051681)참조: 이 문제는 다음 버그의 회귀입니다: Bug #33905399.
-
OpenSSL 3을 사용하여
keyring_oci플러그인을 컴파일하기 위한 지원이 추가되었습니다. (Bug #34043013) -
EXPLAIN ANALYZE에서 발견된 두 가지 문제가 수정되었습니다:- 실제 시간으로 표시되는 타이밍이 누적되지 않았습니다.
- 구체화된 테이블의 경우, 이제 출력에는 구체화된 테이블에서 읽은 로우 수가 아니라 구체화된 로우 수가 표시됩니다.
(Bug #34025798, Bug #34135465)
참조: 다음도 참조하십시오: Bug #33834146, Bug #34678179.
-
스레드 생성 및 삭제에 대해 Performance Schema 테이블에 기록된 이벤트가 클라이언트 연결이 종료될 때 제거되지 않고 서버 종료 시까지 유지되었습니다. 이제 스레드 생성 및 삭제는 사용자 세션에 대한 Performance Schema 계측이 생성된 후 발생하므로, 세션이 종료될 때 정리됩니다. (Bug #34019988)
-
번들로 제공되는 zlib 라이브러리가 zlib 1.2.12로 업그레이드되었습니다. 또한 zlib 1.2.12가 지원되는 최소 zlib 버전이 되었으며, WITH_SYSTEM_LIBS CMake 옵션에서 WITH_ZLIB이 제거되었습니다. (Bug #34015600)
-
CONNECTION_ID()함수는 세션 수명 동안 일정하게 유지되는 세션 ID를 반환하므로 상수 함수로 처리되었습니다. 이로 인해 다른 세션에서 재사용될 수 있는 테이블에 연결된 트리거 내부에서CONNECTION_ID()가 사용될 때 문제가 발생했습니다. 함수가 실행 시점에는const가 되도록 하고, 함수가 평가될 때 실제 세션 ID를 반환하도록 하여 이를 수정했습니다. (Bug #34009876) -
소스 코드에 대해
codespell을 실행하고, 코드 주석에서 보고된 맞춤법 오류를 수정했습니다. (Bug #34006439) -
MySQL Enterprise Encryption
openssl_udf함수 라이브러리 플러그인은 OpenSSL 3 API를 사용하도록 다시 구현되었습니다. (Bug #33992115) -
FEDERATED스토리지 엔진 코드는 NULL 포인터 및 변수 접근 문제를 해결하도록 수정되었습니다. (Bug #33962357) -
MySQL의 히스토그램은 버킷 밖에 있는 값에 대해
0의 선택도 추정값을 반환했습니다. 이는 샘플링 중 누락되었거나 히스토그램이 오래되어 값이 히스토그램에서 누락될 수 있음을 의미했습니다. 이를 방지하기 위해 히스토그램이 생성하는 선택도 추정값에 대해0.001의 상수 하한을 도입했습니다. 이 하한 선택은 샘플링 중 누락될 가능성이 있는 값 또는 범위의 선택도에 해당합니다.누락된 값의 선택도에 대해 통계적 추정값 대신 상수 하한을 사용하면 단순성과 예측 가능성이라는 장점이 있으며, 오래된 히스토그램 및 버킷 내 휴리스틱으로 인해 선택도를 과소평가하는 것을 어느 정도 방지할 수 있습니다.
MySQL의 히스토그램에 대한 자세한 내용은 Optimizer Statistics를 참조하십시오. (Bug #33935417)
-
공통 테이블 표현식(CTE)을 사용하는 특정 쿼리의 경우, CTE가 실행된 것으로 알려진 경우에도
EXPLAIN ANALYZE가 CTE에 대한 프로파일링 데이터를 제공하지 않았습니다. 이는 다음 조건이 충족될 때 발생했습니다:- CTE가 쿼리 플랜에서 두 번 이상 참조되었습니다.
- CTE에 대한 첫 번째 참조(
EXPLAIN FORMAT=TREE출력 순서 기준)가 한 번도 실행되지 않았습니다. - 이후 참조 중 하나 이상이 적어도 한 번 실행되었습니다.
문제는 CTE에 대한 첫 번째 참조를 만날 때 CTE 플랜이 항상 출력되었다는 점이었습니다. 해당 참조가 한 번도 실행되지 않은 경우 CTE는 그 위치에서 구체화되지 않았으며, 따라서 출력할 프로파일링 데이터가 없었습니다.
이 문제에 대한 수정은 CTE가 처음 실행될 때, 즉 구체화되는 시점에 CTE 플랜을 출력하도록 보장합니다. 그러면 출력에 프로파일링 데이터가 포함됩니다. CTE가 한 번도 실행되지 않으면 프로파일링 데이터가 없는 마지막 참조 지점에서 플랜을 출력합니다. (Bug #33905399)
-
이전에는
mysqld --verbose --help명령의 출력에서 플러그인 로드 옵션이 기본적으로 꺼져 있거나 옵션을 사용하여 꺼진 경우에도ON으로 표시되었습니다. 이제 출력에는 플러그인의 현재 값이 표시됩니다. (Bug #33870892) -
이제 서버는 curl(7.83.1)을 번들로 제공하며, EL7의 openssl11과 같은 대체 SSL 시스템이 사용되는 경우에만 이를 사용합니다. (Bug #33859507, Bug #34154806)
-
이제 Debug MySQL 바이너리를
-0g및-fno-inline을 사용하여 빌드할 수 있습니다. (Bug #33855533) -
MySQL 8.0.27에서 도입된
FIREWALL_EXEMPT권한은 이제 업그레이드 중SYSTEM_USER를 가진 사용자에게 부여됩니다. 이전에는 업그레이드 중 어떤 데이터베이스 사용자에게도 이 권한이 부여되지 않았습니다. (Bug #33854409) -
상관 서브쿼리가 예상대로 함수형 인덱스를 사용하지 않았습니다. 이는 서브쿼리 내부에서 사용된 외부 컬럼 참조가 서브쿼리 실행 시 상수로 간주되지 않아, 함수형 인덱스 고려가 건너뛰어질 수 있었기 때문에 발생했습니다.
서브쿼리를 실행하는 동안 외부 컬럼 참조가 상수로 간주되도록 보장하여 이 문제를 수정했습니다. (Bug #33851055)
-
EL7에서는 openssl11을, EL8에서는 openssl3을 WITH_SSL Cmake 옵션에 전달하여 대체 OpenSSL 시스템 패키지 지원을 추가했습니다. LDAP 및 Kerberos와 같은 Authentication 플러그인은 이러한 대체 OpenSSL 버전을 지원하지 않으므로 비활성화됩니다. (Bug #33835934)
-
테이블에 접근하지 않는 서브쿼리를 포함하지만 서브쿼리 평가에서 오류가 발생한 prepared statement가 디버그 빌드에서 assert 실패를 트리거했습니다. (Bug #33773799)
-
일부 stored function이 첫 번째 호출 이후 올바르게 실행되지 않았습니다. (Bug #33754993)
-
상수 조건자 제거 후 쿼리 표현식이 제거되는 재귀 common table expression(CTE)을 사용하여 쿼리를 수행할 때, CTE 임시 테이블에 대한 테이블 객체의 참조 카운트가 0에 도달하면 테이블을 다시 생성할 수 있어야 하지만, 특정 경우에는 테이블 참조 중 하나가 CTE에 연결된 것으로 올바르게 기록되지 않았습니다. (Bug #33725503)
참조: 다음도 참조하십시오: Bug #32962511.
-
파서에 누락된 오류 반환을 추가했습니다. (Bug #33725502)
-
MySQL 8.0.22에서 materialized derived table에 대한 조건 pushdown을 구현하기 위해 수행된 작업과 관련하여, outer reference를 사용하는 조건의 pushdown과 관련된 여러 문제가 식별되어 해결되었습니다. (Bug #33725403, Bug #33725500, Bug #33725508, Bug #33725534, Bug #33725545)
-
공통 테이블 표현식을 사용하는
SELECT에 대해 생성된 실행 계획에는 테이블 구체화와 구체화된 테이블에 대한 인덱스 스캔이 포함됩니다.temptable엔진은 아직 모든 인덱스 스캔 메서드를 지원하지 않으므로, 이러한 쿼리가 항상 올바르게 실행되지 않을 수 있습니다.다른 MySQL 엔진에서는 액세스 경로가 기본으로 간주되지 않을 때 구체화 액세스 경로에 대한 특수 처리가 있습니다.
temptable의 경우 인덱스 스캔이 기본으로 간주되지 않았으며, 이로 인해 정의되지 않은 동작이 발생했습니다.이 문제는 인덱스 스캔 액세스 경로를 기본으로 간주하여,
temptable테이블에서 어떤 인덱스 스캔 액세스 메서드도 사용하지 않도록 함으로써 수정했습니다. (Bug #33700735) -
InnoDB시스템 테이블스페이스에 새 데이터 파일을 추가한 후INFORMATION_SCHEMA.FILES테이블의Data_free컬럼이 업데이트되지 않았습니다. (Bug #33508534) -
플러그인이 기존 시스템 변수와 이름이 중복되는 시스템 변수를 등록하려고 하면, 기존 정적 시스템 변수가 덮어써질 수 있었고, 플러그인을 제거하면 해제된 메모리를 가리키는 포인터가 남을 수 있었습니다. 이 문제들은 이제 수정되었습니다. (Bug #33451101)
-
SHOW TABLES및SELECT * FROM INFORMATION_SCHEMA.TABLES는 사용자에게 개별 Performance Schema 테이블에 대한 접근 권한만 있는 경우 Performance Schema에서 아무 결과도 반환하지 않았습니다. (Bug #33283709) -
data_masking플러그인을 먼저 설치하지 않고 이 플러그인과 관련된 함수를 호출하면 계획되지 않은 서버 종료가 발생했습니다. 이 플러그인과 관련된 함수는 init 함수를 호출하여 초기화되며, init 함수는 다시 UDF 메타데이터 서비스에 접근하지만, 이는 data masking 플러그인이 설치된 경우에만 유효합니다. 이러한 함수를 초기화하기 전에 플러그인이 설치되어 있는지 확인하는 검사를 추가하고, 해당 함수를 제공하는 플러그인이 설치되어 있지 않으면 적절한 오류 메시지를 반환하도록 하여 이 문제를 수정했습니다. (Bug #33234046) -
특정 조건에서 서버가
max_execution_time의 만료 또는KILL문 실행을 올바르게 처리하지 않았습니다. (Bug #33218625) -
여러 스레드를 사용하여 서버에 연결하는 mysqlslap은 FIDO 인증을 사용하는 사용자 계정으로 실행할 수 없었습니다. 인증을 여러 스레드에서 수행할 수 있도록 FIDO 라이브러리를 업데이트하여 이 문제가 수정되었습니다. (Bug #33067183)
-
세션 중에
binlog_checksum시스템 변수에 잘못된 값이 설정된 경우, 같은 세션에서 소스로부터 바이너리 로그 스트림을 요청하기 위해 수행된 COM_BINLOG_DUMP 명령이 실패했습니다. 이제 서버는 체크섬 알고리즘 설정 프로세스를 시작하기 전에 지정된 체크섬 값을 검증합니다. (Bug #32442749) -
느린 쿼리 로깅의 경우, 문서와 달리 느린 쿼리 로그가 활성화되지 않으면
Slow_queries상태 변수가 구현되지 않았습니다. (Bug #28268680, Bug #91496) -
새 매개변수(
examined_row_count,affected_row_count,return_row_count)가 audit 플러그인에 추가되었습니다. 기여해 주신 J D께 감사드립니다. (Bug #110628, Bug #35267239) -
prepared statement가 빈 문자열을 유효한 float 값으로 허용할 수 있었으며, 이는 8.0.27 동작에서의 회귀입니다. 이 수정은 해석된 문자열의 길이가 비어 있지 않고 (float) 숫자로 완전히 해석되는지 명시적으로 확인합니다. 또한 새 검증은 이제 다음을 보장합니다:
- 모든 숫자 값은 빈 문자열 및 모두 공백인 문자열과 함께 지원됩니다.
- 일반 숫자 값뿐만 아니라 앞뒤에 공백이 있는 숫자 값도 지원됩니다.
(Bug #107399, Bug #34213338)
참조: 이 문제는 다음의 회귀입니다: Bug #32213576.
-
MySQL 8.0.29로 업그레이드하면 기존 공간 인덱스에 문제가 발생했습니다(Creating Spatial Indexes 참조). 문제의 근본 원인은 포함된 Boost 라이브러리에서 지리적 영역 계산이 수행되는 방식이 변경된 것이었으며, 이 라이브러리는 MySQL 8.0.29에서 버전 1.77.0으로 업그레이드되었습니다. 이러한 계산이 수행될 때마다 새 메서드를 수용하도록 보장하여 이 문제를 수정했습니다. (Bug #107320, Bug #34184111)
참조: 이 문제는 다음의 회귀입니다: Bug #33353637.
-
준비된 명령문에 대해 조건을 파생 테이블로 푸시다운할 때, 파생 테이블에 union이 포함된 경우 매개변수도 포함하는 조건을 복제합니다. 실행 중에 명령문을 다시 준비해야 하는 경우(예: 지정된 값의 signedness가 실제 데이터 타입의 signedness와 일치하지 않는 경우) 매개변수가 올바르게 복제되지 않아 오류가 발생했습니다. 이는 재파싱을 위해 문자열을 출력할 때 리터럴
?자리 표시자 문자가 아니라, 매개변수에 지정된 값이 사용되었기 때문에 발생했습니다.이제 이러한 경우 재파싱을 위해 매개변수를 출력할 때 플래그
QT_NO_DATA_EXPANSION을 설정하며, 이 플래그가 활성화되면 실제 값 대신?자리 표시자가 출력됩니다. (Bug #107230, Bug #34148712) -
MacOS에서 Homebrew에 대한 Boost 라이브러리 감지 로직을 개선했습니다.
-DWITH_BOOST가 설정된 경우에도 잠재적으로 호환되지 않는 시스템의 Boost 버전이 사용될 수 있었기 때문입니다. (Bug #107151, Bug #34121866)References: 이 문제는 다음의 회귀입니다: Bug #33769505.
-
RHEL 7.x에서 CPU 캐시 라인 크기를 가져오면 s390x RHEL 7.x에서 0이 반환되었으며, 이로 인해 rpl_commit_order_queue 및 integrals_lockfree_queue가 실패했습니다.
기여해 주신 Namrata Bhave님께 감사드립니다. (Bug #107081, Bug #34095278)
-
예기치 않은 서버 중단 이후 mysql 클라이언트가 서버에 다시 연결할 수 없을 때, 완성 해시를 빌드하는 프로세스에서 해제되지 않는 메모리가 할당되었습니다. 이제 재연결 작업은 클라이언트가 다시 연결하지 못하면 완성 해시를 빌드하지 않으며, 클라이언트 연결이 끊기면 관련 메모리가 해제됩니다. (Bug #106864, Bug #34019571)
-
s390x 아키텍처에 대한 사이클 타이머를 추가했습니다.
기여해 주신 Namrata Bhave님께 감사드립니다. (Bug #106824, Bug #33997819)
-
특정 경우에는 구체화가 포함된 세미조인을 실행할 때, 서브쿼리의
WHERE절에 동등 비교가 포함되어 있으면 잘못된 결과가 발생할 수 있었습니다. 이러한 동등 비교의 한쪽이IN또는NOT IN서브쿼리인 경우와 같은 일부 경우에는, 해당 동등 비교가 구체화된 서브쿼리로 푸시다운되지도 않았고 세미조인의 일부로 평가되지도 않았습니다. 이로 인해 일부 내부 해시 조인에서도 문제가 발생했습니다. (Bug #106710, Bug #106718, Bug #33952115, Bug #33957233)참조: 다음도 참조하십시오: Bug #84705, Bug #25466100.
-
(<date column> <non-date column>) IN ((val1, val2), (val3, val4), …)와 같은 쿼리의 비교 함수가 잘못된 결과를 반환할 수 있었습니다. (Bug #106567, Bug #33897969) -
SetOsLimitMaxOpenFiles의 assert 정의를 수정했습니다. 기여해 주신 hongyuan li에게 감사드립니다. (Bug #106555, Bug #33893197)
-
이전에는 동일한 null 허용되지 않는 표현식이
LIKE의 첫 번째 인수와 두 번째 인수로 모두 사용될 때 결과가 항상 true라고 가정했으며, 따라서 최적화로 제거될 수 있었습니다. 이 가정은 유효하지 않은 것으로 밝혀졌는데,ESCAPE가 지정되지 않은 경우에도LIKE가 백슬래시(\)를 이스케이프 문자로 처리한다는 사실 때문입니다. 이로 인해 조건이WHERE절에서 사용될 때와 달리SELECT목록에서 사용될 때 서로 다른 결과가 발생했습니다. 문제를 해결하기 위해, 이제ESCAPE절의 유무와 관계없이LIKE에 대해 이 최적화를 더 이상 수행하지 않습니다. (Bug #106444, Bug #33852756) -
일부 경우에 글로벌 트랜잭션 ID 이외의 인수(예: 컬럼 값)가
GTID_SUBSET()에 전달되면, 함수가 예상된NULL이 아닌 값을 반환했습니다. (Bug #106298, Bug #33793942) -
일반 정량 비교 조건자의 평가에서 조건자의 왼쪽이
NULL인 경우 문제가 발생했습니다. 이러한 경우 마지막 현재 로우에서 서브쿼리 평가 값이 저장되어 다시 평가할 필요가 없지만, 캐시된 값(result_for_null_param)이 실행 사이에 지워지지 않아 다음 실행에서 이전 실행의 결과를 다시 사용할 수 있었습니다. 이로 인한 한 가지 결과는, 서브쿼리 실행에서 먼저 서브쿼리의 로우가 하나도 일치하지 않았을 때(ALL조건자의 경우TRUE를 반환해야 함), 이후 실행에서 하나 이상의 로우가 일치해도FALSE가 예상되었음에도TRUE를 반환했다는 것입니다.이 문제를 해결하기 위해, 이제 실행 후 서브쿼리 조건자를 정리하는 동안
result_for_null_param을 반드시 지우도록 했습니다. (Bug #106164, Bug #33755139) -
--async-client옵션과 종료 명령으로 실행된 테스트 케이스로 인해 mysqltest가 예기치 않게 중단되었습니다. (Bug #105797, Bug #33643149) -
MySQL은 선택도 추정을 개선하기 위해 equiheight 히스토그램 사용을 지원합니다. 컬럼에 대한 equiheight 히스토그램의 각 버킷은 대략 동일한 수의 값(로우)을 포함해야 하며, 버킷을 작게 유지하면 오류를 최소화하는 데 도움이 됩니다.
equiheight 히스토그램을 구성할 때 때때로 너무 많은 값이 같은 버킷에 배치되어 선택도 추정에서 상당한 오류가 발생할 수 있었습니다. 낮은 오류를 보장하고 데이터 분포에 맞게 조정하여 버킷을 효율적으로 사용하는 새로운 equiheight 구성 알고리즘을 도입하여 이 문제를 수정했습니다. 또한 히스토그램 버킷의 고유 값 수에 대한 새로운 추정기는 개선된 최악의 경우 오류 보장을 제공합니다.
자세한 내용은 The INFORMATION_SCHEMA COLUMN_STATISTICS Table 및 Optimizer Statistics를 참조하십시오. (Bug #104789, Bug #33302021)
-
클라이언트 프로그램에 반환되는 사용 중단 경고가
stderr가 아니라stdout으로 전송되었으며, mysqldump의 경우 경고가 덤프 파일에 포함되어 덤프 파일이 더 이상 작동하지 않을 수 있었습니다. 이 문제가 이제 수정되었으며 경고는stderr로 전송됩니다. (Bug #104769, Bug #33733529) -
체인된 SSL 인증서에 대한 지원이 확장되었습니다. (Bug #54158, Bug #27491518)