MySQL 8.0.38 릴리스 노트

DBA를 위한 핵심 내용

MySQL 8.0.38은 InnoDB, Replication, Group Replication, Performance Schema, Thread Pool 등 운영 안정성 관련 수정이 많은 릴리스입니다. 다만 이후 8.0.39에서 8001개 이상 테이블 환경의 재시작 실패 회귀가 수정되었다는 점 때문에, DBA 관점에서는 8.0.38 단독 목표 버전으로 장기간 머무르는 전략은 신중해야 합니다.

8.0.39에서 수정된 “8001개 이상 테이블 생성 후 재시작 실패” 회귀를 고려하면, 테이블 수가 많은 운영 DB는 8.0.38에서 멈추지 말고 8.0.39 이상을 검토하는 것이 안전합니다.
binlog_row_image=MINIMAL과 JSON 기반 저장 생성 컬럼 조합에서 업데이트/삭제가 실패하던 문제, relay_log_space_limit 사용 시 GTID auto positioning이 무한 루프나 deadlock으로 이어지던 문제, binlog commit 중 incident 처리로 무기한 대기하던 문제가 수정되었습니다. 복제 지연·relay log 공간 제한·생성 컬럼 사용 환경은 업그레이드 테스트 가치가 높습니다.
Group Replication에서는 primary 호스트의 20초 이상 네트워크 비활성으로 secondary가 중단될 수 있던 문제, relay log rotation 직전 garbage collection으로 secondary applier가 멈출 수 있던 문제가 수정되었습니다. MGR 운영 환경에서는 네트워크 단절, primary failover, relay log rotation 테스트를 포함하십시오.
TABLE_HANDLES가 최대 9GB까지 메모리를 사용할 수 있던 race condition과 다수 읽기 전용 트랜잭션 상태에서 data_lock, data_lock_waits 조회 성능 문제가 수정되었습니다. 락 분석 쿼리를 운영 중 자주 실행하는 DBA는 모니터링 쿼리의 부하 변화를 확인해야 합니다.
ALTER TABLE 이후 UPDATE 중 서버 중단, 파티션 테이블을 innodb_parallel_read_threads=1로 읽을 때 256회 이후 성능 저하, SRID 공간 인덱스 결과 누락/강제 인덱스 사용 시 assertion, 동시 OPTIMIZE TABLE로 인한 종료 등이 수정되었습니다. DDL, GIS, fulltext, 파티션 사용 환경은 회귀 테스트 범위를 넓히는 것이 좋습니다.
별도 웹 검색에서는 이 버전 자체에 대해 공식 릴리스노트 밖의 광범위한 회귀 사례는 확인하지 못했습니다. 다만 8.0.39의 보정 항목 자체가 8.0.38 운영 리스크를 시사하므로, 가능하면 8.0.39 이상을 기준으로 검토하십시오.

Audit Log 관련 사항

Audit log에서 파일을 제거하거나 이름을 변경한 후 audit log pruning이 작동하지 않았습니다. 이제 이러한 경우에도 pruning이 계속되지만, 누락된 audit log 파일을 삭제할 수 없었다는 경고가 오류 로그에 출력됩니다. (Bug #35902913)

C API 관련 사항

C API 애플리케이션이 서버 측 prepared statement에 대한 결과를 수신하는 동안 중단되었습니다.

컴파일 관련 사항

번들로 제공되는 googletest 및 googlemock 소스를 버전 1.14.0으로 업그레이드했습니다. (Bug #36562482)
GenError에 대한 누락된 의존성을 추가했습니다. (Bug #36551721)
이제 Linux 시스템에서 -DWITH_TCMALLOC=BUNDLED를 지정하여 소스와 함께 제공되는 번들 tcmalloc 라이브러리를 사용해 MySQL을 빌드할 수 있습니다. 이는 Linux에서만 지원됩니다. (Bug #36313839)
이제 Enterprise Linux 8에서 MySQL을 빌드할 때 번들 tcmalloc()이 사용됩니다. (Bug #114844, Bug #35674008)
이제 Linux aarch64 플랫폼 바이너리는 페이지 크기에 4k 또는 64k를 사용하는 시스템 모두와의 호환성을 위해 patchelf --page-size=65536을 사용하여 빌드됩니다. (Bug #114233, Bug #36393794)

연결 관리 관련 사항

connection control 플러그인이 도입한 지연 후 conn_delay/Waiting in connection_control plugin stage가 재설정되지 않아 잘못된 모니터링 정보가 발생했습니다. (Bug #35205358)

데이터 딕셔너리 관련 사항

MySQL 5.7에서 8.0 이상으로 일반 컬럼과 생성 컬럼이 혼합된 MyISAM 테이블을 업그레이드하려고 하면 테이블 손상이 발생했습니다. (Bug #105301, Bug #33503328)

Performance Schema 관련 사항

특정 조건에서 경합 조건으로 인해 TABLE_HANDLES가 사용하는 RAM 양이 최대 9GB까지 증가할 수 있었습니다. (Bug #36170903)
prepared statement를 실행할 때 THREADS의 PROCESSLIST_INFO 컬럼이 업데이트되지 않았습니다.

기여해 주신 Daniel Lenski와 Amazon에 감사드립니다. (Bug #104121, Bug #33057164)

Pluggable Authentication 관련 사항

mysql_native_password 플러그인으로 인증할 때 발생하는 사용 중단 경고는 이제 한 번만 발생합니다. (Bug #35792948)

Thread Pool 관련 사항

연결 핸들러 스레드가 없는 스레드 그룹에 연결하면 멈췄습니다. 연결 스레드가 하나 이상 남아 있는 경우에만 연결 핸들러 스레드가 종료되도록 하여 이 문제를 수정했습니다. (Bug #36550125)

수정된 버그

InnoDB: ALTER TABLE 작업 후 UPDATE에서 MySQL이 예기치 않게 중단되었습니다. (Bug #36571091)

참조: 이 문제는 다음 버그의 회귀입니다: Bug #35183686.
InnoDB: 이제 로그 인덱스 크기 계산에서 컬럼 순서 변경을 고려합니다. (Bug #36526369)

참조: 이 문제는 다음 버그의 회귀입니다: Bug #35183686.
InnoDB: 이제 InnoDB가 수행하는 파일 시스템 작업은 디렉터리 변경 태스크를 수행할 때 상위 디렉터리에 대해 일관되게 fsync를 수행합니다. (Bug #36174938)
InnoDB: 디버그 빌드에서 innodb_interpreter_output 디버그 변수를 설정하면 서버가 예기치 않게 중단되었습니다. 이제 이 변수는 읽기 전용 변수입니다. (Bug #36041032)
InnoDB: redundant 로우 형식에 비해 너무 넓은 컬럼에 인덱스가 있는 상태로 생성된 테이블(MySQL 5.7.35 이전에는 허용됨)의 경우, 인플레이스 업그레이드가 테이블을 아무 알림 없이 임포트했지만 해당 테이블에 접근할 수 없었으며, 이로 인해 백업 생성이 방해되었습니다. 이제 잘못된 인덱스 사용과 관련된 모든 작업은 인덱스가 삭제될 때까지 ER_INDEX_CORRUPT와 함께 거부됩니다. 또한 ER_IB_INDEX_PART_TOO_LONG 오류가 오류 로그에 보고됩니다. (Bug #35869747)

참조: 함께 참조하십시오: Bug #34826861.
InnoDB: 유효하지 않은 컬럼 인덱스를 참조하는 InnoDB assertion 오류가 컬럼 인덱스가 유효할 때 트리거되었습니다. (Bug #34800754)
InnoDB: 빈 XA 트랜잭션에서, XA START 이후 서버를 종료하면 서버가 예기치 않게 중단되었습니다. (Bug #32416819)
InnoDB: 빈 XA 트랜잭션을 처리하는 동안 replication applier 또는 binlog applier를 종료하면 시스템이 예기치 않게 중단되었습니다. (Bug #32416819)
InnoDB: Validate_files::check() 함수에서 불필요한 heap 사용을 제거했습니다.

기여해 주신 Huaxiong Song에게 감사드립니다. (Bug #115041, Bug #36626203)
InnoDB: 파티션 테이블을 innodb_parallel_read_threads=1로 읽은 경우, 256회 읽기 후 모든 테이블에서 읽기 성능이 크게 저하되었습니다. InnoDB는 병렬 읽기 스레드를 전혀 사용하지 않았음에도 병렬 읽기 스레드의 최대 용량에 도달한 것처럼 동작했습니다.

기여해 주신 Ke Yu에게 감사드립니다. (Bug #114154, Bug #36347408)
InnoDB: 공간 참조 식별자(SRID) 속성이 있는 컬럼을 포함하는 공간 인덱스의 결과가 비어 있었습니다. 또한 FORCE INDEX를 사용하여 공간 인덱스에서 커버링 인덱스 스캔을 강제하면 assertion이 발생했습니다. (Bug #112676, Bug #114200, Bug #35894664, Bug #36361834)
InnoDB: 읽기 전용 트랜잭션 수천 개가 존재할 때 data_lock 및 data_lock_waits 테이블을 쿼리하는 것과 관련된 성능 문제가 수정되었습니다. (Bug #109539, Bug #34951273)
Replication: 소스에 JSON 함수로 채워지는 저장된 생성 컬럼이 포함되어 있고 binlog_row_image가 MINIMAL로 설정된 경우, 기반 컬럼에 대한 이후의 업데이트 또는 삭제는 다음 오류와 함께 실패했습니다:
```
        Invalid JSON text in argument 1 to function json_extract: 'The document is empty.'
      
```
레플리카는 생성 컬럼을 다시 평가하려고 시도했으며, 기반 컬럼을 사용할 수 없었기 때문에 해당 오류와 함께 실패했습니다. 이 릴리스부터는 기반 컬럼을 사용할 수 없을 때 저장된 생성 컬럼이 다시 평가되지 않습니다. (Bug #36515172)
Replication: GTID 기반 복제를 relay_log_space_limit을 활성화한 상태로 실행할 때, auto positioning 프로토콜의 재시작이 때때로 무한 루프로 이어져 복제에서 deadlock이 발생했습니다. 이는 크기가 이 제한을 초과하는 트랜잭션뿐만 아니라 복제본이 이전 로그를 purge할 수 없는 경우에도 relay_log_space_limit가 준수되지 않았기 때문입니다.

이 문제를 수정하기 위해 다음과 같이 변경했습니다:
- receiver는 receiver가 수신한 트랜잭션이 purge된 relay log에 들어갈 수 없는 경우를 제외하고, 사용자가 설정한 relay_log_space_limit를 준수합니다. receiver는 이제 수신한 트랜잭션을 큐에 넣기 전에 전체 트랜잭션을 스케줄링할 수 있는지 확인합니다. 가능하지 않으면 receiver는 다음 작업을 수행합니다:
  - receiver가 대기 중임을 나타내는 플래그를 설정합니다
  - relay log를 rotate합니다
  - relay log purge가 실행되었고 applier가 사용 가능한 모든 relay log를 purge했다는 알림을 받을 때까지 대기합니다. 이후 receiver는 제한을 다시 확인하지 않고 트랜잭션을 큐에 넣을 수 있습니다
다음 파일로 이동하기 전에 coordinator는 receiver가 사용 가능한 relay log 공간을 기다리고 있는지 확인합니다. 그렇다면 coordinator는 현재 relay log 파일을 포함하여 적용된 로그를 강제로 purge합니다. 현재 relay log 파일을 안전하게 purge하려면 coordinator가 다음을 수행해야 합니다:
- 다음 파일로 이동하기 전에 모든 worker를 동기화합니다.
- relay log의 현재 purging을 허용하는 데 필요한 group position을 강제로 업데이트합니다.
- applier가 이동한 relay log 파일명을 포함하고 receiver가 읽는 변수를 업데이트합니다.
이러한 작업은 receiver가 트랜잭션 경계에서 대기하고, 대기하기 전에 relay log를 rotate한다는 것을 알고 있기 때문에 허용됩니다.

(Bug #36507020)
Replication: Worker job은 이제 relay_log에서 정의한 기본값을 사용하는 대신, 트랜잭션을 시작한 relay log 파일에 대한 정보를 포함합니다. (Bug #36395631)
Replication: 트랜잭션이 바이너리 로그에 커밋되는 동안 incident를 처리하면 MySQL이 무기한 대기했습니다. (Bug #35671897)
Group Replication: /xcom/gcs_xcom_networking.cc에서 메모리 leak을 제거했습니다. (Bug #36532199)
Group Replication: 특정 상황에서 primary의 호스트에 20초 이상의 네트워크 비활성이 발생하면 secondary가 예기치 않게 중지될 수 있었습니다. (Bug #36306144)
Group Replication: 특정 상황에서 릴레이 로그 로테이션 직전에 가비지 컬렉션이 발생하면, applier가 secondary 멤버에서 새 트랜잭션 적용을 중지할 수 있었습니다.

이는 가비지 컬렉션이 릴레이 로그의 last_committed 및 sequence_number를 증가시켜, 로그 로테이션 후 기록된 sequence_number에 간격을 만들었기 때문에 발생했습니다. 릴레이 로그의 다른 위치에서 간격이 발생한 경우에는 applier가 영향을 받지 않았습니다.

이 릴리스부터 가비지 컬렉션 중에는 last_committed만 업데이트됩니다. (Bug #36280130, Bug #36446250)
JSON: NULLIF(), COALESCE(), 그리고 shift (>>) 연산자에 오류 처리를 위한 누락된 검사를 추가했습니다. (Bug #113668, Bug #35513196, Bug #36198403)

참조: 다음도 참조하십시오: Bug #31358416.
MySQL NDB ClusterJ: ClusterJ 테스트 스위트를 실행하면 여러 스레드가 존재하지 않는다는 오류 메시지가 발생했습니다. 이는 스레드와 연결을 잘못 처리했기 때문이며, 이 패치로 수정되었습니다. (Bug #36086735)
특정 숫자의 평균이 항상 올바르게 계산되지는 않았습니다. (Bug #36563773)
strings의 다음 파일에 잘못된 라이선스 정보가 포함되어 있었습니다:
- mb_wc.h
- ctype-uca.cc
- ctype-ucs2.cc
- ctype-utf8.cc
- dtoa.cc
- strxmov.cc
- strxnmov.cc
(Bug #36506181)
특정한 일반적이지 않은 경우에 UpdateXML() 함수가 모든 인수를 올바르게 처리하지 않았습니다. (Bug #36479091)
SRID 속성이 있는 컬럼을 포함하는 공간 인덱스에서 FORCE INDEX를 사용한 쿼리를 설명하면 계획되지 않은 종료가 발생했습니다. (Bug #36418426)
표현식의 참조 횟수를 증가시킬 때, 이 표현식 내의 기반 표현식은 살펴보지 않았습니다. 표현식을 제거하는 동안 참조 횟수를 감소시킨 후에는 기반 표현식까지 검사했으며, 이로 인해 기반 표현식이 의도치 않게 삭제되었습니다. 이 문제는 Item_ref::real_item()뿐 아니라 sql/item.h의 assert에서도 나타났습니다. 현재 표현식에 남아 있는 유일한 참조가 포함되어 있지 않은 한 기반 표현식을 살펴보지 않도록 하여 이 문제를 수정했습니다. (Bug #36204344, Bug #36356279)
특정 조건에서 EXPLAIN FORMAT=JSON FOR CONNECTION이 때때로 계획되지 않은 종료를 초래했습니다. (Bug #36189820)
일부 CREATE USER 문이 올바르게 처리되지 않았습니다. (Bug #36022885)
ORDER BY 및 LIMIT이 있는 SELECT의 경우, 옵티마이저가 먼저 매우 높은 비용의 전체 테이블 스캔을 선택한 다음 다른 검사를 수행하고 perform_order_index 유형의 경로를 사용했지만, 이것이 옵티마이저 계획의 비용에 반영되지 않았습니다. (Bug #35930969)
종료 중 클라이언트 연결이 항상 올바르게 종료되지 않았습니다. (Bug #35854919)
모든 내부 ACL 비트마스크 변수는 이제 명시적으로 32비트(uint32_t)입니다. (Bug #35507223)
FIND_IN_SET()에 함수형 인덱스를 추가할 수 없었습니다. (Bug #35352161)
fulltext 인덱스가 있고 innodb_optimize_fulltext_only가 활성화된 동일한 테이블에서 두 개의 동시 OPTIMIZE TABLE 문을 실행하면 때때로 서버가 종료되었습니다. (Bug #34929814)
Valgrind에서 authentication_kerberos를 실행하는 동안 관찰된 메모리 누수를 제거했습니다. (Bug #34482788, Bug #36570929)
(사용 중단된) 데이터 마스킹 플러그인에서 구현된 gen_range() 함수가 항상 올바른 결과를 반환하지는 않았습니다.

이 문제는 데이터 마스킹 플러그인에만 영향을 미쳤으며, 이를 대체하는 데이터 마스킹 컴포넌트에는 영향을 미치지 않았습니다. (Bug #34163992)
include/my_command.h의 잘못된 주석을 수정했습니다.

기여해 주신 Sho Nakazono에게 감사드립니다. (Bug #114507, Bug #36455468)
deterministic stored function이 return 문 안에서 JOIN ON을 사용할 때 함수가 잘못된 결과를 반환할 수 있었습니다. 두 실행 사이에 예를 들어 FLUSH TABLES로 인해 발생한 테이블 메타데이터 때문에 쿼리를 다시 준비해야 하는 경우, ON 절이 때때로 손실되었습니다. (Bug #114235, Bug #36379879)