MySQL 8.0.14 릴리스 노트

DBA를 위한 핵심 내용

MySQL 8.0.14는 운영 기능이 크게 확장된 릴리스입니다. 이중 비밀번호, 전용 관리 포트, binlog/relay log 암호화, slow log 확장, LATERAL derived table, undo tablespace DDL, Group Replication 일관성 제어 등 DBA가 체감할 변화가 많습니다. 동시에 LATERAL 예약어 추가, 권한 요구사항 변화, mysql.user 구조 변경, mysql_upgrade 필요, 일부 Group Replication/복제 회귀가 뒤따랐으므로 단순 패치가 아니라 절차 기반 업그레이드로 다루는 것이 적절합니다. 보안 측면에서는 8.0.14 미만 8.0.x가 2019년 1월 CPU 다중 취약점 대상으로 분류됩니다. (Tenable)

1. 이중 비밀번호가 도입되어 무중단 비밀번호 교체가 쉬워졌지만, mysql.user 시스템 테이블 구조가 바뀌므로 업그레이드 후 mysql_upgrade와 서버 재시작 전까지 비밀번호 변경이 불가능합니다. 또한 admin_address/admin_port 기반 전용 관리 포트가 추가되어 max_connections 포화 시 DBA 접속 경로를 별도로 구성할 수 있습니다.
2. binlog_encryption으로 바이너리 로그와 릴레이 로그 저장 데이터를 암호화할 수 있고, log_slow_extra로 slow query log에 더 많은 실행 정보를 남길 수 있습니다. 다만 binlog/relay log 암호화는 전송 중 복제 이벤트나 트랜잭션 캐시까지 보호하지 않으므로, 복제 연결 TLS와 파일 보관 정책을 함께 설계해야 합니다.
3. 런타임 CREATE/DROP/ALTER UNDO TABLESPACE, 병렬 클러스터형 인덱스 읽기, --innodb-dedicated-server의 redo log 자동 설정 개선이 추가되었습니다. undo tablespace 관리는 유연해졌지만 상태 전환과 삭제 조건을 운영 절차에 반영해야 하며, 관련 결함도 다수 수정되었습니다.
4. group_replication_consistency가 추가되어 primary failover 직후 stale read 가능성을 제어할 수 있고, IPv6 지원 및 로컬 입력 채널 최적화가 도입되었습니다. 그러나 8.0.14에는 OS IPv6 비활성화 시 Group Replication 장애 회귀가 있었고 이는 8.0.15에서 수정되므로, IPv4 전용/IPv6 비활성화 환경은 8.0.14 단독 운영을 피하는 것이 좋습니다.
5. LATERAL이 예약어가 되었고, JSON_ARRAYAGG()/JSON_OBJECTAGG()의 윈도우 함수 사용, ST_Distance() 단위 인수, X Protocol SQL prepare 지원 등이 추가되었습니다. LATERAL을 식별자로 쓰는 스키마/쿼리는 인용 처리가 필요할 수 있습니다.
6. 5.7 덤프의 제거된 SQL 모드 처리, O_DIRECT_NO_FSYNC hang 가능성, 복제 그룹 커밋/GTID/binlog 관련 장애, 외래 키/파티셔닝/가상 컬럼/JSON 관련 서버 종료 및 잘못된 결과 문제가 다수 수정되었습니다. 업그레이드 전후에는 mysqldump/mysqlbinlog 복구 테스트, Group Replication failover 테스트, sql_require_primary_key와 SET PERSIST 사용 환경을 검증해야 합니다.

계정 관리 관련 사항

• 이전에는 각 MySQL 사용자 계정이 단일 비밀번호를 가질 수 있었습니다. 이제 MySQL은 계정이 기본 비밀번호와 보조 비밀번호로 지정되는 이중 비밀번호를 가질 수 있도록 허용합니다. 이 기능을 사용하면 복잡한 다중 서버 시스템에서 다운타임 없이 단계적인 비밀번호 변경을 원활하게 수행할 수 있습니다. 이중 비밀번호 기능을 지원하기 위해, ALTER USER 및 SET PASSWORD 문에는 이제 계정에 새 기본 비밀번호를 할당할 때 현재 비밀번호를 보조 비밀번호로 저장하는 RETAIN CURRENT PASSWORD 절이 있습니다. ALTER USER에는 더 이상 필요하지 않은 보조 비밀번호를 폐기하기 위한 DISCARD OLD PASSWORD 절도 있습니다. Password Management를 참조하십시오.

  이중 비밀번호 기능의 구현에는 mysql.user 시스템 테이블 구조 변경이 포함됩니다. 이전 버전에서 이 MySQL 릴리스로 업그레이드하는 경우, 이 시스템 데이터베이스 변경 사항을 반영하려면 mysql_upgrade를 실행하고 서버를 재시작해야 합니다. 이 작업이 완료될 때까지는 비밀번호 변경이 불가능합니다.

  (WL #11540)

Audit Log 관련 사항

• Audit API는 이제 새 audit_api_message_emit 컴포넌트를 사용하여 애플리케이션이 자체 메시지 이벤트를 Audit Log에 추가할 수 있도록 합니다. 이 컴포넌트에는 audit_api_message_emit_udf() 로드 가능 함수가 포함되어 있습니다. The Audit Message Component를 참조하십시오. (WL #11542)

컴파일 관련 사항

• 서버 빌드를 위한 Boost 라이브러리의 최소 버전은 이제 1.68.0입니다. (Bug #28478497)

컴포넌트 관련 사항

• 새로운 host_application_signal 컴포넌트 서비스는 컴포넌트가 호스트 애플리케이션에 신호를 전달할 수 있도록 제공됩니다. 예를 들어, 이 서비스는 복제 컴포넌트가 서버에 종료 신호를 보낼 수 있도록 합니다. (WL #12003)

설정 관련 사항

• 이전에는 COMPILATION_COMMENT CMake 옵션이 서버에서(예를 들어 version_comment 시스템 변수를 설정하기 위해) 그리고 다른 프로그램에서 사용되었습니다. 그러나 값에 “server”라는 단어가 포함된 경우, 다른 프로그램에서 사용하기에는 적절하지 않았습니다. 이제 서버는 새로운 COMPILATION_COMMENT_SERVER 옵션을 사용합니다. 다른 프로그램은 계속 COMPILATION_COMMENT을 사용합니다. (Bug #28888510)

• .gitignore 파일의 내용이 정리되었습니다. 이 파일의 많은 부분은 이전의 .bzrignore 파일에서 이어받은 것이며 관련성이 없었습니다. 이 정리의 한 가지 영향은 소스 내 빌드가 허용되지 않는다는 점입니다. (Bug #28341794, Bug #91626)

• MySQL Server는 이제 관리 연결을 위해 TCP/IP 포트를 특별히 설정할 수 있도록 허용합니다. 이는 max_connections 연결이 이미 설정되어 있더라도 일반 연결에 사용되는 네트워크 인터페이스에서 허용되는 단일 관리 연결에 대한 대안을 제공합니다. 관리 네트워크 인터페이스는 다음 특성을 가집니다:

  • 인터페이스는 시작 시 admin_address 시스템 변수가 해당 IP 주소를 나타내도록 설정된 경우에만 활성화됩니다. admin_address가 설정되지 않은 경우, 서버는 관리 인터페이스를 유지하지 않습니다.

  • admin_port 시스템 변수는 인터페이스 TCP/IP 포트 번호를 지정합니다(기본값 33062).

  • 관리 연결 수에는 제한이 없지만, 연결은 SERVICE_CONNECTION_ADMIN 권한을 가진 사용자에게만 허용됩니다.

  • create_admin_listener_thread 시스템 변수는 DBA가 시작 시 관리 인터페이스에 자체의 별도 스레드가 있는지 여부를 선택할 수 있게 합니다. 기본값은 OFF입니다. 즉, 기본 인터페이스의 일반 연결에 대한 매니저 스레드가 관리 인터페이스의 연결도 처리합니다.

    아이디어를 제안해 준 Facebook에 감사드립니다(코드도 기여했지만, 해당 코드는 사용되지 않았습니다). (Bug #27847672, Bug #90395, WL #12138)

사용 중단 및 제거 관련 사항

• 더 이상 사용되지 않는 resolveip 및 resolve_stack_dump 유틸리티가 제거되었으며 더 이상 MySQL 배포판에 포함되지 않습니다. resolveip 대신 nslookup, host 또는 dig를 사용할 수 있습니다. 공식 MySQL 빌드의 스택 추적은 항상 심볼화되므로 resolve_stack_dump를 사용할 필요가 없습니다. (WL #12619, WL #12620)

SQL 함수 및 연산자 관련 사항

• JSON_ARRAYAGG() 및 JSON_OBJECTAGG() 집계 함수는 이제 OVER 절이 있으면 윈도우 함수로 사용할 수 있습니다. Aggregate Function Descriptions를 참조하십시오. (WL #11574)

로깅 관련 사항

• 새로운 시스템 변수인 log_slow_extra를 활성화하면, 서버는 느린 명령문에 대한 정보를 제공하는 추가 필드를 슬로우 쿼리 로그 라인에 기록합니다. 또한 명령문 타임스탬프를 나타내기 위해 로그에 기록되는 SET 라인은 이제 실행 종료 시점의 시간이 아니라 명령문 실행 시작 시점의 시간을 사용합니다. The Slow Query Log를 참조하십시오. 이 기능의 기반이 된 기여를 제공한 Facebook에 감사드립니다. (Bug #27535580, Bug #89637, WL #12393)

• 이제 바이너리 로그 파일과 릴레이 로그 파일을 암호화할 수 있으므로, 외부 공격자가 이러한 파일과 그 안에 포함된 잠재적으로 민감한 데이터를 오용하는 것을 방지하고, 해당 파일이 저장된 운영체제의 사용자가 무단으로 보는 것도 방지하는 데 도움이 됩니다.

  새 binlog_encryption 시스템 변수를 ON으로 설정하여 MySQL 서버에서 암호화를 활성화합니다. 기본값은 OFF입니다. 이 시스템 변수는 바이너리 로그 파일과 릴레이 로그 파일에 대해 암호화를 켭니다. 암호화를 활성화한 상태로 서버를 처음 시작하면, 바이너리 로그와 릴레이 로그가 초기화되기 전에 새 바이너리 로그 암호화 키가 생성됩니다. 이 키는 각 바이너리 로그 파일(서버에 바이너리 로깅이 활성화된 경우)과 릴레이 로그 파일(서버에 복제 채널이 있는 경우)에 대한 파일 비밀번호를 암호화하는 데 사용되며, 파일 비밀번호에서 생성된 추가 키가 파일의 데이터를 암호화하는 데 사용됩니다.

  서버가 실행 중인 동안 암호화를 활성화하면, 그 시점에 새 바이너리 로그 암호화 키가 생성되고, 새 파일과 이후 파일이 암호화되도록 바이너리 로그 파일과 릴레이 로그 파일이 순환됩니다. binlog_encryption 시스템 변수를 OFF로 변경하여 암호화를 비활성화하면, 바이너리 로그 파일과 릴레이 로그 파일이 즉시 순환되고 이후의 모든 로깅은 암호화되지 않습니다. 이전에 암호화된 파일은 자동으로 복호화되지 않지만, 서버는 여전히 해당 파일을 읽을 수 있습니다. (SHOW BINARY LOGS 명령문은 이제 각 바이너리 로그 파일이 암호화되어 있는지 또는 암호화되지 않았는지를 표시합니다.) 서버가 실행 중인 동안 암호화를 활성화하거나 비활성화하려면 SUPER 권한 또는 새 BINLOG_ENCRYPTION_ADMIN 권한이 필요합니다.

  파일에 사용되는 암호화 알고리즘인 AES (Advanced Encryption Standard) 암호화 알고리즘은 MySQL Server에 내장되어 있으며 설정할 수 없습니다. 로그 파일의 파일 비밀번호를 암호화하는 데 사용되는 바이너리 로그 암호화 키는 MySQL Server의 내장 keyring 서비스를 사용하여 각 MySQL 서버 인스턴스에 대해 특별히 생성되는 256비트 키입니다. 현재 서버에서 사용 중인 바이너리 로그 암호화 키는 바이너리 로그 마스터 키라고 합니다.

  새로운 binlog_rotate_encryption_master_key_at_startup 시스템 변수는 서버가 재시작될 때 바이너리 로그 마스터 키가 자동으로 순환되는지 여부를 제어합니다. 이 시스템 변수가 ON으로 설정되면 서버가 재시작될 때마다 새 바이너리 로그 암호화 키가 생성되어 새 바이너리 로그 마스터 키로 사용됩니다. 기본값인 OFF로 설정되면 재시작 후 기존 바이너리 로그 마스터 키가 다시 사용됩니다.

  MySQL 서버 인스턴스에 대해 암호화가 활성화되어 있을 때는 바이너리 로그 파일 및 릴레이 로그 파일에 기록되는 저장 데이터만 암호화된다는 점에 유의하십시오. mysqlbinlog를 포함한 MySQL 클라이언트로 전송되는 복제 이벤트 스트림의 이동 중 데이터는 항상 암호화되지 않은 형식이므로, 연결 암호화를 사용하여 전송 중에 보호해야 합니다. 트랜잭션 중 바이너리 로그 트랜잭션 및 문 캐시에 보관되는 사용 중 데이터와, 해당 캐시에서 사용할 수 있는 공간을 초과하여 디스크의 임시 파일에 저장되는 모든 데이터도 암호화되지 않은 형식입니다. 임시 파일과 캐시는 트랜잭션을 처리하는 스레드가 종료될 때 삭제됩니다. (WL #10957)

• 로깅 설정을 지정하는 시작 옵션을 처리하기 전에 생성되는 오류 로그 메시지와 관련하여 서버 로깅 동작이 변경되었습니다. 이전에는 서버가 기본 타임스탬프, 형식 및 상세 수준으로 메시지를 생성하고, 이를 버퍼링한 다음, 오류 로그 설정을 알게 된 후 플러시했습니다. 이러한 초기 메시지는 기본 로깅 설정을 사용했기 때문에 시작 옵션에서 지정한 내용과 다를 수 있었습니다.

  이제 서버는 형식이 지정된 로그 메시지가 아니라 로그 이벤트를 버퍼링합니다. 이를 통해 설정을 알게 된 후 해당 이벤트에 설정값을 소급 적용할 수 있으며, 그 결과 플러시된 메시지는 기본값이 아니라 설정된 값을 사용합니다. 자세한 내용은 Error Log Output Format을 참조하십시오. (WL #11875)

Optimizer 관련 사항

• 이전에는 파생 테이블과 공통 테이블 표현식에 외부 참조를 포함할 수 없었습니다. 이제 외부 참조가 허용됩니다. (WL #461)

패키징 관련 사항

• Ubuntu 18.10 및 Fedora 29는 기본적으로 OpenSSL 1.1.1을 설치하지만, OpenSSL 1.1.1은 MySQL에서 완전히 지원되지 않습니다. MySQL을 설치하려면 OpenSSL 1.0.2 호환성 패키지를 설치해야 합니다. (Bug #28981868)

Performance Schema 관련 사항

• Performance Schema 문 이벤트 테이블(events_statements_current, events_statements_history, 및 events_statements_history_long)에는 이제 SQL 수준에서 서버가 유지하는 쿼리 ID를 나타내는 STATEMENT_ID 컬럼이 있습니다. 컬럼 값은 원자적으로 증가되는 전역 카운터를 사용하여 생성되므로 서버 인스턴스 내에서 고유합니다. (WL #12165)

Pluggable Authentication 관련 사항

• LDAP 포트 번호가 636 또는 3269로 설정된 경우, 플러그인은 이제 LDAP 대신 LDAPS(SSL을 통한 LDAP)를 사용합니다. 포트 번호는 authentication_ldap_sasl_server_port 또는 authentication_ldap_simple_server_port 시스템 변수를 사용하여 설정할 수 있습니다. (LDAPS는 startTLS와 다릅니다.) (Bug #28743563)
• 이전에는 프록시를 사용하는 LDAP 인증에서, LDAP 인증 플러그인이 LDAP 서버가 반환한 첫 번째 그룹 이름을 MySQL 프록시된 사용자 계정 이름으로 사용했습니다. 이제 MySQL 계정의 인증 문자열은 일치시킬 그룹 목록을 선호 순서대로 지정할 수 있으며, 선택적으로 일치하는 그룹 이름을 지정된 MySQL 프록시된 사용자 이름에 매핑할 수 있습니다. LDAP Pluggable Authentication을 참조하십시오. (WL #12005)

보안 관련 사항

• 일부 플랫폼(Windows, macOS 및 Generic Linux)에서 MySQL과 함께 번들로 제공되는 OpenSSL 라이브러리가 버전 1.0.2q로 업그레이드되었습니다. 그 밖의 모든 플랫폼에서는 MySQL이 시스템에 설치된 OpenSSL을 사용합니다. 새 OpenSSL 버전에서 수정된 문제는 http://www.openssl.org/news/vulnerabilities.html에 설명되어 있습니다. (Bug #28988091)

• 이후의 서버 재시작에 영향을 주기 위해, SET PERSIST 및 SET PERSIST_ONLY 구문은 시스템 변수가 데이터 디렉터리의 mysqld-auto.cnf 옵션 파일에 지속되도록 합니다. 그러나 일부 시스템 변수는 지속될 수 없습니다(예를 들어 민감한 데이터가 관련되기 때문입니다). 따라서 이러한 변수는 원격 관리자가 수행하는 세션 내에서 런타임에 설정할 수 없으며, 따라서 관리자가 서버 호스트에 로그인하여 my.cnf 옵션 파일을 직접 수정해야 합니다.

  이제 MySQL은 사용자가 이전에 지속할 수 없었던 많은 시스템 변수의 런타임 관리를 수행할 수 있도록 허용하여, 특정 제한 조건에서 해당 변수를 지속할 수 있게 합니다. 이 기능을 활성화하려면 이러한 제한된 시스템 변수를 지속할 수 있음을 나타내는 SSL 인증서 X.509 Subject 값을 지정하고, 새 persist_only_admin_x509_subject 시스템 변수를 해당 Subject 값으로 설정하십시오. 암호화된 연결을 사용하여 서버에 연결하고 지정된 Subject 값을 가진 SSL 인증서를 제공하는 사용자는 그런 다음 SET PERSIST_ONLY를 사용하여 지속 제한 시스템 변수를 지속할 수 있습니다. 자세한 내용은 Nonpersistible and Persist-Restricted System Variables를 참조하십시오. (WL #12086)

• 대부분의 시스템 변수는 세션 값을 설정하는 데 특별한 권한이 필요하지 않으며, 현재 세션에 영향을 주기 위해 모든 사용자가 설정할 수 있습니다. 일부 시스템 변수의 경우 세션 값을 설정하면 현재 세션 밖에도 영향을 줄 수 있으므로, 특별한 권한을 가진 사용자만 수행할 수 있는 제한된 작업입니다. 이전에는 SYSTEM_VARIABLES_ADMIN 또는 SUPER 중 하나가 이러한 권한으로 인정되었지만, 두 권한 모두 세션 변수 설정 이외의 작업도 허용합니다. 새로운 SESSION_VARIABLES_ADMIN 권한을 사용하면 다른 작업도 활성화하지 않고, 제한된 세션 변수를 설정할 수 있는 능력만 사용자에게 부여할 수 있습니다.

  SESSION_VARIABLES_ADMIN으로 허용되는 모든 작업은 SYSTEM_VARIABLES_ADMIN 또는 SUPER로도 허용되므로, 후자의 권한 중 하나를 이미 가진 모든 사용자는 암묵적으로 SESSION_VARIABLES_ADMIN을 실질적으로 가진 것이며 SESSION_VARIABLES_ADMIN을 명시적으로 부여받을 필요가 없습니다. 그러나 사용자가 제한된 세션 시스템 변수를 수정할 수 있도록 하기 위한 목적으로만 SYSTEM_VARIABLES_ADMIN 또는 SUPER를 부여받은 경우, 관리자는 SYSTEM_VARIABLES_ADMIN 및 SUPER를 회수하고 대신 SESSION_VARIABLES_ADMIN을 부여하여 해당 사용자의 권한 범위를 줄일 수 있습니다. 지침은 System Variable Privileges를 참조하십시오.

  이전에 제한되었던 다음 세션 변수에는 SYSTEM_VARIABLES_ADMIN 또는 SUPER가 필요했지만, 이제 SESSION_VARIABLES_ADMIN으로도 설정할 수 있습니다:

  binlog_format
  binlog_row_image
  binlog_row_value_options
  binlog_rows_query_log_events
  debug
  debug_sync
  default_collation_for_utf8mb4
  explicit_defaults_for_timestamp
  gtid_next
  histogram_generation_max_mem_size
  original_commit_timestamp
  sql_log_bin
  sql_log_off
  sql_require_primary_key
  

  이전에 제한되지 않았던 다음 세션 변수는 이제 제한되며, 이를 설정하려면 적어도 SESSION_VARIABLES_ADMIN이 필요합니다(SYSTEM_VARIABLES_ADMIN 또는 SUPER를 가진 사용자도 설정할 수 있습니다):

  auto_increment_increment
  auto_increment_offset
  binlog_direct_non_transactional_updates
  bulk_insert_buffer_size
  character_set_filesystem
  character_set_database
  collation_database
  pseudo_slave_mode
  pseudo_thread_id
  rbr_exec_mode
  transaction_write_set_extraction
  

  (WL #12217)

공간 데이터 지원

• ST_Distance() 함수는 이제 반환 값의 단위를 지정할 수 있도록 하는 선택적 세 번째 인수를 받습니다. 허용되는 단위는 새로운 INFORMATION_SCHEMA ST_UNITS_OF_MEASURE 테이블에 나열된 단위입니다. 객체 형태를 사용하는 공간 관계 함수 및 INFORMATION_SCHEMA ST_UNITS_OF_MEASURE 테이블을 참조하십시오. (WL #11000)

SQL 문법 관련 사항

• 파생 테이블 앞에는 이제 LATERAL 키워드를 붙여, 동일한 FROM 절에서 앞에 오는 테이블의 컬럼을 참조하는 것(의존하는 것)이 허용됨을 지정할 수 있습니다. LATERAL로 지정된 파생 테이블은 FROM 절에서만 나타날 수 있으며, 쉼표로 구분된 테이블 목록이나 조인 명세(JOIN, INNER JOIN, CROSS JOIN, LEFT [OUTER] JOIN 또는 RIGHT [OUTER] JOIN) 안에 나타날 수 있습니다. Lateral 파생 테이블은 nonlateral 파생 테이블로는 수행할 수 없거나 효율이 낮은 우회 방법이 필요한 특정 SQL 작업을 가능하게 합니다. Lateral Derived Tables를 참조하십시오.

  LATERAL은 이제 예약어이며 식별자 따옴표 처리 없이는 식별자로 사용할 수 없습니다.

  (WL #8652)

Thread Pool 관련 사항

• thread pool 플러그인과 함께 제공되는 INFORMATION_SCHEMA 테이블이 Performance Schema 테이블로 제공되도록 마이그레이션되었습니다. 이제 INFORMATION_SCHEMA 테이블은 사용 중단되었으며 향후 MySQL 버전에서 제거될 예정입니다. 애플리케이션은 이전 테이블에서 새 테이블로 전환해야 합니다. 예를 들어 애플리케이션이 다음 쿼리를 사용하는 경우:

  SELECT * FROM INFORMATION_SCHEMA.TP_THREAD_STATE;
  

  애플리케이션은 대신 다음 쿼리를 사용해야 합니다:

  SELECT * FROM performance_schema.tp_thread_state;
  

  자세한 내용은 Performance Schema Thread Pool Tables를 참조하십시오. (WL #11547)

X 플러그인 관련 사항

• X Plugin은 이제 오류 처리 클래스에 5자리 SQLSTATE 오류 코드를 포함합니다. 이전에는 SQL 오류에 대해 SQLSTATE 오류 코드가 클라이언트에 반환되었지만, MySQL 고유 오류 번호만 노출되었습니다. (Bug #28735058)
• 문서 컬렉션을 쿼리할 때, SQL 쿼리의 플레이스홀더에 대한 인수로 boolean 값이 사용되면 예상치 못한 결과가 반환되었습니다. 이제 이 상황에서 boolean 값이 올바르게 처리되도록 boolean 값에 대한 새로운 변환 특수화가 추가되었습니다. (Bug #28227037)
• X Protocol은 이제 검색된 데이터를 반환하기 전에 항상 utf8mb4 캐릭터셋(utf8mb4_general_ci 콜레이션 사용)으로 변환합니다. (Bug #28180155)
• X Protocol은 이제 SQL prepare 기능을 지원합니다. (WL #9270)

추가되거나 변경된 기능

• InnoDB: innodb_buffer_pool_in_core_file 변수를 비활성화하면 InnoDB 버퍼 풀 페이지를 제외하여 core 파일의 크기가 줄어듭니다. 이 변수를 사용하려면 core_file 변수가 활성화되어 있어야 하며, 운영 체제가 Linux 3.4 이상에서 지원되는 madvise()에 대한 MADV_DONTDUMP 비 POSIX 확장을 지원해야 합니다. 자세한 내용은 Excluding Buffer Pool Pages from Core Files를 참조하십시오.

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

• InnoDB: 기본적으로 undo 로그는 MySQL 인스턴스가 초기화될 때 생성되는 두 개의 undo 테이블스페이스에 위치합니다.

  추가 undo 테이블스페이스는 런타임에 CREATE UNDO TABLESPACE 문법을 사용하여 선택한 위치에 생성할 수 있습니다.

  CREATE UNDO TABLESPACE tablespace_name ADD DATAFILE 'file_name.ibu';
  

  CREATE UNDO TABLESPACE 문법을 사용하여 생성된 undo 테이블스페이스는 런타임에 DROP UNDO TABLESPACE 문법을 사용하여 삭제할 수 있습니다.

  DROP UNDO TABLESPACE tablespace_name;
  

  ALTER UNDO TABLESPACE 문법을 사용하여 undo 테이블스페이스를 활성 또는 비활성으로 표시할 수 있습니다.

  ALTER UNDO TABLESPACE tablespace_name SET {ACTIVE|INACTIVE};
  

  테이블스페이스의 상태를 표시하는 STATE 컬럼이 INFORMATION_SCHEMA.INNODB_TABLESPACES 테이블에 추가되었습니다. undo 테이블스페이스는 삭제되기 전에 empty 상태여야 합니다.

  이전에 사용 중단된 innodb_undo_tablespaces 변수는 더 이상 설정할 수 없으며 향후 MySQL 버전에서 제거될 예정입니다.

  자세한 내용은 Undo Tablespaces를 참조하십시오. (WL #9508)

• InnoDB: InnoDB는 이제 병렬 클러스터형 인덱스 읽기를 지원하며, 이를 통해 CHECK TABLE 성능이 향상될 수 있습니다. 이 기능은 보조 인덱스 스캔에는 적용되지 않습니다. 병렬 클러스터형 인덱스 읽기가 수행되려면 innodb_parallel_read_threads 세션 변수를 1보다 큰 값으로 설정해야 합니다. 기본값은 4입니다. 병렬 클러스터형 인덱스 읽기를 수행하는 데 사용되는 실제 스레드 수는 innodb_parallel_read_threads 설정 또는 스캔할 인덱스 서브트리 수 중 더 작은 값으로 결정됩니다. (WL #11720)

• InnoDB: CREATE TABLESPACE 문장의 ADD DATAFILE 절은 이제 선택 사항이며, 이를 통해 FILE 권한이 없는 사용자가 테이블스페이스를 생성할 수 있습니다. ADD DATAFILE 절 없이 실행된 CREATE TABLESPACE 문장은 고유한 파일 이름을 가진 테이블스페이스 데이터 파일을 암시적으로 생성합니다. (WL #12236)

• InnoDB: 서버가 --innodb-dedicated-server로 시작될 때, 로그 파일의 크기와 개수는 이제 이 옵션에 의해 설정된 버퍼 풀에 따라 결정됩니다. 이전에는 로그 파일 크기가 서버에서 감지된 메모리 양에 따라 설정되었으며, 로그 파일 개수는 자동으로 설정되지 않았습니다. 전용 MySQL 서버에 대한 자동 InnoDB 설정 활성화를 참조하십시오. (WL #12300)

• Replication: 복제에서 내부적으로 사용하기 위해 두 개의 새 세션 변수가 추가되었습니다. original_server_version 및 immediate_server_version은 트랜잭션과 연결된 MySQL 서버 릴리스 번호를 복제 토폴로지를 통해 전송하여 버전 간 복제를 지원합니다. original_server_version은 트랜잭션이 원래 커밋된 서버의 MySQL Server 릴리스 번호를 보유합니다(예: MySQL 8.0.14 서버 인스턴스의 경우 80014). immediate_server_version은 복제 토폴로지에서 직접 마스터인 서버의 MySQL Server 릴리스 번호를 보유합니다. 이러한 서버 중 하나 또는 복제 토폴로지에서 중간에 있는 다른 서버가 이러한 세션 시스템 변수를 지원하지 않는 이전 릴리스인 경우, 해당 값은 0으로 설정됩니다.

  이 정보를 사용하면 슬레이브는 관련된 릴리스 간에 문법 변경 또는 의미 변경이 발생한 위치를 인식하고 이를 적절히 처리하여, 이전 릴리스의 마스터에서 시작된 데이터를 올바르게 처리할 수 있습니다. 이 정보는 복제 그룹의 하나 이상의 멤버가 다른 멤버보다 더 새로운 릴리스인 Group Replication 환경에서도 사용할 수 있습니다. 변수 값은 각 트랜잭션에 대해 바이너리 로그에서 볼 수 있으며(서버에서 GTID를 사용하지 않는 경우 Gtid_log_event 또는 Anonymous_gtid_log_event의 일부로), 버전 간 복제 문제를 디버깅하는 데 도움이 될 수 있습니다. (WL #11879)

• 복제: 단일 프라이머리 모드에서 그룹을 실행할 때, 적용할 백로그에 트랜잭션이 보관된 상태에서 새 프라이머리가 선출되는 경우, 새 프라이머리를 대상으로 한 읽기 작업이 오래된 값을 반환할 가능성이 있었습니다. 이제 group_replication_consistency 변수를 사용하여 이 상황에서 그룹이 동작하는 방식을 제어할 수 있습니다. group_replication_consistency가 EVENTUAL로 설정되면, 아직 적용되지 않은 백로그가 있는 경우에도 새 프라이머리가 읽기 요청에 응답하며, 이는 이전 동작과 일치하고 백로그가 적용되는 동안 클라이언트가 오래된 값을 읽을 수 있는 위험을 수반합니다. 이 기간 동안에는 super_read_only 모드가 활성화되어 있으므로 새 프라이머리에 대한 쓰기가 실패합니다. group_replication_consistency가 BEFORE_ON_PRIMARY_FAILOVER로 설정되면, 이전 프라이머리의 백로그를 적용 중인 새로 선출된 프라이머리를 대상으로 하는 모든 새 읽기 또는 쓰기 쿼리는 백로그가 적용될 때까지 보류됩니다. 이를 통해 클라이언트가 항상 자신이 쓴 최신 값을 읽도록 보장하지만, 클라이언트가 새 프라이머리에서 읽을 수 있기 전에 백로그가 적용될 때까지 기다려야 할 수도 있음을 의미합니다. (WL #11123)

  참조: 다음도 참조하십시오: Bug #26004894.

• Group Replication: 이제 Group Replication의 Group Communication System (GCS) 및 그룹 통신 엔진(XCom, Paxos 변형)은 IPv6을 완전히 지원하므로, 복제 그룹 멤버는 내부 그룹 통신에 IPv4 주소의 대안으로 IPv6 주소를 사용할 수 있습니다. IPv6의 localhost 주소와 IPv6의 프라이빗 서브네트워크 주소(unique-local 주소 및 link-local unicast 주소)는 수동 화이트리스트가 지정되지 않은 경우 사용하도록 Group Replication의 자동 화이트리스트에 추가됩니다.

  복제 그룹의 모든 멤버가 Group Replication에 IPv6 주소 사용을 지원하는 MySQL 서버 버전인 경우, 그룹에는 IPv6 주소를 사용하는 멤버와 IPv4 주소를 사용하는 멤버가 혼재될 수 있습니다. 참여하는 멤버는 연결을 위해 시드 멤버가 제공하는 프로토콜과 일치하는 화이트리스트에 포함된 IP 주소 또는 호스트 이름을 제공해야 하지만, 참여하는 멤버의 기본 식별 주소 또는 호스트 이름(group_replication_local_address)은 두 프로토콜 중 하나를 사용할 수 있습니다. 멤버가 IPv4 주소와 IPv6 주소 모두로 확인되는 호스트 이름을 사용하는 경우, Group Replication 연결에는 항상 IPv4 주소가 사용됩니다.

  복제 그룹의 기존 멤버 일부 또는 전체가 Group Replication에서 IPv6 주소 사용을 지원하지 않는 이전 MySQL Server 버전을 사용하는 경우, 조인하는 멤버는 그룹 통신을 위해 group_replication_local_address 옵션에 IPv4 주소를 제시해야 합니다. 모든 그룹 멤버가 업그레이드되면 그룹을 IPv6 주소로 마이그레이션할 수 있습니다. (Bug #26088469, Bug #27757729, Bug #90217, WL #11926)

• Group Replication: 이제 MySQL Group Replication은 TCP 소켓을 사용하는 대신 전용 입력 채널을 사용하여 통신할 수 있습니다. 새 입력 채널은 Group Replication 로직과 기반 그룹 통신 엔진(XCom, Paxos 변형)의 로컬 인스턴스 간 통신에 공유 메모리를 사용합니다.

  이전에는 로컬 XCom 인스턴스와의 통신이 항상 TCP 소켓, 즉 각 그룹 멤버에 대해 group_replication_local_address 시스템 변수로 지정되는 네트워크 주소를 사용하여 수행되었습니다. 이 방식은 네트워크 프로토콜 스택을 통한 메모리 복사 및 데이터 직렬화처럼 로컬 통신에는 불필요한 오버헤드를 발생시켰습니다. 각 그룹 멤버가 원격 XCom 인스턴스와 통신하려면 여전히 TCP 소켓(group_replication_local_address)이 필요합니다. 이제 Group Replication의 Group Communication System (GCS) 컴포넌트는 각 Group Replication 작업에 대해 입력 채널 또는 TCP 중 가장 적절한 통신 방법을 선택합니다. 예를 들어 그룹에 조인하는 프로세스에는 원격 XCom 인스턴스와의 통신이 필요하므로 TCP를 사용해야 합니다. 그러나 그룹에서 멤버를 제거하는 프로세스에는 로컬 XCom 인스턴스와의 통신만 필요하므로 입력 채널이 사용됩니다. 네트워킹 메커니즘을 사용하는 통신과 관련된 오버헤드를 최소화하기 위해 가능한 모든 곳에서 입력 채널이 선택됩니다. (WL #9850)

• Microsoft Windows: MySQL 서버가 생성한 named pipe에서 클라이언트에 부여되는 액세스 제어가 이제 Windows에서 성공적인 통신에 필요한 최소한으로 설정됩니다. 최신 MySQL 클라이언트 소프트웨어는 추가 설정 없이 named pipe 연결을 열 수 있습니다. 이전 클라이언트 소프트웨어를 즉시 업그레이드할 수 없는 경우, 새 named_pipe_full_access_group 서버 시스템 변수를 사용하여 Windows 그룹에 named pipe 연결을 여는 데 필요한 권한을 부여할 수 있습니다. 전체 액세스 그룹의 멤버십은 제한적이고 일시적이어야 합니다. (WL #12445)

• 최소 서버 RPM은 주로 Docker 이미지에 사용됩니다. 더 나은 Docker 호환성을 위해 rpm-docker 설정 파일에서 log-error 라인이 제거되었습니다. 이렇게 하면 로깅이 stdout/stderr로 이동하여 Docker 자체 인터페이스를 사용할 수 있습니다. (Bug #28692675)

• 외래 키 생성 및 삭제와 관련된 오류 메시지가 더 구체적이고 정보성이 높도록 개선되었습니다. (Bug #28526309, Bug #92087)

• 캐릭터셋 변환을 시도했지만 실패한 ALTER TABLE 문에 대한 오류 메시지가 어떤 컬럼에서 오류가 발생했는지를 나타내도록 개선되었습니다. (Bug #27546306, Bug #88738)

• 이전에는 숫자 값을 받는 명령 옵션의 경우, 값에 K, M 또는 G 접미사를 붙여 1024, 10242 또는 10243의 승수를 나타낼 수 있었습니다. 이제 접미사로 T, P 및 E도 사용할 수 있으며, 각각 10244, 10245 또는 10246의 승수를 나타냅니다. 패치를 제공해 준 Daniel Black에게 감사드립니다. (Bug #27306931, Bug #89017)

• 확장성과 성능을 개선하기 위해 리소스 그룹 잠금이 개정되었습니다. (Bug #27148580)

• 시작 옵션 --binlog-row-event-max-size에 이제 대응하는 시스템 변수 binlog_row_event_max_size가 있습니다. 시작 옵션과 시스템 변수는 로우 기반 바이너리 로그 이벤트의 최대 크기에 대한 소프트 제한을 설정하며, 기본 설정은 8192바이트입니다. 가능한 경우, 바이너리 로그에 저장된 로우는 이 설정 값 이하의 크기를 갖는 이벤트로 그룹화됩니다. 이벤트를 분할할 수 없는 경우 최대 크기를 초과할 수 있습니다.

  binlog_row_event_max_size 전역 시스템 변수는 읽기 전용이며 서버 시작 시에만 설정할 수 있습니다. 따라서 이 값은 SET 문에서 PERSIST_ONLY 키워드 또는 @@persist_only 한정자를 사용해야만 수정할 수 있습니다. 시스템 변수가 추가되었다는 것은 이 설정을 Performance Schema 테이블이나 SHOW VARIABLES 또는 SELECT 문을 사용하여 확인할 수 있음을 의미합니다. (Bug #19985377, Bug #74728, WL #12385)

• 이제 다음 조건이 적용되는 경우 ALTER TABLE을 사용하여 컬럼 캐릭터셋을 인플레이스 방식으로(테이블 재빌드 없이) 변경할 수 있습니다:

  • 컬럼 데이터 타입이 CHAR, VARCHAR, TEXT 타입 또는 ENUM입니다.
  • 캐릭터셋 변경이 utf8mb3에서 utf8mb4로의 변경이거나, 임의의 캐릭터셋에서 binary로의 변경입니다.
  • 컬럼에 인덱스가 없습니다.

  (WL #11605)

• 새로운 -DFORCE_INSOURCE_BUILD CMake 옵션은 in-source 빌드를 강제할지 여부를 정의합니다. Out-of-source 빌드가 권장되며, 이는 동일한 소스에서 여러 빌드를 허용하고 빌드 디렉터리를 제거하여 정리를 빠르게 수행할 수 있기 때문입니다. In-source 빌드를 강제하려면 -DFORCE_INSOURCE_BUILD=ON과 함께 CMake를 호출하십시오.

수정된 버그

• 중요한 변경 사항: MySQL 5.7 서버의 덤프를 MySQL 8.0을 실행 중인 서버로 가져오면 8.0 서버에서 지원하지 않는 SQL 모드가 사용된 경우 ER_WRONG_VALUE_FOR_VAR로 실패하는 경우가 많았습니다. 이는 NO_AUTO_CREATE_USER가 MySQL 5.7에서는 기본적으로 활성화되어 있지만 MySQL 8.0에서는 지원되지 않는다는 사실 때문에 자주 발생할 수 있었습니다.

  이러한 상황에서 서버의 동작은 이제 pseudo_slave_mode 시스템 변수 설정에 따라 달라집니다. 이것이 false이면 서버는 ER_UNSUPPORTED_SQL_MODE로 모드 설정을 거부합니다. pseudo_slave_mode가 true이면 서버는 지원되지 않는 모드를 무시하고 경고를 제공합니다. mysqlbinlog는 SQL을 실행하기 전에 pseudo_slave_mode를 true로 설정한다는 점에 유의하십시오. (Bug #90337, Bug #27828236)

• InnoDB: 백그라운드 purge 스레드가 undo 로그를 truncate한 후 전역 및 백업 메타데이터 잠금이 해제되지 않았습니다. (Bug #29215254, Bug #93901)

• InnoDB: MySQL이 Solaris X86에서 시작되지 않았습니다. TempTable 스토리지 엔진의 정적 thread-local tables 변수가 올바르게 초기화되지 않았습니다. (Bug #28987365)

• InnoDB: 데드락 감지 중 사용되는 래칭 로직이 단순화되었습니다. (Bug #28904966)

• InnoDB: 클러스터형 인덱스 레코드의 이전 버전에 대한 잘못된 레코드 오프셋으로 인해 디버그 어설션이 발생했습니다. (Bug #28825617)

  참조: 이 문제는 다음의 회귀입니다: Bug #25540277.

• InnoDB: 히스토리 목록의 길이가 innodb_max_purge_lag를 초과할 때 적용되는 최소 DML 지연이 5000마이크로초에서 5마이크로초로 감소했습니다. (Bug #28813453)

• InnoDB: 한 스레드가 테이블을 삭제하려고 시도하는 동안 다른 스레드가 암호화된 테이블스페이스를 생성할 때, 잘못된 잠금 순서로 인해 데드락이 발생했습니다. (Bug #28774259)

• InnoDB: ALTER TABLESPACE가 지원되지 않는 테이블스페이스 속성을 무시하지 못했습니다. (Bug #28656611)

• InnoDB: 암시적 잠금을 명시적 잠금으로 변환하는 로직이 단순화되고 최적화되었습니다. (Bug #28637472)

• InnoDB: 프래그먼트 페이지 할당 실패로 인해 어설션이 발생했습니다. (Bug #28615893)

• InnoDB: 잘못 배치된 디버그 지점으로 인해 플러시된 LOB 페이지가 손상된 것으로 간주되었습니다. (Bug #28607368)

• InnoDB: TempTable 스토리지 엔진이 tmpdir 변수로 정의된 디렉터리 대신 시스템 임시 디렉터리에 임시 파일을 잘못 생성했습니다. (Bug #28598943)

• InnoDB: 전체 텍스트 검색 보조 테이블의 이름과 유사한 이름을 가진 테이블을 삭제하려고 하면 어설션 실패가 발생했습니다. (Bug #28577083)

• InnoDB: UPDATE 쿼리에서 호출된 함수가 가상 컬럼을 고려하지 않았습니다. (Bug #28560650)

• InnoDB: 버퍼 풀 zip 해시 뮤텍스에 대해 잘못된 키가 정의되었습니다. (Bug #28556539)

• InnoDB: mysql.innodb_table_stats 및 mysql.innodb_index_stats 테이블과 관련된 백그라운드 트랜잭션의 데드락 처리가 수정되었습니다. 내부 테이블이 데드락 사이클에 포함될 때 트리거되는 어설션에 해당 테이블들이 잘못 포함되었습니다. (Bug #28523042, Bug #92069)

• InnoDB: innodb_spin_wait_delay를 높은 값으로 설정하면 서버 종료를 시도할 때 어설션 실패가 발생했습니다. 이 실패가 발생하지 않도록 innodb_spin_wait_delay 최댓값이 1000으로 낮아졌습니다. (Bug #28489407, Bug #91973)

• InnoDB: 외래 키 제약 조건과 인덱싱된 가상 컬럼이 있는 테이블에 대한 ON DELETE CASCADE 작업으로 인해 서버가 종료되었습니다. (Bug #28470805)

• InnoDB: 가상 컬럼 값을 포함하는 잘못 작성된 DML 로그에서 어설션이 발생했습니다. (Bug #28448853)

• InnoDB: DATA DIRECTORY 절을 사용하여 MySQL 데이터 디렉터리 외부에 생성된 테이블에서 실행할 때 RENAME TABLE 작업이 실패했습니다. (Bug #28341514)

• InnoDB: ALTER TABLE... EXCHANGE PARTITION은 서로 다른 가상 컬럼 정의를 가진 파티션이 교환되도록 허용했으며, 이로 인해 나중에 InnoDB가 존재하지 않는 가상 컬럼에서 읽으려고 시도할 때 어설션이 발생했습니다. (Bug #28235668)

• InnoDB: 트랜잭션 커밋 중 발생하는 redo log 쓰기 및 flush 요청을 위한 카운터가 추가되었습니다. 이 카운터는 log writer 스레드가 연속된 요청 사이의 평균 시간을 계산하는 데 사용됩니다. 평균 시간이 100마이크로초보다 크면 log writer 스레드는 spin delay를 사용하지 않고, 대신 10마이크로초 timeout 제한으로 요청 이벤트를 대기합니다.

  hang을 일으킬 수 있었던 log writer 스레드 구현 문제도 수정되었습니다. (Bug #28062382, Bug #28444247, Bug #28616442, Bug #90890)

• InnoDB: 완전히 초기화되지 않은 새로 추가된 undo tablespace에 rollback segment를 추가하려고 할 때 assertion이 발생했습니다. (Bug #27914054)

• InnoDB: RENAME TABLE 작업 후 foreign key 제약 조건이 무시되었습니다. (Bug #27453180, Bug #89441)

• InnoDB: O_DIRECT_NO_FSYNC innodb_flush_method 설정을 사용하면 파일 시스템 메타데이터가 동기화되지 않아 시스템이 hang될 수 있었습니다. 이 문제가 O_DIRECT_NO_FSYNC 모드에서 발생하는 것을 방지하기 위해, 이제 InnoDB는 새 파일을 생성한 후, 파일 크기를 증가시킨 후, 파일을 닫은 후에 fsync()를 호출합니다. fsync() 시스템 호출은 각 쓰기 작업 후에는 여전히 건너뜁니다. (Bug #27309336)

• InnoDB: 빈 문자열로 CREATE TABLE 또는 ALTER TABLE ENCRYPTION 옵션을 지정해도 오류가 발생하지 않았으며, 기본 설정인 ENCRYPTION='N'으로 해석되었습니다. 이제 빈 문자열을 지정하면 유효하지 않은 것으로 처리되며 오류가 발생합니다. (Bug #27177845)

• InnoDB: Windows의 MySQL 인스턴스에서 lower_case_table_names 변수가 활성화된 Linux의 MySQL 인스턴스로 테이블스페이스 데이터 파일을 이동할 때, 파티셔닝된 테이블 이름 구분자(파티셔닝된 테이블 이름의 #P# 또는 #SP# 부분)가 소문자로 변환되지 않았습니다. 이름이 완전히 소문자로 변환되지 않아 테이블을 변경하거나, 이름을 변경하거나, 최적화하려고 할 때 “‘InnoDB error’ from storage engine”과 같은 오류가 발생했습니다. (Bug #26925260)

• InnoDB: 64비트 Windows 시스템에서 크기가 4GB보다 큰 테이블스페이스 파일에 쓰려고 할 때 assertion이 발생했습니다. 이 실패는 narrowing cast로 인해 발생했습니다. (Bug #26636815, Bug #87423)

• InnoDB: 지원되지 않는 작업인, 파티셔닝된 테이블을 참조하는 외래 키 제약 조건이 있는 테이블 생성을 시도한 후, SHOW ENGINE INNODB STATUS 출력이 참조된 테이블 이름을 확인할 수 없다는 외래 키 오류를 잘못 보고했습니다. 이 오류는 더 이상 나타나지 않으며, 이제 클라이언트에 반환되는 오류 메시지는 파티셔닝과 함께 외래 키가 아직 지원되지 않는다고 명시합니다. (Bug #25319071, Bug #84331)

• InnoDB: 파티셔닝된 테이블을 참조하는 외래 키 생성 및 외래 키를 지원하지 않는 스토리지 엔진을 사용하는 테이블 참조를 포함하여, 지원되지 않는 외래 키 작업에 대해 오해의 소지가 있는 오류 메시지가 보고되었습니다. 이제 오류 메시지가 더 많은 정보를 제공합니다. (Bug #11747571, Bug #33027)

• Partitioning: 삭제된 테이블스페이스에서 즉시 컬럼 추가를 수행하려고 하면 assert가 발생했습니다. 이제 이러한 경우 오류가 반환됩니다. (Bug #28517843)

• Partitioning: BLOB 또는 TEXT 컬럼을 포함하는 파티셔닝된 테이블에 대해 반복된 ALTER TABLE 문이 항상 올바르게 처리되지는 않았습니다. (Bug #28491099)

• 파티셔닝: 파티셔닝된 테이블에 DATA DIRECTORY 옵션을 사용하는 파티션 정의가 하나 이상 있는 경우 ALTER TABLE... EXCHANGE PARTITION이 작동하지 않았습니다. 이 수정은 InnoDB 스토리지 엔진을 사용하는 파티셔닝된 테이블만 지원합니다. (Bug #19730200)

• Replication: group_replication_exit_state_action 값에 따라 그룹을 나가는 멤버의 동작이 일관되지 않았습니다. 오류 시나리오와 관계없이 그룹을 나가는 멤버의 동작을 조화시키기 위해, 이제 group_replication_exit_state_action=READ_ONLY인 멤버가 의도치 않게 그룹을 나가면 해당 멤버가 시작될 때 가지고 있던 super_read_only 모드가 복원됩니다. 이렇게 하면 동작이 group_replication_exit_state_action=ABORT_SERVER인 멤버의 동작과 일관됩니다. (Bug #28971639, Bug #28526591)

• Replication: CREATE TABLE 문에 대해 바이너리 로그에 기록되는 메타데이터에는 테이블의 문자 컬럼에 대한 캐릭터셋 정보가 포함됩니다. 이전에는 mysqlbinlog 옵션 --print-table-metadata가 지정된 경우, 테이블에 대한 기본 캐릭터셋이 출력되었습니다. 이 기본 캐릭터셋은 테이블 컬럼에서 가장 자주 나타난 캐릭터셋이었으며, 테이블에 지정되었던 기본 캐릭터셋과 일치하지 않을 수 있었습니다. 이제 mysqlbinlog는 각 컬럼의 캐릭터셋을 개별적으로 출력합니다. 또한 컬럼은 별도의 라인에 출력됩니다. (Bug #28774144)

• Replication: ENUM 및 SET 컬럼에 대한 테이블 메타데이터의 일부로 캐릭터셋 정보가 바이너리 로그에 기록되지 않았습니다. 이 정보는 이제 확장 메타데이터를 생성하는 binlog_row_metadata=FULL이 설정된 경우 추가됩니다. (캐릭터 컬럼의 경우 캐릭터셋 정보는 binlog_row_metadata=MINIMAL에서도 추가됩니다.) (Bug #28706307)

• Replication: 바이너리 로그의 ROLLBACK TO SAVEPOINT 문에서 식별자에 대한 따옴표 처리를 수정하기 위한 패치가 이후 MySQL 버전에 올바르게 적용되지 않았습니다. (Bug #28569645)

• Replication: MySQL 5.7.23의 패치 이후, LOAD DATA 문이 MySQL 5.7.22 마스터에서 이후 릴리스의 복제 슬레이브로 수행되는 statement-based 복제를 중단시켰습니다. 이 문제는 이제 수정되었습니다. (Bug #28541204, Bug #92132)

• Replication: 일부 상황에서는 마스터 정보 로그가 테이블(master_info_repository=TABLE)에서 파일(master_info_repository=FILE)로 변경된 경우, 복제 슬레이브에서 CHANGE MASTER TO 문을 사용할 수 없었습니다. (Bug #28529558)

• Replication: mysqlbinlog가 DML SQL 문과 관련된 이벤트에 대해 sql_require_primary_key 시스템 변수(MySQL 8.0.13에서 도입됨)를 ON으로 설정하는 문을 잘못 추가했습니다. 시스템 변수가 ON으로 설정될 때 수행되는 검사는 새 테이블을 생성하거나 기존 테이블의 구조를 변경하는 DDL SQL 문에만 관련됩니다. (Bug #28524803)

• Replication: 시스템 변수 binlog_transaction_dependency_tracking 및 binlog_transaction_dependency_history_size가 설정되거나 읽힐 때, 필요한 잠금 유형으로 인해 데드락 시나리오가 발생할 수 있었습니다. 이는 동일한 잠금이 활성 바이너리 로그 작업에도 필요했기 때문입니다. 이제 트랜잭션 의존성 추적 시스템 변수에 접근하기 위해 대신 새 잠금 유형이 사용되므로, 이 데드락은 발생할 수 없습니다. (Bug #28511326, Bug #91941, Bug #28537209, Bug #92108)

• Replication: 다음 트랜잭션의 GTID 값이 아직 결정되지 않은 경우(gtid_next=NOT_YET_DETERMINED) 암시적 커밋이 시도되면 디버그 빌드에서 assertion이 발생했습니다. gtid_next 시스템 변수는 mysqlbinlog가 형식 설명 이벤트를 실행하기 위해 내부용 명령문 BINLOG를 실행한 직후 이 값을 가집니다. 암시적 커밋이 있는 명령문(예: CREATE TABLE 명령문)이 다음에 시도되면, gtid_next 설정이 AUTOMATIC 상태로 전환되지 않았으며, 허용할 수 없는 상태로 남아 있었습니다. autocommit이 켜져 있으면, 해당 명령문이 시도될 때 오류 ER_CANT_SET_GTID_NEXT_TO_ANONYMOUS_WHEN_GTID_MODE_IS_ON도 로그에 기록되었습니다.

  이 문제를 해결하기 위해, 이제 BINLOG 명령문 사용이 gtid_next의 상태를 변경하는 경우 트랜잭션 중에는 방지됩니다. 이를 시도하면 오류 ER_VARIABLE_NOT_SETTABLE_IN_TRANSACTION이 반환됩니다. 또한 GTID가 사용 중이고 gtid_next 값이 NOT_YET_DETERMINED인 경우, 다음 명령문은 gtid_next를 유효한 값으로 명시적으로 설정하거나 GTID 상태에 영향을 주지 않아야 합니다. 그렇지 않으면 오류 ER_CANT_SET_GTID_NEXT_TO_ANONYMOUS_WHEN_GTID_MODE_IS_ON이 반환됩니다. (Bug #28490793, Bug #91980)

• Replication: PURGE BINARY LOGS TO 'log_name' 문은 mysqlbinlogmove를 사용해 다른 위치로 이동된 바이너리 로그 파일에 대해 실패했습니다. 이러한 파일은 여전히 바이너리 로그 인덱스 파일에 나열되지만, 바이너리 로그 파일이 일반적으로 저장되는 디렉터리를 기준으로 한 상대 경로가 아니라 절대 경로를 사용해 나열됩니다. 이제 MySQL Server는 이동된 바이너리 로그 파일을 성공적으로 찾고 제거할 수 있습니다. (Bug #28284624)

• Replication: binlog_format이 MIXED로 설정된 경우, 함수에 임시 테이블에 적용되는 DML 문과 DROP TEMPORARY TABLE 문이 함께 포함되어 있으면, 함수 호출이 바이너리 로그에 기록되지 않아 복제 오류가 발생했습니다. 이제 함수에 임시 테이블에서 동작하는 DML 문이 포함되어 있으면, 혼합 복제 모드에서 함수 호출이 바이너리 로그에 기록됩니다. (Bug #28258992)

• Replication: GTID가 사용 중이고 super_read_only=ON이 설정된 복제 슬레이브 또는 Group Replication 그룹 멤버에 대해 autocommit이 0으로 설정된 경우, 완료되지 않은 트랜잭션으로 인해 서버 종료가 방지되었습니다. 해당 트랜잭션은 GTID를 mysql.gtid_executed 테이블에 저장하려고 시도했지만, super_read_only=ON이 설정되어 있었기 때문에 업데이트가 실패했습니다. (autocommit이 1로 설정된 경우에는 이 상황에서 트랜잭션이 완료되며, 대신 서버 시작 시 mysql.gtid_executed 테이블이 업데이트됩니다.) 이제 이 작업에 대해서는 super_read_only 설정에 대한 검사가 건너뛰어지므로, super_read_only 및 autocommit 설정의 조합과 관계없이 트랜잭션이 GTID를 mysql.gtid_executed 테이블에 저장하고 완료될 수 있습니다. (Bug #28183718)

• Replication: gtid_next 값이 수동으로 설정된 상태에서 알 수 없는 트랜잭션 식별자에 대해 XA ROLLBACK 문이 실행되면 디버그 빌드에서 assertion이 발생했습니다. 이제 서버는 XA ROLLBACK 문이 오류와 함께 실패하는 경우 GTID 상태를 업데이트하려고 시도하지 않습니다. (Bug #27928837, Bug #90640)

• Replication: 트랜잭션이 커밋되거나 롤백된 직후 SELECT... FOR UPDATE 문이 실행되고, 해당 트랜잭션에 gtid_next 세션 시스템 변수를 사용하여 수동으로 GTID가 할당된 경우 debug 빌드에서 assertion이 발생했습니다. gtid_next가 트랜잭션에 GTID를 설정하는 데 사용되고 해당 트랜잭션이 커밋되거나 롤백된 후에는, 다른 어떤 문보다 먼저 명시적인 SET GTID_NEXT 문을 다시 실행해야 하며, 그렇지 않으면 gtid_next 값이 정의되지 않은 상태로 남습니다. SELECT... FOR UPDATE 문은 변경을 수행하지 않았음에도 쓰기 잠금을 획득했기 때문에, 이 상황에서 GTID 일관성 위반을 유발했습니다. 이제 쓰기 잠금을 획득하는 SELECT... FOR UPDATE 문은 이 상황에서 오류를 반환합니다. (Bug #27903848, Bug #90547)

• Replication: 부하가 큰 상황에서 바이너리 로그 그룹 커밋의 race condition으로 인해 서버가 예기치 않게 중지될 수 있었습니다. 이러한 상황을 방지하기 위해 트랜잭션 커밋 추적이 변경되었습니다. (Bug #27556117)

• Replication: SHOW SLAVE STATUS 문이 기존의 모든 릴레이 로그 파일의 전체 합산 크기(Relay_Log_Space)에 대해 반환하는 값이 릴레이 로그 파일이 실제로 사용하는 디스크 공간보다 훨씬 커질 수 있었습니다. I/O 스레드는 값을 업데이트하는 동안 변수를 잠그지 않았으므로, SQL 스레드가 릴레이 로그 파일을 자동으로 삭제하고 I/O 스레드가 값 업데이트를 완료하기 전에 감소된 값을 쓸 수 있었습니다. 그런 다음 I/O 스레드는 SQL 스레드의 업데이트를 무시하고 원래의 크기 계산값을 썼으며, 이로 인해 삭제된 파일의 공간이 다시 더해졌습니다. 이제 동시 업데이트를 방지하고 정확한 계산을 보장하기 위해 업데이트 중에 Relay_Log_Space 값이 잠깁니다. (Bug #26997096, Bug #87832)

• Replication: 복제 슬레이브의 백업 프로세스가 보기 목적으로 릴레이 로그 인덱스 파일을 일시적으로 잠갔고, MySQL Server도 동시에 rename 또는 delete 작업을 위해 해당 파일에 액세스하려고 시도한 경우, 백업은 경고와 함께 완료되었지만 MySQL Server가 예기치 않게 중지되었습니다. 이제 MySQL Server는 이 경우 또는 유사한 시나리오가 원인이며 곧 파일을 다시 사용할 수 있게 되는 상황에 대비하여 파일 액세스 작업을 여러 번 재시도합니다. (Bug #25839610)

• Replication: sync_binlog=1이 설정된 상태에서 바이너리 로그 끝 위치가 업데이트되기 전에 커밋 중 바이너리 로그가 순환되면, 서버가 새 바이너리 로그 파일에 이전 바이너리 로그 끝 위치를 사용하려고 했기 때문에 슬레이브에서 복제가 중지되었습니다. 이제 서버는 바이너리 로그 끝 위치를 업데이트할 때 바이너리 로그 파일 이름을 활성 바이너리 로그 파일과 비교하므로, 이 문제가 발생하지 않습니다. (Bug #22252394, Bug #25524203, Bug #84752)

• Replication: 그룹에 새 멤버를 추가할 때 인증 정보가 전송하기에 너무 크면, 모든 그룹 멤버에서 실패를 발생시키는 이벤트가 생성되었습니다. 이 상황을 피하기 위해 이제 인증 정보가 너무 크면 오류가 생성되며, 이 오류로 인해 조인하는 멤버가 그룹을 떠나게 됩니다. (Bug #93130, Bug #91870, Bug #28900691, Bug #28443958)

• Replication: group_replication_switch_to_single_primary_mode()를 사용했을 때, 비동기 채널도 가지고 있던 멤버에서 오류가 발생하면 비동기 복제 채널이 올바르게 중지되지 않았으며, 서버가 예기치 않게 중지될 수 있었습니다. (Bug #91747, Bug #28382590)

• Replication: group_replication_switch_to_single_primary_mode와 같이 그룹을 설정하는 그룹 코디네이터 기반 함수를 멤버가 UNREACHABLE 또는 RECOVERING 상태일 때 사용할 수 있었으며, 이로 인해 작업이 모든 멤버가 ONLINE이 될 때까지 대기했습니다. 이로 인해 그룹 코디네이터 작업이 성공적으로 완료되지 못할 수 있었습니다. 이제 이 상태의 그룹에서 이러한 함수 중 하나를 호출하면 오류가 반환됩니다. 함수를 사용하여 그룹을 설정하려고 시도하기 전에 모든 멤버가 ONLINE인지 확인하십시오. (Bug #91537, Bug #28284355)

• Replication: 지속적인 최대 부하가 있는 그룹에 멤버가 참여했을 때, 해당 멤버가 RECOVERING 상태에서 ONLINE 상태로 이동하지 못할 수 있었습니다. 원인은 다음과 같았습니다:

• 멤버가 복구 중에 도착한 트랜잭션의 전체 큐가 적용되기를 루프에서 기다리는 동안, 새 트랜잭션이 계속 도착하고 있었습니다.

  • 전체 큐가 적용된 경우에도, 멤버는 applier가 일시 중지되었는지도 확인하고 있었으며, 이는 지속적인 피크 워크로드에서는 발생할 가능성이 낮습니다.

  이제 복구 완료 정책이 트랜잭션 적용을 기다릴 때, 멤버는 먼저 다음 조건 중 하나가 충족될 때까지 기다립니다:

  • 적용할 트랜잭션이 흐름 제어 설정 내에 들어맞습니다. 즉, 적용할 트랜잭션은 다음 흐름 제어 반복 중에 적용될 수 있습니다;
  • 비어 있는 복구 큐의 경우, 큐에 추가되거나 적용 중인 트랜잭션이 없습니다.

  그런 다음 멤버 상태가 ONLINE으로 변경되기 전에, 멤버는 group_replication_applier 채널에서 현재 큐에 들어 있는 트랜잭션이 적용되기를 기다립니다. (Bug #89582, Bug #27511404)

• Group Replication: 의심되는 Group Replication 그룹 멤버를 축출하기 전 대기 기간에 대한 최대 타임아웃 설정이 3600초(1시간)로 줄었습니다. 이전에는 group_replication_member_expel_timeout 시스템 변수를 최대 31536000초까지의 값으로 설정할 수 있었습니다. 새 상한은 비활성 멤버를 그룹에서 제거하기 위한 더 합리적인 최대값을 제공합니다. 이 타임아웃의 기본 설정은 0이며, 이는 5초 감지 기간이 끝난 직후 비활성 멤버가 축출 대상이 됨을 의미합니다. 더 느린 네트워크에서 불필요한 축출을 피하거나, 예상되는 일시적인 네트워크 장애 또는 시스템 속도 저하가 있는 경우 타임아웃 값을 지정하는 것이 유용합니다. (Bug #28656750)

• Group Replication: Group Communication System (GCS)이 네트워크 이름 확인에 systemd-resolved 서비스를 사용하는 시스템에서, 호스트 이름을 확인할 수 없는 경우 GCS는 무기한 계속 시도했습니다. 이제 이름 확인 서비스에서 재시도 메시지가 반환되면 GCS는 제한된 횟수만큼 재시도한 다음, 해당 호스트 이름을 확인할 수 없다고 결론을 내립니다. (Bug #28177861)

• Group Replication: 그룹이 온라인으로 재구성되고 있을 때, 예를 들어 group_replication_switch_to_multi_primary_mode 또는 group_replication_set_as_primary를 사용하는 경우, 멤버를 중지하면 예기치 않은 중지가 발생할 가능성이 있었습니다. 이제 STOP GROUP_REPLICATION을 실행할 때, 해당 멤버가 재구성 중인 온라인 그룹의 일부이면 그룹 코디네이터에 Group Replication이 중지 중임이 통보됩니다. 멤버는 온라인 설정 프로세스가 진행 중인 작업을 완료할 때까지 기다리지만, 이후의 작업은 모두 취소됩니다. (Bug #92829, Bug #28807260)

• Group Replication: 그룹 복제를 중지할 때, 대기 중인 트랜잭션이 있는 채널은 교착 상태를 일으킬 수 있었습니다. (Bug #92376, Bug #28636768, Bug #28365855)

• Group Replication: group_replication_exit_state_action이 ABORT_SERVER로 설정된 경우, Group Replication 플러그인은 이제 MySQL을 종료하기 위해 WL#12003에서 추가된 새 컴포넌트 서비스를 사용합니다. (Bug #91793, Bug #28401703)

• Microsoft Windows: 기존 MySQL 서비스를 제거하지 못한 후 MySQL Installer가 실패할 수 있었습니다. 이제 이는 설치 작업을 계속할 수 있도록 치명적이지 않은 것으로 처리되지만, 서비스 정리를 허용하려면 시스템 재시작이 필요할 수 있습니다. (Bug #29016677, Bug #93048)

• Microsoft Windows: 동일한 호스트에서 동일한 사용자에 대해 --no-monitor 옵션으로 여러 mysqld 인스턴스가 시작된 경우, SHUTDOWN 명령이 잘못된 서버 프로세스를 종료했습니다. 이 수정은 프로세스의 프로세스 ID를 추가하여 --no-monitor와 함께 사용할 고유한 종료 이벤트 이름을 생성합니다. (Bug #28723675)

• X DevAPI: X Protocol을 사용할 때 사용자 변수가 OUT 매개변수로 지정되어 호출된 저장 프로시저가 변수의 값을 설정하지 않았습니다. (Bug #91907, Bug #28458752)

• JSON: JSON 객체에 대한 반복 처리에서 불필요한 문자열 할당이 발생했습니다. (Bug #28975640)

• JSON: JSON 값을 텍스트로 변환할 때 대상 문자열이 선형으로 증가하여 불필요하게 많은 재할당이 발생했습니다. 이제 이 프로세스는 필요한 할당 수를 줄이기 위해 대신 지수 증가를 사용합니다. (Bug #28949700)

  References: 함께 참조하십시오: Bug #103790, Bug #32919524.

• JSON: YEAR 값이 JSON에서 불투명 데이터로 저장되었습니다. YEAR 값을 포함하는 JSON 문서가 텍스트로 변환될 때 YEAR 값은 base64로 인코딩된 문자열로 표시되었습니다. 이 문제를 해결하기 위해 이제 YEAR 값은 부호 없는 정수로 저장되며, 텍스트로 변환될 때 숫자로 표시됩니다. 이 수정의 추가 이점은 JSON 문서 내 YEAR 값에 필요한 저장 공간이 이제 더 적어진다는 점입니다. (Bug #28947107)

• JSON: JSON 컬럼을 포함하는 ARCHIVE 테이블에서 UPDATE 또는 DELETE를 실행하려고 할 때 assert에 도달했습니다. (Bug #28923281)

• JSON: FEDERATED 테이블의 JSON 컬럼에서 선택하려고 할 때, 서버가 ER_INVALID_JSON_PATH_CHARSET Cannot create a JSON value from a string with CHARACTER SET 'binary'를 반환했습니다.

  또한 JSON 컬럼을 포함하는 FEDERATED 테이블에 대해 DELETE 또는 UPDATE 중 어느 것도 영향을 주지 않았습니다. (Bug #28877215)

• JSON: SELECT jt.* FROM t1, JSON_TABLE(t1.c, '$[*]' COLUMNS (num INT PATH '$[0]')) AS jt 형식의 쿼리는 해당 쿼리를 실행하는 사용자에게 컬럼 c에 대한 SELECT 권한이 있었음에도 권한 오류로 인해 실패했습니다. (Bug #23254268)

• Bug#27855592로 구현된 기능을 위해 Facebook에서 제공한 코드가 업데이트되었습니다. (Bug #28950397)

  참조: 다음도 참조하십시오: Bug #27855592.

• SuSE Linux에서 pthread_mutex_destroy()의 잘못된 EBUSY 반환 값이 처리되지 않았습니다. (Bug #28948462)

• mysqld_safe 및 mysqld_multi가 클라이언트 전용 패키지에 잘못 포함되었습니다. (Bug #28942508)

• 호스트 캐시 잠금 처리가 잘못되어 서버가 종료될 수 있었습니다. (Bug #28936159)

• audit_log 플러그인이 설치된 경우 MySQL Enterprise Firewall이 제대로 작동하지 않았습니다. (Bug #28930885, Bug #93184)

• Windows의 Visual Studio에서 성공적으로 빌드할 수 있도록 수정되었습니다. (Bug #28892711, Bug #93077)

• 서버가 redo log 파일과 동일한 이름의 데이터베이스 생성을 허용했으며, 이로 인해 예기치 않은 서버 동작이 발생할 수 있었습니다. 이러한 이름은 더 이상 데이터베이스 이름으로 허용되지 않습니다. (Bug #28867993)

• mysqld_multi가 올바른 datadir 값을 mysqld에 전달하지 못할 수 있었습니다. (Bug #28866662, Bug #90801)

• 루틴, 이벤트 및 트리거에 대한 MDL 키 생성 중 파라미터 스키마 이름을 검사하여 이름이 소문자인지 확인하는 디버그 assertion이 멀티바이트 문자를 포함한 스키마 이름을 만났을 때 실패했습니다. (Bug #28864244)

• 일부 오류 메시지의 형식 지정자가 잘못된 숫자 값을 표시하지 않도록 개선되었습니다. (Bug #28860795)

• Windows의 디버그 빌드에서 사용되지 않는 메모리 누수 검사가 활성화되어 종료 프로세스가 느려질 수 있었습니다. 이제 이러한 검사는 특수 빌드에서만 활성화됩니다. (Bug #28857626)

• sql_require_primary_key 시스템 변수가 활성화된 경우 mysql_upgrade가 특정 시스템 테이블을 업그레이드하지 못할 수 있었습니다. (Bug #28855207, Bug #92988)

• -DWITH_LIBWRAP=ON으로 설정된 빌드가 컴파일되지 않았습니다. (Bug #28853650, Bug #92983)

• InnoDB 테이블의 경우, 이 함수에서 참조되는 컬럼의 기본값이 컬럼을 nullable로 만들어 변경되면, DEFAULT() 함수에 의존하는 저장된 또는 인덱싱된 가상 생성 컬럼의 값이 ALTER TABLE에 의해 올바르게 업데이트되지 않았습니다. (Bug #28848265)

• Windows의 Visual Studio에서 /permissive 플래그가 켜진 상태로 성공적인 빌드를 가능하게 하기 위해 수정되었습니다. (Bug #28842878, Bug #92943)

• -DCMAKE_BUILD_TYPE=Release로 설정된 빌드가 컴파일되지 않았습니다. (Bug #28841366, Bug #92945)

• 이제 다음 조건이 적용되는 경우 ALTER TABLE이 INPLACE 알고리즘을 사용할 수 있습니다:

  • InnoDB 테이블의 경우, 생성 저장 컬럼을 수정하지만 해당 컬럼의 타입, 표현식 또는 null 허용 여부를 변경하지 않는 구문입니다.
  • 비-InnoDB 테이블의 경우, 생성 저장 컬럼 또는 가상 컬럼을 수정하지만 해당 컬럼의 타입, 표현식 또는 null 허용 여부를 변경하지 않는 구문입니다.

  이러한 변경의 예로는 컬럼 주석 변경이 있습니다. (Bug #28836543)

• 지속 저장되었던 플러그인 시스템 변수가 플러그인이 다시 설치될 때 적용되지 않았습니다. (Bug #28823972)

• EXPLAIN... FOR CONNECTION이 다른 연결의 SQL 모드를 수정할 수 있었습니다. (Bug #28786981)

• Sun RPC 및 XDR이 glibc에서 별도의 libtirpc 라이브러리로 제거되면서 일부 플랫폼에서 libasan과 관련된 문제가 발생했습니다. (Bug #28785835, Bug #92762, Bug #28897799, Bug #93116)

• SELECT a FROM table WHERE b = value 형식의 쿼리를 처리하는 동안 두 ENUM 값을 비교하고 컬럼 b에 인덱스가 있는 경우 assert에 도달할 수 있었습니다. (Bug #28769996)

• offline_mode 시스템 변수에 대한 동시 읽기 및 쓰기 접근으로 인해 데드락이 발생할 수 있었습니다. (Bug #28761869)

• MySQL 5.7에서 MySQL 8.0으로 업그레이드할 때 트리거가 잘못된 순서로 메모리에 로드되어 assertion failure가 발생했습니다. (Bug #28760011, Bug #92609)

• Performance Schema data_locks 테이블과 관련된 조인은 잘못된 결과를 생성할 수 있었습니다. (Bug #28733170)

• 스칼라 서브쿼리 사용이 포함된 일부 다중 중첩 서브쿼리가 올바르게 처리되지 않았습니다. (Bug #28723670)

• Ubuntu에서 설치된 /etc/mysql/mysql.conf.d/default-auth-override.cnf 파일이 실수로 실행 가능 모드로 생성되었습니다. 수정 기여를 해 주신 Evgeniy Patlan에게 감사드립니다. (Bug #28714840, Bug #92587)

• 동일한 사용자 수준 잠금을 보유한 동시 연결로 인해 실패한, 타임아웃이 0인 GET_LOCK() 호출로 인해 메모리 누수가 발생했습니다. (Bug #28714367)

• 많은 수의 테이블을 호스팅하는 서버가 반복적으로 시작되고 중지될 때 힙 손상 및 서버 종료가 발생할 수 있었습니다. (Bug #28705511, Bug #92572)

• MySQL Router가 MySQL Server MSI 패키지에서 누락되었습니다. (Bug #28685556)

• 예제 저장 함수 GTID_SUBTRACT_UUID가 문서화된 버전과 일치하도록 코드에서 수정되었습니다. (Bug #28670170)

• Linux용 MySQL 패키지 설치 프로그램에서 mysqld에 대해 더 이상 CAP_SYS_NICE 기능을 활성화하지 않습니다. (이는 리소스 그룹 스레드 우선순위 사용을 용이하게 하기 위해 수행되었습니다.) 스레드 우선순위에 대한 액세스가 필요한 Linux 배포에서는 Resource Group Restrictions의 CAP_SYS_NICE 기능 활성화에 관한 MySQL Reference Manual 지침을 참조하십시오. (Bug #28670160)

• <=> 연산자의 내부 구현이 단순화되었습니다. (Bug #28660232)

• STOP GROUP_REPLICATION 문을 실행하여 그룹에서 서버 인스턴스를 제거한 후, "[GCS] Error pushing message into group communication engine" 오류 메시지의 여러 인스턴스가 해당 서버 인스턴스에 기록되었습니다. 이제 서버가 그룹을 떠나는 중이거나 더 이상 그룹의 멤버가 아닌 경우 이 오류는 무시됩니다. (Bug #28658228, Bug #92454)

• JSON_TABLE(... COLUMNS...)에서 어떤 컬럼의 CHARACTER SET 속성이 암시적이면, 결과 컬럼은 전역 character_set_results를 기본 캐릭터셋으로 사용했습니다. 이제 이 컬럼은 세션 character_set_connection 및 collation_connection 값을 사용합니다. (Bug #28643862)

• 로우 값을 생성하는 표현식에 함수형 인덱스를 추가하면 어설션이 발생했지만, 이제는 대신 오류가 발생합니다. (Bug #28643252)

• 디버그 빌드에서 sql-mode를 TIME_TRUNCATE_FRACTIONAL로 설정한 후 트리거를 생성하면 assertion failure가 발생했습니다. 이 SQL 모드는 mysql.triggers 데이터 딕셔너리 테이블의 sql_mode 컬럼에 존재하지 않았습니다. (Bug #28642918)

• --log-timestamps=SYSTEM을 사용할 때 로그 메시지의 ISO 8601 타임스탬프가 일광 절약 시간을 고려하지 않았습니다. (Bug #28632725, Bug #32893161)

• 오류 ER_IB_MSG_720의 인수가 잘못 계산되었습니다. (Bug #28629175)

• 소켓 파일을 지정하는 옵션이 올바르게 지정되지 않은 경우 서버가 시작 시 종료될 수 있었습니다. (Bug #28609181)

• 자식 테이블과 다른 스토리지 엔진을 사용하는 부모 테이블을 추가한 다음, 부모 테이블을 자식 테이블과 같은 스토리지 엔진으로 변경하여 일관성이 없는 외래 키를 생성할 수 있었습니다. (Bug #28608460, Bug #92317)

• 서버가 복제 그룹에 조인할 때, 해당 서버는 group_replication_group_seeds 시스템 변수에 나열된 첫 번째 시드 멤버에 연결을 시도합니다. 연결이 거부되면, 조인하는 멤버는 목록에 있는 다른 각 시드 멤버에 순서대로 연결을 시도합니다. 이전에는 조인하는 멤버가 시드 멤버에 연결되었지만 그 결과 복제 그룹에 추가되지 않은 경우, 조인하는 멤버는 더 이상 연결을 시도하지 않았습니다. 이러한 상황은 연결이 이루어진 후 시드 멤버에 장애가 발생했거나, 시드 멤버가 whitelist에 조인하는 멤버의 주소를 가지고 있지 않아 연결을 닫았거나, 시드 멤버가 그룹 조인 요청을 거부한 경우 발생할 수 있었습니다. 이제 조인하는 멤버가 시드 멤버에 연결되었지만 그룹에 조인하지 못하면, 조인하는 멤버는 목록에 남아 있는 시드 멤버를 순서대로 계속 시도합니다. (Bug #28602835)

• 특정한 할당 패턴, 할당자의 rebind를 수반하는 복사, 그리고 할당 해제가 주어지면, temptable::Allocator가 해제된 메모리 블록을 재사용할 수 있었습니다. 이로 인해 Windows 플랫폼에서 테스트 스위트에 실패가 발생했습니다. (Bug #28595557)

• time_zone을 음수 오프셋으로 설정하고 timestamp를 낮은 값으로 설정하면 루틴과 뷰를 변경할 때 어설션이 트리거되었습니다. (Bug #28590623, Bug #92273)

• pid_file 시스템 변수를 DEFAULT로 영속화하면 이후 서버 시작 시 NULL 값이 될 수 있었습니다. (Bug #28589736)

• 잘못된 권한 검사로 인해 MySQL 5.7에서 성공적으로 실행되던 SELECT... FOR UPDATE 문에서 오류가 발생할 수 있었습니다. (Bug #28581664, Bug #92254)

• ALTER TABLE을 사용하여 외래 키의 부모 컬럼 이름을 변경하려고 하면 실패할 수 있었습니다. (Bug #28581468)

• RESET PERSIST에 대한 권한이 올바르게 검사되지 않았습니다. (Bug #28564239)

• AVG(YEAR(datetime_column))를 계산할 때 오버플로가 발생했습니다. (Bug #28562930)

• 서버 재시작 후 Performance Schema variables_info 테이블의 영속화된 시스템 변수 경로 이름이 잘못 계산될 수 있었습니다. (Bug #28561584)

• 파티션된 테이블 이름 검사에서 유효하지 않은 assertion이 발생했습니다. (Bug #28556942)

• handler::create() 함수가 조건 목록에 오류가 있는 상태로 호출될 수 있었으며, 이로 인해 handler::create() 함수의 오류가 제대로 보고되지 않을 수 있었습니다. (Bug #28556264)

• ALTER TABLE의 경우, MySQL 8.0.12 이전 버전에서 생성된 테이블에 대해 ALGORITHM=INSTANT가 잘못 거부되었습니다. (Bug #28554157, Bug #92194)

• mysqlpump는 오류가 발생했을 때 할당된 모든 리소스를 해제하지 않아 메모리 누수가 발생했습니다. (Bug #28538971, Bug #92131)

• JSON_TABLE() 함수의 COLUMNS 절에 있는 데이터 타입에 대해 COLLATE 속성이 거부되었습니다. (Bug #28538315)

• 디버그 빌드의 경우, 서버가 CREATE USER 문을 롤백하려고 시도할 때 종료될 수 있었습니다. (Bug #28536312)

• 부호 있는 값을 가진 플러그인 변수가 잘못 표시되었습니다. (Bug #28534414, Bug #92107)

• 더 이상 사용되지 않는 시스템 변수를 잘못 처리하면 Performance Schema variables_by_thread 테이블에 대한 쿼리의 출력이 올바르지 않을 수 있었습니다. (Bug #28515475, Bug #92049)

• Event_queue::lock_data 및 SAFE_MUTEX 구현에서 Thread Sanitizer가 발견한 데이터 레이스가 수정되었습니다. (Bug #28510721, Bug #92041, Bug #28510691, Bug #92040)

• 준비된 명령문에 대해 재준비가 실패했을 때 ER_NEED_REPREPARE 진단이 진단 영역에 푸시되지 않았습니다. (Bug #28509306, Bug #92029)

• 서브쿼리에 UNION이 포함된 경우, 서브쿼리 컬럼 수의 개수가 잘못 계산되었습니다. (Bug #28499924)

• WITH ROLLUP을 사용하여 표현식을 평가할 때, 이제 표현식에 임시 테이블 컬럼이 있는 경우에만 표현식의 결과를 임시 테이블에 기록합니다. (Bug #28493849, Bug #28523014)

• 디버그 빌드의 경우, TEMPORARY 테이블에 대한 ALTER TABLE의 잘못된 외래 키 오류 검사가 서버 종료를 초래할 수 있었습니다. (Bug #28493257, Bug #91990)

• 일부 시스템 변수의 경우 SET PERSIST가 지정된 값이 아니라 기본값을 지속했습니다. (Bug #28466045)

• SET RESOURCE GROUP을 prepared statement로 실행할 수 없었습니다. (Bug #28448258, Bug #91876)

• window function을 구현하기 위해 수행된 작업 중 실수로 제거된 Item_field::fix_fields() 호출을 복원했습니다. (Bug #28431783)

• X 플러그인 시작 및 종료 중 Thread Sanitizer가 보고한 데이터 레이스를 수정했습니다. (Bug #28407294)

• 잘못된 utf8 문자를 포함하는 파티션 설명으로 테이블을 생성하면 assertion이 발생했습니다. (Bug #28387488, Bug #91763)

• mysqldump 출력에 제거된 SQL 모드 값이 포함될 수 있었습니다. (Bug #28373001, Bug #91714)

• 잠재적인 잠금 순서 사이클을 수정했습니다. (Bug #28366531)

• GTID가 활성화된 서버에서 INFORMATION_SCHEMA.COLUMNS 테이블에 대한 동시 statement가 deadlock을 일으킬 수 있었습니다. (Bug #28293047, Bug #91548)

• utf32 테이블 캐릭터셋과 테이블 정의의 리터럴 문자열이 있는 테이블에 대한 CREATE TABLE statement가 assertion을 발생시켰습니다. (Bug #28275881)

• 서버 업그레이드가 성공적으로 완료되면 서버 버전 번호를 업데이트하는 것을 지원하기 위해 내부 함수가 추가되었습니다. (Bug #28211486, Bug #91323)

• memcmp() 함수를 사용하여 로그 파일 이름을 문자열로 비교하면 초기화되지 않은 메모리 읽기 오류가 발생했습니다. 이제 비교에는 strncmp() 함수를 사용합니다. 기여해 주신 Zsolt Parragi와 Laurynas Biveinis에게 감사드립니다. (Bug #28178776, Bug #90238)

• 서버가 악센트만 다른 저장 프로그램 및 리소스 그룹 이름을 잘못 처리했습니다. (Bug #28122841)

• Optimizer가 두 번째 컬럼에 대한 LIKE 절이 있는 내부 조인을 실행할 때 복합 인덱스의 두 번째 컬럼을 건너뛰었습니다. (Bug #28086754)

• CREATE TABLE... SELECT가 기본값 없이 생성해야 하는 경우에도 “zero” 날짜 기본값을 가진 날짜 컬럼을 생성할 수 있었습니다. (Bug #28022129)

• IN 서브쿼리 술어를 세미조인으로 변환하는 작업이 매우 많은 수의 테이블에 대해 올바르게 처리되지 않았습니다. (Bug #28004674)

• 윈도우 함수용으로 생성된 임시 테이블의 마지막에 추가되는 filesort를 수행할 때, 스토리지 엔진에서 필드를 읽는 데 사용되는 비트맵이 올바르게 활성화되지 않았습니다. 임시 테이블이 필요하지 않은 경우, 서버는 select 테이블의 출력에 filesort를 추가했지만, 제거된 참조(WHERE 조건)는 추가되지 않았습니다. 이제 이러한 경우에는 첫 번째 윈도우 함수에 정렬이 필요하고 이 윈도우 함수를 처리하기 전에 임시 테이블이 생성되지 않은 경우, 해당 참조가 select 테이블에 추가됩니다. (Bug #27975193)

• range 프레임에서 로우를 확인한 후, 나중에 다른 로우가 이 range 프레임보다 앞에 나타나는 것으로 확인되면 서버가 계속해서 새 로우를 확인했습니다. 이로 인해 다음 프레임 계산이 잘못 수행되었습니다. (Bug #27973860)

• 서버가 SIGHUP 시그널을 잘못 처리하면 서버가 종료될 수 있었습니다. (Bug #27966483, Bug #90742)

• 컬럼 a가 있고 생성 컬럼 b의 값으로 파티셔닝된 테이블에서 DELETE WHERE a=constant를 수행하면 디버그 빌드에서 어설션이 발생했습니다. (Bug #27954073)

• 동적 테이블 통계를 업데이트할 때 INFORMATION_SCHEMA 쿼리로 인해 서버가 종료될 수 있었습니다. (Bug #27898108)

• 외래 키 부모 테이블을 열 때 메타데이터 잠금 데드락이 발생할 수 있었습니다. (Bug #27859086)

• 계정 관리 명령문의 부적절한 메모리 처리로 인해 서버가 잘못 동작할 수 있었습니다. (Bug #27820277)

• 특정 경우에 윈도우 함수가 ORDER BY 및 PARTITION BY를 올바르게 처리하지 않았습니다. (Bug #27816506)

• MySQL 쿼리 Optimizer는 테이블로 푸시다운할 각 조건자를 테이블 조건으로 식별합니다. 이 프로세스의 일부로, 테이블 조건 중 주어진 조건자가 테이블에 대해 선택된 액세스 경로에 의해 이미 참인 것으로 알려져 있는지 확인하며, 이 경우 해당 조건자는 안전하게 제거될 수 있습니다.

  예를 들어, pk가 테이블 t1의 프라이머리 키인 SELECT * FROM t1 WHERE pk=1을 실행할 때는 ref 액세스 메서드가 선택됩니다. 이것이 이미 pk=1인 로우만 반환한다는 것을 알고 있으므로, 이 조건을 필터(Using where)로 추가 평가하는 것은 제거되어야 합니다.

  GROUP BY 또는 ORDER BY를 포함하는 쿼리를 최적화할 때, 정렬된 인덱스를 대신 사용하여 정렬을 건너뛸 수 있는지 발견하기 위해 늦은 단계의 Optimizer 검사가 수행됩니다. 이는 정렬할 테이블에 액세스하기 위해 다른 인덱스가 이미 선택되었을 수 있는 이후에 수행되므로, (이전에 선택된 액세스 경로로 인해) 중복된다고 판단된 일부 조건자가 너무 이르게 제거될 수 있었습니다. 이를 보완하기 위해 다음 조치가 수행되었습니다:

• 액세스 메서드가 이미 선택되었기 때문에 이전에 제거된 프레디케이트를 포함하는 테이블 조건의 재구성.

  • 정렬을 피할 수 있도록 하는 정렬된 인덱스가 존재하는지 확인하는 검사를 수행하며, 이 과정에서 액세스 계획을 수정할 수도 있습니다.

  초기 프레디케이트 제거를 해결하기 위한 다음 작업도 올바르게 수행되지 않았기 때문에 문제가 발생했습니다:

  • 액세스 계획이 수정되었는지 여부와 관계없이, 앞서 언급한 재구성된 테이블 조건에 다시 추가된 모든 추가 프레디케이트가 테이블 조건의 영구적인 일부가 되었습니다.
  • 액세스 계획이 다른 정렬된 인덱스를 사용하도록 변경되었을 때, 새 인덱스에 의해 더 이상 필요하지 않게 된 프레디케이트를 제거하기 위한 분석이 새 인덱스에 대해 수행되지 않았습니다.

  NDBCLUSTER와 같이 조건 푸시다운을 구현하는 스토리지 엔진에는 추가 문제가 있었습니다: 푸시다운된 조건은 분석 전에 테이블 조건에서 생성되었으므로, 액세스 경로가 나중에 변경된 경우 푸시다운된 조건에 이미 제거된 프레디케이트가 포함되지 않아 조건 푸시다운의 효율이 낮아졌습니다.

  이 문제의 근본 원인은 테이블에 대한 액세스 메서드가 완전히 결정되기 전에 테이블 프레디케이트에 대해 part_of_refkey() 분석이 수행되었다는 점이었습니다. 이러한 초기 분석을 제거하여 이 문제가 수정되었습니다. (Bug #27808758, Bug #27814026)

• ORDER BY column 절을 포함하는 윈도우 함수가 쿼리되는 테이블에서 컬럼을 찾은 경우에도 Unknown field in window order by와 함께 실패했습니다. (Bug #27808099)

• 많은 수의 자리 표시자를 사용하여 여러 로우 삽입을 수행하는 prepared statement를 실행하면 과도한 메모리를 소비하고 느리게 실행될 수 있었습니다. (Bug #27703912)

• Windows에서 Visual Studio용 Visual C++ Redistributable이 제거된 경우, MSI installer를 사용한 MySQL 제거가 실패했습니다. (Bug #27621546)

• 파서가 트리거 정의에서 서버 종료를 초래할 수 있는 잘못된 SET 문 구문을 허용했습니다. (Bug #27595603)

• keyring_encrypted_file 플러그인 keyring 파일이 유효하지 않은 경우 서버가 시작되지 않았습니다. (Bug #27588064)

• 소스 및 대상 keyring 플러그인이 각각 keyring_okv 및 keyring_encrypted_file인 경우 Keyring 마이그레이션이 실패했습니다. (Bug #27493970)

• 디버그 빌드에서 signed integer를 사용하는 윈도우 함수가 FOLLOWING을 포함하는 프레임을 잘못 처리할 수 있었습니다. (Bug #27452365)

• CURSOR_TYPE_READ_ONLY 플래그가 설정된 procedure call이 포함된 prepared statement를 실행할 때, 프로시저가 빈 결과 집합을 반환하는 SELECT를 수행하면 클라이언트 라이브러리가 중단되었습니다. (Bug #27443252, Bug #89214)

• 외래 키가 참조하는 컬럼의 이름이 SHOW CREATE TABLE 출력 및 INFORMATION_SCHEMA.KEY_COLUMN_USAGE 테이블에서 항상 소문자로 표시되었습니다. (Bug #27353767, Bug #88718)

• 다른 동시 작업을 수행하는 동안 audit_log 플러그인을 로드 및 언로드하면 서버가 응답하지 않게 될 수 있었습니다. (Bug #27325622)

• 데이터 딕셔너리 속성 인터페이스(dd::Properties) 및 구현이 속성 객체에 유효한 키를 정의하는 새로운 방법을 제공하도록 개정되었습니다. (Bug #27309072, Bug #89031, Bug #27309082, Bug #89032)

• SET PASSWORD와 동시에 validate_password 컴포넌트를 설치 및 제거하면 컴포넌트 오류가 발생할 수 있었습니다. (Bug #27020979)

• 서버 소스 코드의 일부 오타가 수정되었습니다. 기여해 주신 Hyunwoo Park에게 감사드립니다. (Bug #26189673, Bug #86565)

• 컬럼 권한이 테이블에 부여된 후, HANDLER READ 호출이 권한 검사 중 어설션을 발생시켰습니다. (Bug #25987758)

• 외래 키 정의에서 참조하는 컬럼 타입과 참조되는 컬럼 타입의 호환성을 보장하는 검사가 스토리지 엔진 계층에서 SQL 계층으로 이동되었습니다. 또한 컬럼이 호환되지 않는 경우와 외래 키 제약 조건이 존재하지 않는 테이블을 참조하는 경우 더 나은 오류 메시지가 생성됩니다. (Bug #25722927, Bug #28371394, Bug #91712, Bug #21308781, Bug #77467, Bug #11746132, Bug #23693)

• 파서가 일부 메모리 부족 검사를 잘못 수행했습니다. (Bug #25633994)

• 사용자 관리 문과 grant 테이블에 직접 접근하려고 한 다른 문 사이의 경합 조건으로 인해 데드락과 트랜잭션 롤백이 발생할 수 있었습니다. (Bug #24481240)

• 서버가 skip_name_resolve 시스템 변수를 활성화한 상태로 시작된 경우, 호스트 이름 부분이 localhost인 계정을 무시한다는 잘못된 경고가 오류 로그에 기록될 수 있었습니다. (해당 계정은 실제로 사용되었으며 무시되지 않았습니다.) (Bug #23329861, Bug #81441)

• IGNORE를 사용하는 DML 문이 생성 컬럼이 있는 테이블에서 항상 올바르게 처리되지는 않았습니다. (Bug #22990029)

• MySQL은 이제 상수 리터럴 표현식에서 발생하는 자명한 WHERE 조건을 최적화의 이후 단계가 아니라 준비 중에 제거합니다. 이는 다음과 같이 자명한 조건을 포함하는 외부 조인이 있는 쿼리에 대해 개선된 실행 계획을 가져와야 합니다:

  SELECT * FROM t1 LEFT JOIN t2 ON condition_1 WHERE condition_2 OR 0 = 1
  

  중복된 OR 0 = 1 조건을 제거한 후 optimizer는 다음에 표시된 것처럼 쿼리를 내부 조인으로 다시 작성할 수 있습니다:

  SELECT * FROM t1 LEFT JOIN t2 WHERE condition_1 AND condition_2
  

  자세한 내용은 What Is New in MySQL 8.0 및 Outer Join Optimization을 참조하십시오. (Bug #16893426, Bug #28237111, Bug #28239008, Bug #28341790, WL #9571)

  참조: 함께 참조하십시오: Bug #28197977, Bug #28240054.

• FEDERATED 테이블의 BLOB 컬럼에 대한 업데이트가 작동하지 않았습니다. (Bug #11748067, Bug #34997)

• REGEXP_REPLACE(), REGEXP_SUBSTR(), REGEXP_LIKE(), REGEXP_INSTR() 함수 각각이 함수에 지정된 반환 타입의 값 대신 DOUBLE을 반환했습니다. (Bug #90039, Bug #27682225)

• 동적 범위와 인덱스 병합을 사용하는 쿼리가 예상보다 더 많은 메모리를 사용할 수 있었습니다. (Bug #89953, Bug #27659490)

• NO_PAD 콜레이션을 사용하는 CHAR 컬럼이 있는 테이블에서 선택하면 일관되지 않은 결과가 반환되었습니다. (Bug #89753, Bug #27578340)