---
title: "MySQL 8.0.38 릴리스 노트"
description: "MySQL 8.0.38 Community Server 릴리스 노트를 한국어로 번역하고, DBA가 참고해야 할 핵심 내용을 함께 정리하였습니다."
tags: [ MySQL, 릴리스노트 ]
image: "mysql-release-note.png"
author: "Oracle"
published: "2024-07-01"
updated: ""
source_url: "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-38.html"
---

## DBA를 위한 핵심 내용

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

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

## Performance Schema 관련 사항

- 특정 조건에서 경합 조건으로 인해 [`TABLE_HANDLES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-table-handles-table.html)가 사용하는 RAM 양이 최대 9GB까지 증가할 수 있었습니다. (Bug #36170903)
- prepared statement를 실행할 때 [`THREADS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-threads-table.html)의 `PROCESSLIST_INFO` 컬럼이 업데이트되지 않았습니다.

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

## Pluggable Authentication 관련 사항

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

## Thread Pool 관련 사항

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

## 수정된 버그

- **InnoDB:** [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 작업 후 [`UPDATE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/update.html)에서 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`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_index_corrupt)와 함께 거부됩니다. 또한 [`ER_IB_INDEX_PART_TOO_LONG`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_ib_index_part_too_long) 오류가 오류 로그에 보고됩니다. (Bug #35869747)

  참조: 함께 참조하십시오: Bug #34826861.
- **InnoDB:** 유효하지 않은 컬럼 인덱스를 참조하는 `InnoDB` assertion 오류가 컬럼 인덱스가 유효할 때 트리거되었습니다. (Bug #34800754)
- **InnoDB:** 빈 [`XA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/xa-statements.html) 트랜잭션에서, `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`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_parallel_read_threads)로 읽은 경우, 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`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_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`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_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`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#sysvar_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()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flow-control-functions.html#function_nullif), [`COALESCE()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/comparison-operators.html#function_coalesce), 그리고 shift ([`>>`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/bit-functions.html#operator_right-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()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/xml-functions.html#function_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`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html)이 때때로 계획되지 않은 종료를 초래했습니다. (Bug #36189820)
- 일부 [`CREATE USER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-user.html) 문이 올바르게 처리되지 않았습니다. (Bug #36022885)
- `ORDER BY` 및 `LIMIT`이 있는 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)의 경우, 옵티마이저가 먼저 매우 높은 비용의 전체 테이블 스캔을 선택한 다음 다른 검사를 수행하고 `perform_order_index` 유형의 경로를 사용했지만, 이것이 옵티마이저 계획의 비용에 반영되지 않았습니다. (Bug #35930969)
- 종료 중 클라이언트 연결이 항상 올바르게 종료되지 않았습니다. (Bug #35854919)

- 모든 내부 ACL 비트마스크 변수는 이제 명시적으로 32비트(`uint32_t`)입니다. (Bug #35507223)
- [`FIND_IN_SET()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/string-functions.html#function_find-in-set)에 함수형 인덱스를 추가할 수 없었습니다. (Bug #35352161)
- fulltext 인덱스가 있고 [`innodb_optimize_fulltext_only`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-parameters.html#sysvar_innodb_optimize_fulltext_only)가 활성화된 동일한 테이블에서 두 개의 동시 [`OPTIMIZE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/optimize-table.html) 문을 실행하면 때때로 서버가 종료되었습니다. (Bug #34929814)
- Valgrind에서 `authentication_kerberos`를 실행하는 동안 관찰된 메모리 누수를 제거했습니다. (Bug #34482788, Bug #36570929)
- (사용 중단된) 데이터 마스킹 플러그인에서 구현된 [`gen_range()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/data-masking-plugin-functions.html#function_gen-range-plugin) 함수가 항상 올바른 결과를 반환하지는 않았습니다.

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

  기여해 주신 Sho Nakazono에게 감사드립니다. (Bug #114507, Bug #36455468)

- deterministic stored function이 `return` 문 안에서 `JOIN ON`을 사용할 때 함수가 잘못된 결과를 반환할 수 있었습니다. 두 실행 사이에 예를 들어 [`FLUSH TABLES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/flush.html)로 인해 발생한 테이블 메타데이터 때문에 쿼리를 다시 준비해야 하는 경우, `ON` 절이 때때로 손실되었습니다. (Bug #114235, Bug #36379879)