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

## DBA를 위한 핵심 내용

MySQL 8.0.31은 `INTERSECT`/`EXCEPT`, 히스토그램 JSON 주입, 메모리 사용량 Performance Schema 지표, Thread Pool 제어 기능 등 기능 추가가 많은 릴리스입니다. DBA 관점에서는 복제 필터·권한 검사 순서 변경, XA 필터링 수정, Group Replication 채널 보호, INSTANT DDL 후속 버그 수정이 더 중요합니다. 새 SQL 문법과 Optimizer 내부 변경이 큰 릴리스이므로, 복잡한 UNION/파생 테이블/윈도우 함수/CTE 쿼리는 회귀 테스트 범위에 포함해야 합니다.

1. 복제 필터가 적용된 뒤 권한 검사와 `require_row_format` 검증이 수행되도록 바뀌어, 필터로 제외될 이벤트 때문에 레플리카가 중단되는 사례가 줄었습니다. 제한 권한 applier 계정이나 마이그레이션용 필터링 구성을 쓰는 환경에서 유용합니다.
2. `--replicate-do-db`/`--replicate-ignore-db`가 XA START/END/COMMIT/ROLLBACK을 잘못 필터링해 레플리카 중단 또는 prepared XA 잔류를 만들 수 있던 문제가 수정되었습니다. XA와 DB 단위 필터를 함께 쓰는 토폴로지는 우선 적용 대상입니다.
3. Group Replication 실행 중 `group_replication_applier` 채널에 대한 수동 `START REPLICA`/`STOP REPLICA`가 금지되어, 원격 트랜잭션 커밋 불능 상태를 예방합니다. 기존 운영 스크립트가 해당 채널을 직접 조작하지 않는지 확인하십시오.
4. Performance Schema와 sys 스키마에 statement/thread/session 단위 메모리 최대값 지표가 추가되었고, Thread Pool에는 트랜잭션 지연·쿼리 스레드 수·트랜잭션 제한 관련 기능이 확대되었습니다. 고동시성 환경에서 병목 분석과 긴급 접속 권한 설계에 활용할 수 있습니다.
5. `INTERSECT`, `EXCEPT`, 괄호 쿼리 표현식, JSON 기반 히스토그램 주입이 추가되었습니다. 동시에 관련 Optimizer 코드 변경이 크므로, 집합 연산·파생 테이블·CTE·윈도우 함수가 포함된 핵심 리포트 SQL은 업그레이드 전후 결과와 실행 계획을 비교하십시오.
6. 별도 웹 검색에서는 이 버전 자체에 대해 공식 릴리스노트 밖의 널리 알려진 대규모 회귀나 업그레이드 장애는 확인하지 못했습니다. 핵심은 새 SQL 기능과 복제/XA/Group Replication 동작 변경의 내부 검증입니다.

## Audit Log 관련 사항

- [`audit_log_rotate()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-reference.html#function_audit-log-rotate) 함수는 감사 로그 파일 로테이션을 단순화합니다. 이전에는 감사 로그 파일 로테이션에 파일 이름을 수동으로 변경하고 [`audit_log_flush = ON`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-reference.html#sysvar_audit_log_flush)을 설정하여 파일을 닫고 원래 이름으로 새 로그 파일을 여는 작업이 필요했습니다. `audit_log_rotate()` 함수는 현재 파일의 이름을 변경하고 새 파일을 생성합니다. 감사 로그 파일의 이름을 수동으로 변경할 필요가 더 이상 없습니다.

  [`audit_log_flush`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/audit-log-reference.html#sysvar_audit_log_flush) 변수는 MySQL 8.0.31부터 사용 중단되었습니다. 향후 MySQL 버전에서 이에 대한 지원이 제거될 것으로 예상하십시오. (WL #15249)

## 컴파일 관련 사항

- **Microsoft Windows:** 더 이상 사용되지 않는 C++ STL 기능을 사용하지 않음으로써 모든 C++ 사용 중단 경고를 수정했습니다. (Bug #33985941)
- 내부 Performance Schema 함수 이름을 _utf8*에서 _utf8mb4*로 변경했습니다. 이 함수들은 v8.0.11부터 utf8mb4를 사용해 왔습니다. (Bug #34351301)

  참조: 다음도 참조하십시오: Bug #27407745.
- LLVM bug #16404에 설명된 LLVM/Clang 관련 정수 문제를 우회하기 위해 clang/ubsan용 링커 플래그를 수정했습니다. (Bug #34311325)
- 향후 호환성을 위해 헬퍼 스크립트를 업데이트하여 캐릭터셋/콜레이션에 'utf8' 대신 'utf8mb3'를 사용하도록 했습니다.

  utf8mb3 캐릭터셋 및 콜레이션을 처리하는 데 사용되는 함수와 데이터 구조의 이름을 변경하여 해당 utf8mb3 사용을 더 명확히 했습니다. (Bug #34263480, Bug #34025412)
- CMake 코드를 정리하고 INFO_BIN 및 INFO_SRC를 단순화했습니다. (Bug #34139084)

## 컴포넌트 관련 사항

- 이제 새 컴포넌트 서비스는 서버 컴포넌트와 플러그인이 로컬 서버 내에서 쿼리할 수 있게 합니다. 새 MySQL 명령 서비스는 `libmysql`의 C API 함수와 유사하지만, 프로토콜 내부를 클라이언트에 노출하지 않는다는 점이 다릅니다. 이러한 서비스에 대한 자세한 내용은 https://dev.mysql.com/doc/index-other.html 에서 제공되는 MySQL Server Doxygen 문서를 참조하십시오. 다음을 검색하십시오:

  - `s_mysql_mysql_command_factory`
  - `s_mysql_mysql_command_options`
  - `s_mysql_mysql_command_query`
  - `s_mysql_mysql_command_query_result`
  - `s_mysql_mysql_command_field_info`
  - `s_mysql_mysql_command_error_info`

  (WL #14293)

## 사용 중단 및 제거 관련 사항

- `keyring_oci` 플러그인은 사용 중단되었으며, MySQL의 향후 릴리스에서 제거될 수 있습니다. 대신 keyring 데이터를 저장하기 위해 `component_keyring_oci` 컴포넌트 사용을 고려하십시오([Using the Oracle Cloud Infrastructure Vault Keyring Component](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/keyring-oci-component.html) 참조). (WL #14943)

## Keyring 관련 사항

- MySQL Keyring은 이전에 서버 플러그인을 사용하여 Oracle Cloud Infrastructure Vault Keyring 키스토어 기능을 구현했지만, 이제 MySQL 컴포넌트 인프라스트럭처를 사용하도록 전환하고 있습니다. 새 keyring 컴포넌트는 기존 `keyring_oci` 플러그인과 유사점이 있지만, 다르게 설정되며 새 컴포넌트를 초기화하는 데 유사한 설정 옵션 집합이 사용되는 경우 `keyring_oci` 플러그인을 사용하여 생성된 키에 액세스할 수 있습니다. 설정 세부 사항은 [Using the Oracle Cloud Infrastructure Vault Keyring Component](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/keyring-oci-component.html)를 참조하십시오.

  `component_keyring_oci`는 시작 중 [`--early-plugin-load`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-options.html#option_mysqld_early-plugin-load) 서버 옵션을 사용하여 로드되지 않으며, 시스템 변수를 사용하여 시작 중 또는 런타임에 설정되지 않습니다:

  - 시작 중에는 서버가 매니페스트 파일을 사용하여 로드할 keyring 컴포넌트를 결정하고, 로드된 컴포넌트는 초기화될 때 자체 설정 파일을 참조합니다. [Keyring Component Installation](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/keyring-component-installation.html)을 참조하십시오.
  - 런타임에는 [`ALTER INSTANCE RELOAD KEYRING`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-instance.html#alter-instance-reload-keyring) 문을 통해 설정 파일 변경 후 설치된 keyring 컴포넌트를 다시 설정할 수 있습니다. [ALTER INSTANCE Statement](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-instance.html)을 참조하십시오.

  keyring 컴포넌트가 설치되어 있으면 Performance Schema [`keyring_component_status`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-keyring-component-status-table.html) 테이블이 해당 컴포넌트에 대한 상태 정보를 제공합니다. [The keyring_component_status Table](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-keyring-component-status-table.html)을 참조하십시오. (WL #14943)

## Optimizer 관련 사항

- **중요한 변경:** MySQL Optimizer의 집합 연산 내부 관리가 개선되었으며, 다음과 같은 효과가 있습니다:

  - 괄호로 묶인 쿼리 표현식의 본문을 이제 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html)과 함께 조합하여 중첩할 수 있습니다. 예를 들어, 여기에 표시된 쿼리는 이전에는 [`ER_NOT_SUPPORTED_YET`](https://docs.oracle.com/cd/E17952_01/mysql-errors-8.0-en/server-error-reference.html#error_er_not_supported_yet) 오류로 거부되었지만, 이제 허용됩니다:

    ```
    ( 
      (SELECT a, b, c FROM t ORDER BY a LIMIT 3) ORDER BY b LIMIT 2
    ) ORDER BY c LIMIT 1;
    ```
  - 괄호로 묶인 표현식 본문을 축약할 때, MySQL은 이제 SQL 표준에 지정된 의미 체계를 따르므로, 더 높은 외부 제한이 더 낮은 내부 제한을 재정의할 수 없습니다. 이는 표현식 `(SELECT... LIMIT 3) LIMIT 5`가 최대 세 로우를 반환할 수 있음을 의미합니다.
  - `UNION DISTINCT` 및 `UNION ALL`은 이제 임의의 조합으로 중첩될 수 있습니다.

  방금 나열한 모든 경우에서 지원되는 최대 중첩 레벨은 63입니다. 이는 파서가 수행하는 단순화 또는 병합 이후에 적용됩니다. 자세한 내용은 [Parenthesized Query Expressions](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/parenthesized-query-expressions.html)를 참조하십시오. (Bug #103954, WL #11350)
- 파생 테이블에서 [`JOIN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/join.html) 연산의 테이블을 가리키는 외부 참조가 서브쿼리에서 사용할 수 없었음에도 (잘못) 유효한 것으로 보고되었지만, 파생 테이블이 없는 이러한 참조는 올바르게 유효하지 않은 것으로 보고되었습니다.

  관련 문제로, [`INSERT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/insert.html) 문의 `VALUES` 절 내부에 배치된 파생 테이블에 대한 외부 참조가 유효한 것으로 인식되지 않았지만, 파생 테이블이 없는 유사한 참조는 그렇게 인식되었습니다. 이제 파생 테이블에 대한 이러한 참조는 `VALUES` 내에서 허용됩니다.

  두 경우 모두, 외부 참조에 올바른 이름 해석 컨텍스트가 사용되도록 하여 문제를 수정했습니다. (Bug #32678303, Bug #34131822)

## Performance Schema 관련 사항

- Performance 스키마와 sys 스키마는 이제 MySQL 8.0.28에서 도입된 전역 및 세션 메모리 제한에 대한 메트릭을 노출합니다.

  Performance Schema의 테이블에 다음 컬럼이 추가되었습니다:

  - [`SETUP_INSTRUMENTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-setup-instruments-table.html):

    - `FLAGS`
  - [`THREADS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-threads-table.html):

    - `CONTROLLED_MEMORY`
    - `MAX_CONTROLLED_MEMORY`
    - `TOTAL_MEMORY`
    - `MAX_TOTAL_MEMORY`
  - [`EVENTS_STATEMENTS_CURRENT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-current-table.html), [`EVENTS_STATEMENTS_HISTORY`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-history-table.html), 및 [`EVENTS_STATEMENTS_HISTORY_LONG`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-events-statements-history-long-table.html):

    - `MAX_CONTROLLED_MEMORY`
    - `MAX_TOTAL_MEMORY`
  - [Statement Summary Tables](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-statement-summary-tables.html):

    - `MAX_CONTROLLED_MEMORY`
    - `MAX_TOTAL_MEMORY`
  - [Performance Schema Connection Tables](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-connection-tables.html):

    - `MAX_SESSION_CONTROLLED_MEMORY`
    - `MAX_SESSION_TOTAL_MEMORY`
  - [`PREPARED_STATEMENTS_INSTANCES`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-prepared-statements-instances-table.html):

    - `MAX_CONTROLLED_MEMORY`
    - `MAX_TOTAL_MEMORY`

  sys 스키마 [`STATEMENT_ANALYSIS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-statement-analysis.html) 및 [`X$STATEMENT_ANALYSIS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/sys-statement-analysis.html) 뷰에 다음 컬럼이 추가되었습니다:

  - `MAX_CONTROLLED_MEMORY`
  - `MAX_TOTAL_MEMORY`

  [`SETUP_INSTRUMENTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-setup-instruments-table.html) 테이블의 PROPERTIES 컬럼은 `controlled_by_default` 플래그로 업데이트되었습니다.

  또한 [`SETUP_INSTRUMENTS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-setup-instruments-table.html)의 `FLAGS` 컬럼 값을 설정하여 비전역 메모리 인스트루먼트를 제어되는 메모리 인스트루먼트 집합에 추가하거나 제거할 수 있습니다. 예를 들면 다음과 같습니다:

    ```
                    
            SQL> UPDATE PERFORMANCE_SCHEMA.SETUP_INTRUMENTS SET FLAGS="controlled" 
                 WHERE NAME='memory/sql/NET::buff';             
            
      ```

      (WL #14432)

    ## SQL 문법 관련 사항

    - 이제 컬럼 히스토그램을 사용자가 지정한 JSON 값으로 설정할 수 있습니다. 이는 샘플링에서 중요한 값이 제외될 때 유용할 수 있습니다. 또한 보조(레플리카) MySQL 서버가 데이터를 샘플링하고 히스토그램을 구축하는 작업을 맡을 수 있으며, 이렇게 구축된 히스토그램은 성능에 영향을 주지 않고 기본(소스)에서 사용할 수 있음을 의미합니다.

      이 기능은 [`ANALYZE TABLE... UPDATE HISTOGRAM`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/analyze-table.html)에 대한 확장을 통해 제공됩니다. 다음 명령문은 테이블 *`tbl_name`*의 컬럼 *`col_name`*에 대한 히스토그램을 히스토그램의 JSON 표현인 *`json_data`*로 설정합니다:

      ```
      ANALYZE TABLE tbl_name 
        UPDATE HISTOGRAM ON col_name
        USING DATA 'json_data'
      ```

      이후 Information Schema [`COLUMN_STATISTICS`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/information-schema-column-statistics-table.html) 테이블의 `HISTOGRAM` 컬럼 값을 확인하여 이를 확인할 수 있습니다.

      자세한 정보와 예시는 [Histogram Statistics Analysis](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/analyze-table.html#analyze-table-histogram-statistics-analysis)를 참조하십시오.

      MySQL에 이 기여를 해 주신 Kaiwang Chen에게 감사드립니다. (Bug #104040, Bug #33012389, WL #15123)
    - 이번 릴리스에서 MySQL은 SQL 표준 [`INTERSECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/intersect.html) 및 [`EXCEPT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/except.html) 테이블 연산자에 대한 지원을 추가합니다.

      `query_a INTERSECT query_b`는 두 결과 집합 모두에 나타나는 로우만 포함합니다.

      `query_a EXCEPT query_b`는 *`query_a`*의 결과 집합에서 *`query_b`*의 결과에 *없는* 모든 로우를 반환합니다.

      `INTERSECT`와 `EXCEPT`는 모두 `DISTINCT`와 `ALL`을 지원하며, 두 경우 모두 `DISTINCT`가 기본값입니다. (이는 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html)과 동일합니다).

      `INTERSECT`는 `EXCEPT` 또는 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html)보다 먼저 그룹화되므로, [`TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/table.html)`r EXCEPT TABLE s INTERSECT TABLE t`는 `TABLE r EXCEPT (TABLE s INTERSECT TABLE t)`로 평가됩니다.

      추가 정보와 예시는 [INTERSECT Clause](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/intersect.html) 및 [EXCEPT Clause](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/except.html)를 참조하십시오. (Bug #1309, Bug #31336, Bug #11747209, Bug #11744757, WL #349)

    ## 추가되거나 변경된 기능

    - **중요한 변경; Replication:** `Rewriter` 플러그인은 rewriter 규칙 테이블에 따라 SQL 쿼리를 다시 작성합니다. 이전에는 권한과 관계없이 모든 사용자의 쿼리뿐 아니라, 복제 applier thread, MySQL Server 부트스트랩, 스토리지 엔진에서 수행되는 것과 같은 내부 시스템 쿼리를 포함하여 모든 쿼리가 다시 작성 대상이었습니다. 이 MySQL 릴리스는 시스템 스레드가 실행하는 쿼리 및 지정된 사용자의 쿼리와 같은 특정 쿼리에 대해 플러그인이 재작성을 건너뛰도록 허용하는 메커니즘을 제공합니다.

      이는 쿼리가 다시 작성되지 않는 사용자를 나타내는 새로운 권한 [`SKIP_QUERY_REWRITE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_skip-query-rewrite)를 구현하여 수행합니다. 새로운 시스템 변수 [`rewriter_enabled_for_threads_without_privilege_checks`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/rewriter-query-rewrite-plugin-reference.html#sysvar_rewriter_enabled_for_threads_without_privilege_checks)는 권한 검사가 비활성화된 상태로 실행되는 스레드에 대해 재작성을 건너뛸지 여부를 제어합니다. 이러한 스레드에는 업그레이드 스레드, 초기화 스레드, 그리고 `PRIVILEGE_CHECKS_USER`가 `NULL`인 복제 스레드가 포함됩니다. 이전 버전과의 호환성을 유지하기 위해 이 변수의 기본 설정은 `ON`이지만, 권장 설정은 `OFF`입니다.

      `SKIP_QUERY_REWRITE`와 `rewriter_enabled_for_threads_without_privilege_checks`는 모두 `Rewriter` 플러그인이 설치된 경우에만 사용할 수 있습니다.

      자세한 내용은 [The Rewriter Query Rewrite Plugin](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/rewriter-query-rewrite-plugin.html)을 참조하십시오. (WL #14527)
    - **중요한 변경:** OpenSSL 라이브러리가 번들로 제공되는 플랫폼의 경우, MySQL Server에 링크된 OpenSSL 라이브러리가 버전 1.1.1q로 업데이트되었습니다. OpenSSL 버전 1.1.1q에서 수정된 문제는 [https://www.openssl.org/news/cl111.txt](https://www.openssl.org/news/cl111.txt) 및 [https://www.openssl.org/news/vulnerabilities.html](https://www.openssl.org/news/vulnerabilities.html)에 설명되어 있습니다. (Bug #34414695)

    - **InnoDB:** 온라인 버퍼 풀 크기 조정 작업을 모니터링하기 위해 두 개의 새로운 상태 변수가 제공됩니다. [`Innodb_buffer_pool_resize_status_code`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Innodb_buffer_pool_resize_status_code) 상태 변수는 온라인 버퍼 풀 크기 조정 작업의 단계를 나타내는 상태 코드를 보고합니다. [`Innodb_buffer_pool_resize_status_progress`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Innodb_buffer_pool_resize_status_progress) 상태 변수는 각 단계의 진행률을 나타내는 백분율 값을 보고합니다.

      자세한 내용은 [Configuring InnoDB Buffer Pool Size](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/innodb-buffer-pool-resize.html)를 참조하십시오. (WL #15175)
    - **Replication:** 복제 필터링이 사용 중일 때, 레플리카는 더 이상 필터링되어 제외되는 이벤트에 대해 권한 검사 또는 [`require_row_format`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_require_row_format) 검증과 관련된 복제 오류를 발생시키지 않습니다. 이전에는 모든 권한이 어플라이어에서 검사되었으며, 일부는 필터를 적용하기 전에 검사되고 다른 일부는 그 이후에야 검사되었습니다. 이번 릴리스부터는 권한 검사가 모든 복제 필터가 적용된 이후로 지연됩니다. 또한 이번 릴리스 이전에는 `require_row_format`이 `1`과 같은지에 대한 검사가 리시버와 어플라이어 모두에서 수행되었습니다. 이제는 어플라이어만 이 검사를 수행하며, 모든 필터가 평가되기 전에 수행합니다.

      이를 통해 기존 복제 필터를 사용하여 검증에 실패하는 모든 트랜잭션을 필터링하여 제외할 수 있으며, 데이터베이스의 해당 부분에 대한 업데이트가 row-based 형식으로만 복제되는 한, 레플리카가 지정된 사용자에게 접근 권한이 부여된 데이터베이스 부분만 수락할 수 있습니다. 이것이 바람직할 수 있는 또 다른 경우는 인바운드 복제 사용자에게 접근 권한이 없는 관리 테이블을 사용하는 온프레미스 또는 클라우드 서비스에서 MySQL Database Service로 마이그레이션할 때입니다.

      권한 검사는 레플리카의 중요 테이블 업데이트를 방지합니다. `require_row_format` 검사는 안전하지 않은 작업의 복제를 방지합니다. 이는 권한 검사와 함께 사용되는데, 안전하지 않은 작업이 없다는 보장이 일부 세션 컨텍스트 초기화 및 정리 작업의 필요성을 제거하고, 이는 다시 해당 작업에 대한 권한을 부여할 필요성을 제거하기 때문입니다.

    이 작업과 관련된 다른 동작 변경 사항은 다음 목록에 나와 있습니다:

      - require row format 검증을 위반하는 이벤트가 수신될 때 receiver 스레드는 더 이상 오류로 중단되지 않습니다. require row format 검증을 위반하는 이벤트가 처리된 뒤 복제 필터로 인해 필터링될 때 applier 스레드는 더 이상 오류로 중단되지 않습니다.
      - 여기 나열된 시스템 변수 중 하나를 설정할 권한이 없어 필터링되는 `Query` 로그 이벤트에 대해 applier 스레드는 더 이상 오류로 중단되지 않습니다:

        - [`pseudo_thread_id`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_pseudo_thread_id)
        - [`sql_require_primary_key`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_sql_require_primary_key)
        - [`default_table_encryption`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_default_table_encryption)

        이는 변수 설정과 applier가 해당 변수를 설정할 권한이 있는지 확인하는 작업이 이제 필터링이 수행된 후에만 실행되기 때문입니다. 이벤트가 필터링되면 applier는 변수를 설정하려고 시도하지 않으므로, 그렇게 하는 데 필요한 권한이 있는지 확인하는 검사에서 실패하지 않습니다.
      - `Execute_load_query` 이벤트가 처리되고 복제 필터로 인해 결국 필터링될 때 applier 스레드는 더 이상 권한 검사에서 오류로 중단되지 않습니다. 이는 `Append_block` 또는 `Begin_load_query` 이벤트가 적용되고, 이후 `Execute_load_query` 이벤트가 처리된 다음 필터링되는 경우에도 마찬가지입니다.
      - `Delete_file` 이벤트에 대해 applier 스레드는 더 이상 권한 검사 또는 `require_row_format` 검사에서 오류로 중단되지 않습니다. 이러한 이벤트는 테이블 이름이나 데이터베이스 이름을 포함하지 않으므로 필터링할 수 없으며, 따라서 필터링된 것으로 간주합니다. Delete_file 이벤트는 데이터베이스 상태를 변경하지 않으므로 이렇게 간주해도 안전하다고 판단합니다.
      - `PRIVILEGE_CHECKS_USER`로 구성된 사용자 계정이 있고 해당 계정에 [`FILE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/privileges-provided.html#priv_file) 권한이 없거나 `require_row_format`이 활성화된 경우, `Append_block` 또는 `Delete_file` 이벤트 처리 중에 applier 스레드는 더 이상 파일 시스템에서 파일을 생성하거나 삭제하지 않습니다.
      - [`--replicate-rewrite-db`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#option_mysqld_replicate-rewrite-db)에 의해 변경된 복제 이벤트의 경우, 모든 권한 검사는 재작성된 데이터베이스에 적용됩니다.

    자세한 내용은 [서버가 복제 필터링 규칙을 평가하는 방법](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-rules.html) 및 [복제 중 레플리카 오류](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-features-errors.html)를 참조하십시오. (Bug #33704306, Bug #33733677, WL #15032)
    - 서버가 리소스 그룹 기능을 지원하는지 여부를 나타내기 위해 새로운 [`Resource_group_supported`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-status-variables.html#statvar_Resource_group_supported) 상태 변수가 추가되었습니다. (Bug #34264356)
    - 시스템 curl 라이브러리에 링크하지 않고 curl을 포함하는 바이너리 패키지는 curl 7.85.0을 사용하도록 업그레이드되었습니다. (Bug #34138733, Bug #34614578)
    - 새로운 [`thread_pool_transaction_delay`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_thread_pool_transaction_delay) 시스템 변수는 워커 스레드가 새 트랜잭션 실행을 시작하기 전에 밀리초 단위의 지연 기간을 지정할 수 있게 합니다. 최댓값은 300000(5분)입니다.

      트랜잭션 지연은 리소스 경합으로 인해 병렬 트랜잭션이 다른 작업의 성능에 영향을 주는 경우에 사용할 수 있습니다. 예를 들어 병렬 트랜잭션이 인덱스 생성 또는 온라인 버퍼 풀 크기 조정 작업에 영향을 주는 경우, 해당 작업이 실행되는 동안 리소스 경합을 줄이도록 트랜잭션 지연을 설정할 수 있습니다. (WL #15277)
    - 새로운 `thread_pool_query_threads_per_group` 시스템 변수는 스레드 그룹 내 쿼리 스레드 수를 기본값인 단일 쿼리 스레드에서 늘릴 수 있게 합니다. 높은 동시성 스레드 풀 알고리즘(`thread_pool_algorithm=1`)을 사용하는 경우, 장기 실행 트랜잭션으로 인해 응답 시간이 느려지는 현상이 발생하면 값을 늘리는 것을 고려하십시오. 이 값은 `thread_pool_max_transactions_limit` 값을 초과할 수 없습니다. (WL #15330)
    - 이전에는 MySQL Database Service에서만 사용할 수 있었던 Thread Pool 플러그인 기능을 이제 MySQL Enterprise Edition에서 사용할 수 있습니다.

      - `thread_pool_max_transactions_limit` 변수는 Thread Pool 플러그인이 허용하는 최대 트랜잭션 수를 정의합니다. 트랜잭션 제한을 정의하면 스레드가 트랜잭션이 커밋될 때까지 해당 트랜잭션에 바인딩되며, 이는 높은 동시성 상태에서 처리량을 안정화하는 데 도움이 됩니다.
      - `thread_pool_dedicated_listeners` 변수는 각 스레드 그룹의 리스너 스레드 하나를 해당 그룹에 할당된 연결에서 들어오는 구문을 수신하도록 전용으로 지정합니다. 이 변수는 `thread_pool_max_transactions_limit`로 트랜잭션 제한이 정의된 경우에만 유용합니다. 각 스레드 그룹에 추가 전용 리스너 스레드가 있으면 더 많은 리소스를 소비하고 스레드 풀 성능에 영향을 줍니다. 따라서 `thread_pool_dedicated_listeners`는 신중하게 사용해야 합니다.
      - `TP_CONNECTION_ADMIN` 권한은 사용자가 특권 연결로 서버에 접근할 수 있게 합니다. `thread_pool_max_transactions_limit`로 정의된 제한에 도달하면 새 연결은 서버에 접근할 수 없습니다. 특권 연결은 `thread_pool_max_transactions_limit`로 정의된 제한을 무시하며, 서버에 연결하여 트랜잭션 제한을 늘리거나, 제한을 제거하거나, 실행 중인 트랜잭션을 종료할 수 있게 합니다.

    (WL #15293)

    - Performance Schema 테이블 [`replication_group_communication_information`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/performance-schema-replication-group-communication-information-table.html)의 새 필드 `WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE`은 쿼리된 멤버에서 `group_replication_paxos_single_leader`가 현재 `OFF`로 설정되어 있더라도, 복제 그룹이 단일 합의 리더 사용을 지원하는지 여부를 표시합니다. 이 필드는 그룹이 `group_replication_paxos_single_leader`를 `ON`으로 설정하여 시작되었고, 해당 통신 프로토콜 버전이 MySQL 8.0.27 이상인 경우 1로 설정됩니다. (WL #15203)
    - MySQL Server의 오프라인 모드를 활성화하는 작업은 `offline_mode` 시스템 변수 값을 `ON`으로 변경하여 수행되며, 이제 `SYSTEM_VARIABLES_ADMIN` 권한에 더해 `CONNECTION_ADMIN` 권한도 필요합니다(또는 이 두 권한을 모두 포함하는, 더 이상 사용되지 않는 `SUPER` 권한이 필요합니다). 사용자가 `CONNECTION_ADMIN` 권한을 가진 세션은 오프라인 모드가 활성화될 때 연결된 상태로 유지되며, 해당 권한을 가진 사용자는 오프라인 서버 인스턴스에 새 연결을 만들 수 있습니다. 이 새로운 요구 사항은 오프라인 모드를 활성화할 수 있는 관리자가 그렇게 함으로써 의도치 않게 스스로를 잠그는 상황을 방지한다는 의미입니다. (WL #13400)
    - 읽기 전용 [`build_id`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_build_id) 시스템 변수가 추가되었습니다. Linux 시스템에서는 컴파일 시점에 160비트 `SHA1` 서명이 생성됩니다. 이 값은 16진수 문자열로 변환되어 빌드의 고유 식별자를 제공합니다. 이 값은 시작 시 서버 로그에 기록됩니다.

      이 변수는 Linux 이외의 플랫폼에서는 지원되지 않습니다. (WL #15161)
    - Ubuntu 22.10 지원이 추가되었습니다.

    ## 수정된 버그

    - **호환되지 않는 변경:** MySQL 8.0.14 이후 사용 중단된 서비스 `pfs_plugin_table`이 이 릴리스에서 제거되었습니다.

      이 서비스를 사용하는 플러그인 또는 컴포넌트는 대신 `pfs_plugin_table_v1` 및 `pfs_plugin_column_*`를 사용하도록 업데이트해야 합니다. (Bug #34361827)
    - **중요 변경; 복제:** [`--replicate-do-db`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#option_mysqld_replicate-do-db) 또는 [`--replicate-ignore-db`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-replica.html#option_mysqld_replicate-ignore-db)가 사용될 때마다 기본 데이터베이스에 의해 필터링되는 쿼리 로그 이벤트에는 바이너리 로그 형식과 관계없이 [`XA START`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/xa-statements.html), `XA END`, `XA COMMIT`, `XA ROLLBACK`이 포함되었습니다(`XA PREPARE` 또는 `XA COMMIT ONE_PHASE`는 포함되지 않았습니다).

      이는 여기에 나열된 문제 중 하나로 이어질 수 있습니다:

      - `XA START` 또는 `XA END`가 필터링되면, 트랜잭션 첫 번째 부분 내의 XA 문 시퀀스가 유효하지 않게 되어 레플리카가 오류와 함께 중지되었습니다.
      - `XA START` 및 `XA END`는 유지되는 반면 `XA COMMIT` 또는 `XA ROLLBACK`이 필터링되면, 트랜잭션이 레플리카에서 무기한으로 준비된 상태로 남을 수 있었습니다.

      이러한 문제 중 하나가 발생하지 않도록 하기 위해, 이제 `--replicate-do-db` 또는 `--replica-ignore-db`를 사용하여 기본 데이터베이스별로 `XA START`, `XA END`, `XA COMMIT`, `XA ROLLBACK` 문을 필터링하지 않습니다. (Bug #106201, Bug #33764808)

    - **InnoDB:** `ALGORITHM-INSTANT`를 사용하여 추가되거나 삭제된 컬럼에 대한 로우 버전을 지원하는 릴리스로 업그레이드한 후, nullable 컬럼과 즉시 추가된 컬럼이 있는 테이블에서 instant `ADD COLUMN` 작업 중 실패가 발생했습니다. (Bug #34488482)
    - **InnoDB:** 동일한 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문에서 가상 컬럼을 추가하고 컬럼을 삭제하면 잘못된 debug 어설션 실패가 발생했습니다. (Bug #34467592)
    - **InnoDB:** 컬럼을 삭제하고 기존 컬럼의 이름을 삭제된 컬럼의 이름으로 변경한 후 컬럼의 물리적 위치가 올바르게 설정되지 않았습니다. (Bug #34463089)
    - **InnoDB:** `mtr_t::start()`에서 감지된 Valgrind 오류가 수정되었습니다. (Bug #34327575)
    - **InnoDB:** 손상된 파티션된 테이블에 대한 DDL 작업에서 어설션 실패가 발생했습니다. (Bug #34293555)
    - **InnoDB:** histogram 샘플링 중 인덱스 블록 latch 순서 위반으로 동시 삽입이 차단되었으며 deadlock 실패가 발생할 수 있었습니다. (Bug #34282448, Bug #34174927, Bug #107299)
    - **InnoDB:** 데이터 로드 작업이 진행 중일 때 실행된 [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 작업에서 어설션 실패가 발생했습니다. (Bug #34267618)

    - **InnoDB:** MySQL 서버 초기화 중 발생하던 `InnoDB` 메모리 누수가 Address Sanitizer (ASAN) 빌드에서 식별되었으며, 수정되었습니다. (Bug #34156050)
    - **InnoDB:** 복구 중에 디스크에서 가져온 암호화된 undo 테이블스페이스 페이지와 연결된 테이블스페이스 객체에 해당 페이지를 복호화하는 데 필요한 암호화 키가 포함되어 있지 않아 실패가 발생했습니다. (Bug #34148143)
    - **InnoDB:** 디버그 빌드에서 내림차순 b-tree 스캔이 디버그 어설션 실패를 발생시켰습니다. (Bug #34144951)
    - **InnoDB:** `innodb_redo_log_consumer_advance()` 함수가 유효하지 않은 인수를 처리하지 못했습니다. (Bug #34052884)
    - **InnoDB:** `ALGORITHM=INSTANT`를 사용하여 추가된 컬럼이 해당 컬럼을 추가한 DDL 작업 전에 생성된 읽기 뷰에서 표시되었습니다. (Bug #33937504)
    - **InnoDB:** 특정 테이블 ID를 가진 사용자가 생성한 테이블이 포함된 MySQL 5.6 데이터 디렉터리로 MySQL 인스턴스를 업그레이드하는 동안 실패가 발생했습니다. 해당 테이블 ID를 할당한 결과, MySQL 5.7에서 MySQL 8.0으로 업그레이드하는 동안 충돌하는 데이터 딕셔너리 테이블 ID가 할당되었습니다.

      기여해 주신 Rahul Malik에게 감사드립니다. (Bug #33919635)
    - **InnoDB:** intrinsic 임시 테이블 페이지가 포함된 버퍼 블록이 페이지 순회 중 재배치되어 어설션 실패가 발생했습니다. (Bug #33715694)
    - **InnoDB:** 폐기된 테이블스페이스가 있는 테이블을 삭제하면 어설션 실패가 발생했습니다. (Bug #33232978)

    - **InnoDB:** 종료가 플러시 단계에 도달하기 전에 완료되지 않은 페이지 I/O 읽기는 해당 I/O 읽기 이후 완료되어야 하는 change buffer 병합이 페이지에 있는 경우 assertion failure를 발생시켰습니다. (Bug #33192496)
    - **InnoDB:** `dict_table_x_lock_indexes()`의 인덱스 래치 순서 위반이 assertion failure를 발생시켰습니다. (Bug #32912868)
    - **InnoDB:** [`TRUNCATE TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/truncate-table.html) 작업이 특정 경우에 획득한 mutex를 해제하지 못했습니다. (Bug #107858, Bug #34380370)
    - **InnoDB:** 디버그 빌드에서, instant 방식으로 추가되거나 삭제된 컬럼이 있는 테이블에 대해 `.cfg` 파일 없이 테이블스페이스를 임포트하면 assertion failure가 발생했습니다. (Bug #107517, Bug #34307874)
    - **InnoDB:** `trx_undo_prev_version_build()` 함수의 잠재적 메모리 누수가 수정되었습니다.

      기여해 주신 Alex Xing에게 감사드립니다. (Bug #106952, Bug #34051207)
    - **InnoDB:** 복구 중에 공간 삭제를 다시 수행하는 동안 디버그 assertion failure가 발생했습니다. (Bug #103482, Bug #32819101)
    - **InnoDB:** 객체 풀 수를 지정하던 `InnoDB` 시작 메시지는 buffer pool 인스턴스 수와의 혼동을 피하기 위해 제거되었습니다. (Bug #80248, Bug #22653060)

    - **파티셔닝:** [`ALTER TABLE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/alter-table.html) 문이 컬럼 중 하나의 캐릭터셋을 변경하도록 동작할 때 파티셔닝된 테이블이 예상대로 다시 파티셔닝되지 않았습니다. 이에 대한 근본 원인은 캐릭터셋 변경을 in-place alter 작업으로 수행할 수 있는지 판단할 때 캐릭터셋 변경의 영향을 받는 컬럼이 테이블의 파티셔닝 표현식의 일부인지 여부를 고려하지 않았기 때문입니다. 이러한 변경은 테이블의 재파티셔닝으로 이어질 수 있으므로 in-place로 수행할 수 없었습니다. 이제 캐릭터셋 변경이 계획되면, 파티셔닝 표현식의 일부인 컬럼에 이것이 영향을 주는지도 확인합니다. 영향을 주지 않는 경우에는 해당 작업을 in-place로 수행할 수 있습니다. (Bug #106884, Bug #34031693)
    - **복제:** 복제 정보 처리의 내부 오류를 수정했습니다. (Bug #34214416)
    - **복제:** 단일 이벤트가 복제본의 한 테이블에서 동일한 로우에 대해 여러 업데이트를 발생시킨 경우, 소스에는 존재하지 않는 기본 키가 복제본의 해당 테이블에 있으면 변경 사항을 적용할 수 없었습니다. 이제 해시 기반 로우 조회 알고리즘은 복제본의 테이블에 기본 키가 있는 경우에도 이 상황에서 동작합니다. (Bug #34114296)

    - **Replication:** 복제본에서 단일 문이 서로 다른 테이블에 대해 여러 쓰기 이벤트를 생성할 때, 복제본 테이블의 추가 auto-increment 컬럼은 생성된 마지막 이벤트에 대해서만 정리되었습니다. 마지막 이벤트가 추가 auto-increment 컬럼이 있는 테이블과 관련되지 않은 경우에는 전혀 정리되지 않았습니다. 이제 정리 프로세스는 여러 쓰기 이벤트에 대해 항상 수행됩니다. (Bug #34095290)
    - **Replication:** `group_replication_force_members` 시스템 변수가 설정되고 뷰 변경 대기가 시간 초과된 경우, 클라이언트에 오해의 소지가 있는 오류가 반환되었습니다. 해당 오류 및 관련 오류는 시스템 변수에 지정된 값이 잘못되었다고 암시하지 않도록 업데이트되었습니다. (Bug #34091087)
    - **Replication:** Performance Schema 테이블 `replication_applier_filters`의 FILTER_RULE 컬럼이 규칙이 존재하지 않는 필터에 대해 잘못된 데이터를 표시했습니다. 이제 이 테이블은 이러한 상황에서 빈 문자열을 표시합니다. (Bug #33885484)
    - **Replication:** 플러시 또는 동기화 오류가 드물게 발생하는 일부 경우, 서버가 파일과 파일 내 위치 모두에 대해 유효하지 않은 값을 사용하여 바이너리 로그의 끝점을 업데이트하려고 시도할 수 있었으며, 이로 인해 정의되지 않은 동작이 발생했습니다.

      이 문제를 해결하기 위해 이제 파일 및 위치 매개변수가 모두 유효한 것으로 알려진 경우에만 내부 함수 `update_binlog_end_pos(binlog_file, pos)`를 호출합니다. (Bug #33818238)

    - **Replication:** 유효하지 않은 GTID 로그 이벤트의 SID를 사용하는 작업이 때때로 정의되지 않은 동작으로 이어졌습니다.

      이 문제는 SID가 유효하지 않은 GTID 로그 이벤트에 속하는 경우에도 항상 초기화되도록 보장하여 해결했습니다. (Bug #33784022)
    - **Replication:** 상태 변수의 최대 길이(`MAX_SIZE_LOG_EVENT_STATUS`) 계산이 올바르게 수행되지 않았습니다.

      이 수정에서 바로잡은 문제는 다음과 같습니다:

      - [`sql_require_primary_key`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_sql_require_primary_key) 및 [`default_table_encryption`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_default_table_encryption)에는 2바이트가 필요합니다(하나는 타입 ID용, 하나는 변수용).
      - [`time_zone`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_time_zone)의 최대 길이가 `MAX_TIME_ZONE_NAME_LENGTH`가 아니라 255로 계산되었습니다.
      - 사용자 변수의 길이, `binlog_accessed_db_names`에 저장된 데이터베이스 ID 수, 마이크로초 타입을 저장하려면 추가 바이트가 각각 필요합니다.

      또한 실제로 사용되지 않았던 `master_data_written`이 제거되었습니다. (Bug #33713071)

    - **Replication:** 32비트 플랫폼에서 [`binlog_expire_logs_seconds`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/replication-options-binary-log.html#sysvar_binlog_expire_logs_seconds)를 `2147483648`(`231`) 이상으로 설정하면, 지정된 시간이 경과하기 전에 모든 바이너리 로그가 purge되는 효과가 있었습니다. (Bug #33670457)
    - **Replication:** 그룹 설정 변경이 진행 중이면 새 멤버가 참여할 수 없습니다. 이 시나리오에서 발생하는 오류 메시지는 이제 primary election, single primary mode와 multi-primary mode 간의 전환, 또는 group communication protocol 변경과 같이 어떤 작업이 진행 중인지 명시합니다. (Bug #32766981)
    - **Replication:** 바이너리 로그 sender 스레드가 heartbeats가 활성화된 상태에서 업데이트를 기다릴 때, 때때로 update signal을 놓쳐 변경 사항이 다음 signal이 발생하고 스레드가 이를 인지할 때까지 복제되지 않았습니다.

      기여해 주신 Facebook에 감사드립니다. (Bug #104491, Bug #33176377)

    - **Group Replication:** [`START REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/start-replica.html) 및 [`STOP REPLICA`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/stop-replica.html) 문은 Group Replication 적용자 채널(`group_replication_applier`)에 대해 허용되었지만, 채널을 수동으로 중지하고 시작하면 복제 그룹의 온라인 멤버가 원격 트랜잭션을 커밋할 수 없는 상태가 될 수 있었습니다. 이제 Group Replication이 실행 중일 때 이러한 문을 해당 채널에 사용할 수 없습니다. (Bug #34231291)
    - **Group Replication:** 서버 인스턴스에서 Group Replication이 시작되었지만 호환되지 않는 설정과 같은 오류로 인해 멤버가 즉시 이탈한 경우 데드락이 발생할 수 있었습니다. 이제 서비스 레지스트리는 이 문제를 방지하는 대체 프로세스로 서비스 등록 및 등록 해제를 관리합니다. (Bug #34194893)
    - **Group Replication:** InnoDB ClusterSet에서 커밋 순서 데드락 및 후속 재시도 이벤트가 발생한 경우, Group Replication은 인증 중 트랜잭션의 GTID가 이미 사용되었다는 오류와 함께 트랜잭션을 롤백할 수 있었습니다. 이제 이 오류는 GTID가 그룹뿐 아니라 서버 인스턴스에서도 사용된 경우에만 반환됩니다. (Bug #34157846)

    - **Group Replication:** Group Replication은 트랜잭션 커밋에 충돌이 없고 올바른 순서임을 확인한 후 커밋하는 세션에 다시 보고합니다. 이벤트 스케줄러 스레드가 시작되었을 때 Group Replication은 커밋하는 세션을 찾을 수 없었으며, 이로 인해 멤버가 `ERROR` 상태로 진입하고 그룹을 떠났습니다. 커밋하는 세션을 찾는 절차가 이벤트 스케줄러 스레드를 시작하는 데 사용되는 것과 같은 daemon 스레드를 찾도록 확장되었습니다. 기여해 주신 Lou Shuai에게 감사드립니다. (Bug #107635, Bug #34312482)
    - 동일한 연결에서 많은 저장 프로시저를 호출하면 서버가 계속 증가하는 양의 가상 메모리를 소비했습니다. (Bug #35110491)
    - 시스템 변수 `replication_optimize_for_static_plugin_config`가 semisynchronous 복제의 성능을 향상하기 위해 활성화되었을 때, 알림 처리 관련 문제로 인해 `RAPID` 플러그인을 서버에서 사용할 수 없었습니다. 이 문제는 이제 수정되었습니다. (Bug #34549470)
    - 선행 0이 많이 포함된 문자열을 decimal로 변환할 때 잘못해서 오버플로로 표시되었으며, 이로 인해 반환되는 값이 지정된 precision 및 scale에 대한 최대 decimal 값이 되었습니다.

      이러한 경우 변환 전에 모든 선행 0을 단일 `0`으로 대체하여 이 문제를 수정합니다. (Bug #34479194)

    - Windows의 `WSAPoll` 함수와 Unix 계열 시스템의 `poll()` 함수 간 차이로 인해 Windows의 thread pool 코드가 잘못된 파일 디스크립터 또는 소켓을 I/O 준비 완료 상태로 간주했습니다. (Bug #34478731)
    - MySQL 8.0.27 이상인 MySQL 인스턴스가 MySQL 8.0.26에서 실행 중인 복제 그룹에 참여한 경우, 멤버 액션 `mysql_start_failover_channels_if_primary`는 그룹의 나머지 멤버 액션 설정과 일치하도록 제거되었습니다. 그러나 인스턴스가 MySQL 8.0.27 이상에서 실행되도록 업그레이드된 경우, 이후 그룹을 부트스트랩한 서버에서 `group_replication_reset_member_actions()`가 실행되지 않는 한 해당 멤버 액션은 복원되지 않았습니다. 이제 참여하는 멤버는 멤버 액션 `mysql_start_failover_channels_if_primary`를 사용할 수 있는지 확인하고, 사용할 수 있으면 이를 해당 멤버 액션 설정에 추가합니다. (Bug #34464526)
    - 쿼리의 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 목록에 사용된 상수 표현식이 서버에서 항상 올바르게 처리되지는 않았습니다. (Bug #34418412)
    - `Json_table_column::fill_column()`에 누락된 오류 검사를 추가했습니다. (Bug #34416304)
    - 여러 인수를 받는 일부 문자열 함수가 모든 인수를 올바르게 처리하지 않았습니다. (Bug #34393009)

    - [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html) 결과를 보관하는 임시 테이블에 대해 생성된 [`YEAR`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/year.html) 타입의 컬럼이 항상 올바른 길이임을 보장하지 않았습니다. (Bug #34370933)
    - 뷰(`v1`)가 다른 뷰(`v2`)에 접근하고, `v2`가 다시 생성된 경우 [`SHOW COLUMNS FROM v1`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/show-columns.html)이 유효하지 않은 뷰 오류를 보고했습니다. 이 문제는 사용자에게 역할을 통해 전역 권한이 부여되었지만 테이블 수준 권한은 부여되지 않은 경우에만 발생할 수 있었습니다. 테이블 수준 권한이 없으면 전역 권한을 확인하도록 하여 수정되었습니다. (Bug #34341533)
    - Performance Schema 테이블 `replication_group_member_actions`에 대한 쿼리가 스레드 간 충돌로 인해 실패할 수 있었습니다. 이제 이 문제가 수정되었습니다. (Bug #34337673)
    - const 테이블을 읽을 때 항목 평가 후 누락된 오류 검사를 추가했습니다. (Bug #34327798)
    - 파생 테이블의 재파싱 및 클로닝이 특정 경우에 항상 올바르게 처리되지는 않았습니다. (Bug #34317258, Bug #34408241)
    - 여러 쿼리 블록이 있는 경우, 집합 연산을 포함하는 파생 테이블로 조건을 푸시다운하는 작업이 항상 올바르게 처리되지는 않았습니다. (Bug #34306361)
    - RSA 키 생성 중 시작 실패가 발생하면 비어 있거나 불완전한 키가 생성되었습니다. 이제 키는 장애 안전 방식으로 생성됩니다. (Bug #34274914)

    - 명시적 `COLLATE` 절이 있는 두 문자열 값을 비교할 때, 두 값은 동일한 콜레이션을 가져야 하며, 그렇지 않으면 비교가 거부되어야 하지만, 이것이 항상 강제되지는 않았습니다.

      자세한 내용은 [Collation Coercibility in Expressions](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/charset-collation-coercibility.html)를 참조하십시오. (Bug #34274525)
    - 바이너리 로그에서 읽은 [`CREATE USER`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/create-user.html) 작업이 예기치 않은 문법 오류로 인해 복제 서버에서 실행되지 못했습니다. (Bug #34178823)
    - 정수 값에 대해 `FLOAT`로 수행하는 [`CAST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_cast) 작업에서, `SQL_BIG_RESULT`가 아닌 `SQL_SMALL_RESULT`를 사용할 때 정밀도 불일치가 때때로 발생할 수 있었습니다([SELECT Statement](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html) 참조).

      `SQL_BIG_RESULT`의 경우, 값은 IEEE 32비트 부동소수점 값의 고유 정밀도에 따라 잘렸으며, 이것이 올바른 동작입니다. `SQL_SMALL_RESULT`에서는 원래 정수 값의 정밀도가 보존되었습니다. 이는 값이 배정밀도 값만 지원하는 임시 테이블로 복사되었고, 이러한 값이 나중에 클라이언트로 다시 복사되었기 때문에 발생했습니다.

      이러한 값을 임시 테이블로 복사할 때 부동소수점 값의 타입을 구분하여, 배정밀도 값은 double 타입으로 저장되고 단정밀도 값은 float 타입으로 저장되도록 하여 이 문제를 수정했습니다. (Bug #34167787)

    - 소스 코드 대부분에 대해 `codespell`을 실행하고, 코드 주석에서 보고된 철자 오류를 수정했습니다. (Bug #34163323)
    - 특정 경우에서, 내부 함수 포인터를 호출하기 전에 검사할 때 잘못된 포인터가 검증되었습니다. (Bug #34134738)
    - `eq_ref` 접근에 대한 접근 경로와 이터레이터 모두에는 정렬된 인덱스 스캔을 사용할지 여부를 결정하기 위한 `use_order` 멤버가 있었습니다. `eq_ref`는 항상 최대 하나의 로우만 반환하므로, 이를 정렬할 필요가 없습니다. 따라서 `use_order`는 여기에서 아무 목적도 수행하지 않으며, 접근 경로와 해당 이터레이터에서 제거되었습니다. (Bug #34122706)
    - [`ADD_GDB_INDEX`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/source-configuration-options.html#option_cmake_add_gdb_index) **CMake** 옵션이 유닛 테스트를 로드할 때도 동작하도록 개선했습니다. (Bug #34117732)

      참조: 함께 참조하십시오: Bug #29925009.
    - 관련 USE_LD_GOLD CMake 옵션을 포함하여 GNU 'gold' 링커 지원을 제거했습니다. (Bug #34094324)

    - MySQL 5.7 데이터 디렉터리에서 수동으로 생성된 디렉터리( MySQL 5.7에서 스키마 디렉터리로 처리됨) 중 디렉터리 이름에 특수 문자가 포함된 디렉터리 또는 ``#mysql50#`` 접두사를 사용하여 이름에 특수 문자가 포함되도록 생성된 스키마와 테이블은 MySQL 8.0으로 업그레이드한 후 DDL 실패를 발생시켰습니다. MYSQL 8.0에서는 객체 이름이 데이터 딕셔너리에 추가될 때 특수 문자가 물음표 문자(`?`)로 대체됩니다. 이름 불일치로 인해 영향을 받는 객체에 대한 DDL 작업이 실패했습니다. 이제 업그레이드는 잘못된 스키마 및 테이블 이름이 발견되면 오류와 함께 중지됩니다.

      MySQL 5.7에서는 **mysqlcheck**를 사용하여 잘못된 스키마 및 테이블 이름을 유효한 인코딩으로 업데이트할 수 있습니다. 잘못된 이름을 식별하려면 다음을 실행하십시오:

      ```
      mysqlcheck --check-upgrade --all-databases
      ```

      잘못된 이름을 수정하려면 다음을 실행하십시오:

      ```
      mysqlcheck --fix-db-names --fix-table-names --all-databases
      ```

      MySQL 5.7에서는 특수 문자가 포함된 디렉터리 이름도 다음 SQL 문법을 사용하여 유효한 인코딩을 사용하도록 업데이트할 수 있습니다:

      ```
      ALTER DATABASE `directory_name` UPGRADE DATA DIRECTORY NAME;
      ```

      (Bug #34066605)

    - null-safe equals 연산자([`<=>`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/comparison-operators.html#operator_equal-to))를 사용하는 조건을 이제 실행기가 equijoin 조건으로 간주할 수 있습니다. 이러한 조건을 사용하는 프레디케이트는 equijoin 프레디케이트로 간주되지 않고, 조인 이후 평가할 추가 프레디케이트로 간주됩니다. (Bug #34063499)
    - MySQL Enterprise Encryption 컴포넌트를 OpenSSL 3으로 컴파일하는 지원이 추가되었습니다. (Bug #34043029)
    - 소스 코드에서 `codespell`을 실행하고 코드 주석에서 보고된 맞춤법 오류를 수정했습니다. (Bug #34006439)
    - [`GREATEST()`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/comparison-operators.html#function_greatest)에 대한 하나 이상의 인수가 시간 값인 경우, 해당 인수가 함수에 전달되는 순서가 결과에 영향을 줄 수 있었습니다. (Bug #33996054)
    - `WHERE` 절의 일부로 [`IN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/comparison-operators.html#operator_in) 프레디케이트가 있는 중첩 서브쿼리를 포함한 파생 테이블에 대해 `LEFT JOIN`을 사용하는 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)가 잘못된 결과를 반환했습니다. (Bug #33971286)
    - `vio_ssl_write()` 및 `ssl_handshake_loop()` 함수에서 `ERR_clear_error()` 호출이 OpenSSL 3.0으로 컴파일할 때 오류를 발생시켰습니다. (Bug #33967647)

    - 서버가 중첩 뷰를 항상 예상대로 처리하지는 않았습니다. (Bug #33876690)
    - **mysqlpump**에 파생 테이블(쿼리 `FROM` 절에 의해 생성되는 테이블)을 사용하는 데 필요한 올바른 권한이 부여되지 않을 수 있었으며, 이로 인해 이러한 테이블이 있는 경우 덤프 프로세스가 중지되었습니다. 이제 파생 테이블은 별도로 처리되며 해당 테이블에 대한 권한이 설정됩니다. (Bug #33866103)
    - 여러 `AND`, `OR` 또는 `XOR` 조건을 포함하는 [`SELECT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/select.html)를 서브쿼리로 가지는 저장 루틴을 반복 실행하면 가상 메모리가 과도하게 소비되고 결국 고갈될 수 있었습니다. (Bug #33852530)
    - [`EXPLAIN ANALYZE`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/explain.html#explain-analyze)는 쿼리 계획의 각 iterator에 대한 예상 비용 및 경과 시간 정보를 제공합니다. 이러한 숫자는 누적된 값이어야 하므로, 특정 iterator의 비용(또는 시간)에는 이 iterator가 의존하는 모든 iterator의 비용이 포함되어야 합니다. 예를 들어, `t1`의 테이블 스캔 뒤에 `t2`의 기본 키 조회를 사용하여 테이블 `t1`을 테이블 `t2`와 조인하는 예상 비용은 `t1` 스캔 비용에 `t2`의 카디널리티 조회 비용을 더한 값보다 작아서는 안 됩니다.

      구체화 또는 임시 테이블이 포함된 일부 쿼리의 경우 이러한 숫자가 누적되지 않았습니다. 또한 [`UNION`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/union.html) 작업의 결과를 구체화한 다음 임시(구체화된) 테이블에서 테이블 스캔을 수행할 때 비용 추정이 올바르지 않았습니다. (Bug #33834146, Bug #34302461)

    - 두 문자열 값의 비교를 위한 콜레이션 강제 변환은 피연산자의 순서에 따라 달라졌습니다. 하나의 문자열은 `utf8mb4` 캐릭터셋을 사용하고 다른 하나는 `utf8mb3`를 사용하는 경우, 왼쪽 피연산자가 `utf8mb4`이면 `utf8mb4` 콜레이션을 사용하여 비교가 수행되었고, 왼쪽 피연산자가 `utf8mb3`이면 `utf8mb3`를 사용하여 비교가 수행되었습니다.

      문제의 근본 원인은 ASCII 문자열의 강제 변환에 사용되는 특수 처리에 있었습니다. 두 문자열이 모두 리터럴이었으므로 ASCII 및 비ASCII 문자를 찾기 위해 스캔되었고, 이에 따라 레퍼토리 속성이 설정되었습니다. 이는 한 문자열은 ASCII로 처리되는 반면 다른 문자열은 그렇지 않을 수 있음을 의미했습니다. `utf8mb4` 문자열이 ASCII로 간주되어 `utf8mb3` 문자열과 호환되는 것으로 판단되면, 비교 전에 해당 문자열이 (잘못) 변환되었습니다.

      이를 수정하기 위해 `MY_REPERTOIRE_ASCII`가 아니라 내부 `MY_CS_PUREASCII` 속성을 사용합니다. `MY_CS_PUREASCII`는 실제 문자열이 아니라 캐릭터셋에서만 엄격하게 파생되므로, 콜레이션 결정이 결정적이 됩니다. 이제 이러한 경우 두 문자열 중 어느 것도 ASCII로 식별되지 않으며, 예상대로 비교가 수행되기 전에 `utf8mb3`가 `utf8mb4`로 변환됩니다. (Bug #33801312)

    - [`connect_timeout`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_connect_timeout) 제한의 범위가 전체 패킷 읽기로 확장되었습니다. (Bug #33723597)

      참조: 다음도 참조하십시오: Bug #34574013.
    - Event Scheduler가 예상대로 서버에서 자동으로 재시작되도록 보장하기 위한 새 검증이 추가되었습니다. (Bug #33711304)

      참조: 다음도 참조하십시오: Bug #33539082.
    - prepared statement가 커서 없이 실행되었을 때 이전 실행에서 커서를 사용한 경우 잘못된 결과를 반환할 수 있었습니다. 이 문제는 두 개의 쿼리 결과 객체를 생성하고 저장하여 수정되었습니다. 하나는 커서와 함께 사용하기 위한 것이고 다른 하나는 커서 없이 사용하기 위한 것입니다. 객체는 필요할 때 생성되므로, prepared statement가 커서와 함께 사용되지 않는 경우 커서 전용 쿼리 결과 객체는 생성되지 않습니다. (Bug #33535746)

    - 매개변수가 있는 prepared statement가 로우 업데이트에 실패할 수 있었지만, 동일한 데이터를 사용하는 동일한 문장을 쿼리로 실행하면 로우가 업데이트되었습니다. 이 문제에 대한 수정은 매개변수에 기본 데이터 타입을 할당하는 것이지만, 데이터 타입 전파에 사용할 수 있는 컨텍스트가 없고 캐릭터 문자열 타입이 암시적으로 지정되기 때문에 이는 비효율적일 수 있습니다. 이 경우 모범 사례는 이러한 매개변수 선언을 원하는 데이터 타입을 제공하는 [`CAST`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/cast-functions.html#function_cast) 절로 감싸는 것입니다. (Bug #33521861)
    - FEDERATED 스토리지 엔진을 사용하는 테이블의 경우, 로컬 서버에서 연속된 쿼리 사이의 지연이 원격 서버의 대기 제한 시간(`wait_timeout` 설정)을 초과하면 로컬 서버에서 패킷 오류가 반환되었습니다. 이제 원격 서버의 제한 시간 오류가 로컬 서버에서 올바르게 처리되며, 로컬 서버는 다시 연결하고 문장을 다시 실행합니다. (Bug #33500956)
    - 조인 최적화 중에 발생할 수 있었던 예기치 않은 조건을 처리했습니다. (Bug #31401468)

      참조: 다음도 참조하십시오: Bug #34350945.
    - `SET @@character_set_client = @@character_set_system` 실행 후 optimizer hint가 올바르게 파싱되지 않았습니다. (Bug #107820, Bug #34370403)

    - [`MyISAM`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/myisam-storage-engine.html) 테이블의 컬럼에서 boolean 모드로 full-text 검색을 수행하는 쿼리는 해당 컬럼이 문자열 타입이 아닐 때 debug 빌드에서 assertion을 발생시켰습니다. 이는 `MyISAM`이 boolean 모드에서 인덱스가 없는 `MATCH` 컬럼을 허용하므로, constant propagation의 대상이 되는 정수 컬럼도 허용한다는 사실 때문이었습니다. `MyISAM` 이외의 스토리지 엔진을 사용하는 테이블에서 이러한 쿼리는 이 문제의 영향을 받지 않았습니다.

      이 문제는 컬럼이 문자열 타입이 아닐 때 `MATCH` 절에서 constant propagation을 비활성화하여, 해당 절이 컬럼 참조만 포함한다고 안전하게 가정할 수 있도록 수정되었습니다. (Bug #107638, Bug #34311472)
    - `my_time.cc`의 주석에 있는 오류를 수정했습니다. 기여해 주신 Dimitry Kudryavtsev에게 감사드립니다. (Bug #107633, Bug #34308417)
    - MySQL 8.0.24에서 연결 오류 처리 방식이 변경된 후, `max_allowed_packet` 초과와 같은 오류로 인해 **mysql** 클라이언트가 서버에서 연결 해제된 경우, 이후 해당 연결 해제를 나타내도록 오류가 재설정되지 않았습니다. 이후 쿼리에서는 원래 오류가 반환되었으며, **mysql** 클라이언트에 연결 해제 오류가 없었기 때문에 자동 재연결이 수행되지 않았습니다. 이제 오류가 연결 해제를 나타내고 클라이언트가 재연결할 수 있도록 재설정됩니다. (Bug #107605, Bug #34303841)

    - MySQL 8.0.29의 버그 수정 이후, 비밀번호가 옵션 파일에 제공된 경우 **mysql** 클라이언트는 로그인 시 `-p` 옵션이 지정되어도 비밀번호를 요청하지 않았습니다. 이제 클라이언트는 `-p` 옵션이 지정되면 항상 비밀번호를 요청하고, 옵션 파일에서 대체 비밀번호가 채워졌더라도 지정된 비밀번호를 사용합니다. (Bug #107205, Bug #34134984)
    - 암호화된 연결 사용을 비활성화하기 위한, 사용 중단된 `--ssl=off` 서버 옵션의 대안이 문서화된 대로 또는 사용 중단 경고에 표시된 대로 작동하지 않았습니다. 이제 `tls_version` 시스템 변수를 빈 값(`tls_version=''`)으로 설정하면 이 목적에 맞게 올바르게 작동합니다. (Bug #106459, Bug #33858646)
    - [`BIT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/bit-type.html) 컬럼에 대한 집계 쿼리가 비트 문자열로 포맷된 값을 반환했지만, `BINARY` 플래그도 자동으로 추가되었습니다. 이제 새로운 검증에서 [`BIT`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/bit-type.html) 결과에 대해 `BINARY` 플래그 설정을 확인하고 건너뜁니다. (Bug #106241, Bug #33781442)
    - `SHOW SLAVE STATUS` 및 `SHOW SLAVE HOSTS`는 `SHOW REPLICA STATUS` 및 `SHOW REPLICA HOSTS`가 도입된 이후 이전보다 더 많은 CPU를 사용했습니다. (Bug #105924, Bug #33684069)

    - [`NO_SKIP_SCAN`](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/optimizer-hints.html#optimizer-hints-index-level) 힌트가 테이블 skip scan에 사용하지 않을 특정 인덱스를 참조한 경우, 가능한 다른 모든 인덱스도 무시되었으며, 따라서 해당 테이블의 어떤 인덱스에도 skip scan이 사용되지 않았습니다.

      이는 `NO_SKIP_SCAN` 힌트가 모든 인덱스에 적용 가능하지 않은 경우 skip scan에 대해 가능한 모든 키에 대한 처리가 수행되지 않았기 때문에 발생했습니다. (Bug #104670, Bug #33251616)
    - `WHERE column IN (list)`를 사용하는 쿼리는 값 목록의 길이가 길어질수록 점점 더 과도한 CPU 시간을 사용했습니다. (Bug #102037, Bug #32311183)