Last Updated on 5월 14, 2024 by Jade(정현호)
안녕하세요
포스팅 글에서는 MySQL 8.4 LTS 버전 출시에 관련된 내용과 8.4 LTS 버전에서 변경된 점에서 확인해보도록 하겠습니다.
lefred님 블로그에서 정리된 InnoDB 관련 기본값이 변경된 파라미터 대한 글의 번역과 내용 정리와 MySQL 8.4 버전의 주요 변경 사항에 대해서 정리하였습니다.
Contents
- MySQL 8.4 LTS 버전
- InnoDB 파라미터 기본값 변경사항
- innodb_buffer_pool_in_core_file
- innodb_buffer_pool_instances
- innodb_change_buffering
- innodb_dedicated_server
- innodb_adaptive_hash_index
- innodb_doublewrite_files
- innodb_doublewrite_pages
- innodb_flush_method
- innodb_io_capacity
- innodb_io_capacity_max
- innodb_log_buffer_size
- innodb_numa_interleave
- innodb_page_cleaners
- innodb_parallel_read_threads
- innodb_purge_threads
- innodb_read_io_threads
- innodb_use_fdatasync
- temptable_max_ram
- temptable_max_mmap
- temptable_use_mmap
- MySQL 8.4 주요 변경사항
- Reference
MySQL 8.4 LTS 버전
MySQL 8.4 LTS 버전이 2024년 4월 30일에 GA(General Availability) 되었습니다.
MySQL은 이전에 8.0.34 마이너 버전이 출시하면서 향후 MySQL은 Innovation Version 과 Long-Term Support (LTS) version으로 구분하여 나눠서 출시할 것이라고 내용 발표 및 설명을 하였습니다.
해당 발표 내용에서 MySQL 8.4 버전이 LTS 버전으로 출시될 것이라고 릴리즈 예상 다이어그램을 통해 계획을 알렸습니다.
[Introducing MySQL Innovation Release]
LTS는 Long-Term Support의 약자로 장기 지원 버전을 의미하기 때문에 8.0 버전이 이후로 안정적인 운영이 필요한 실제 Production 환경에서 사용될 주요 버전으로 예상해볼 수 있습니다.
MySQL 8.4은 LTS 버전으로 출시되었으며 8.0 버전이후 Production(운영) 데이터베이스 버전으로 사용될 것으로 예상할 수 있습니다.
다음 포스팅 글에서는 8.0.34+ LTS 버전 및 Innovation Version 과 Long-Term Support (LTS) version에 대한 내용은 다음 글에서 조금 더 자세하게 설명하고 있습니다.
InnoDB 파라미터 기본값 변경사항
MySQL 8.4 LTS 버전에서는 이전의 많은 deprecation 된 내용에 대해서 최종적으로 Removed 된 내역도 많으며, 현재 시대의 워크로드 및 하드웨어 사양에 맞게 InnoDB 파라미터 기본값이 수정되었습니다.
InnoDB 관련 파라미터 20개의 기본값이 변경되었으며, 해당 파라미터를 살펴보고 변경된 이유를 확인해보도록 하겠습니다.
innodb_buffer_pool_in_core_file
코어 파일(core file)은 실행 중인 프로세스의 상태와 메모리 이미지를 기록하며, 버퍼 풀은 메인 메모리에 상주하고 실행 중인 프로세스의 메모리 이미지는 코어 파일에 덤프되기 때문에 큰 버퍼 풀이 있는 시스템은 mysqld 프로세스가 종료될 때 큰 코어 파일이 될 수도 있습니다.
대용량 코어 파일은 작성하는 데 걸리는 시간, 소비하는 디스크 공간, 대용량 파일 전송과 관련된 문제 등 여러 가지 이유로 문제가 될 수 있습니다.
파라미터 기본값 변경내역
- Previous Value: ON
- New Value (8.4 LTS): MADV_DONTDUP이 지원되는 경우 OFF 그렇지 않으면 ON
이와 관련된 파라미터가 innodb_buffer_pool_in_core_file 이며 8.0.14 버전 부터 도입되었으며 8.0 버전에서는 기본값이 ON이었으나, 8.4 버전에서는 MADV_DONTDUMP 를 지원하는 OS의 경우 OFF가 기본값이며 리눅스 3.4 이상에서는 지원을 하기 때문에 리눅스 운영 체제 대부분에서는 실질적으로 기본값이 OFF가 되며, MacOS나 Windows 시스템에서는 MADV_DONTDUMP 지원되지 않음으로 기본값이 ON이 됩니다.
innodb_buffer_pool_instances
innodb_buffer_pool_instance 변수는 InnoDB 버퍼 풀을 몇 개의 인스턴스로 나눌지 설정합니다.
큰 용량 예를 들어서 수 기가바이트 이상의 크기를 가지는 버퍼 풀을 갖는 시스템의 경우, 버퍼 풀을 별도의 여러 인스턴스로 분할하면 스레드가 캐시된 페이지를 읽고 쓰는 동안 경합을 줄여 동시성을 향상시킬 수 있습니다.
파라미터 기본값 변경내역
- Previous Version: 8 (or 1 if BP < 1 GB)
- New Value (8.4 LTS)
- If BP <= 1 GB: 1
- If BP > 1 GB: 1-64 사이 설정 가능하며 두개의 계산된 힌트에서 나온 최소값
a. Buffer pool hint : (innodb_buffer_pool_size / innodb_buffer_pool_chunk_size) / 2
b. CPU hint: 1/4 of available logical processors
일부 시스템에서는 이전 버전의 기본값인 8이 너무 클 수 있었습니다. 그래서 MySQL 8.4 LTS 버전에서는 위와 같이 변경되었습니다.
innodb_change_buffering
change buffering은 변경사항에 대해서 디스크 쓰기 작업시 보조 인덱스(Secondary Index)에 대한 쓰기를 지연시키는 기능입니다.
InnoDB가 change buffering을 수행 여부는 I/O 작업을 순차적으로(sequentially) 수행할 수 있도록 보조 인덱스에 대한 쓰기 작업을 지연시키는 최적화를 의미합니다.
파라미터 기본값 변경내역
- Previous Value: all
- New Value (8.4 LTS): none
이 기술은 순차적(sequentially) I/O를 선호하는 데 유리했던 기술입니다. 가장 최근의 하드웨어에서는 무작위(random) I/O가 더 이상 문제가 되지 않습니다.
(최근에 저장소가 HDD에서 SSD로 사용이 많이 변경되었기 때문)
Change Buffer(체인지 버퍼)에 대해서는 다음 포스팅을 참조하시면 됩니다.
innodb_dedicated_server
MySQL 8.0부터는 MySQL이 모든 리소스를 데이터베이스에 사용 가능한 전용 서버(dedicated server)에서 실행될 때 이 변수(innodb_dedicated_server)를 활성화하고 이 변수에 의해 관리되는 InnoDB 설정을 수동으로 수정하지 않는 것을 권장하고 있습니다.
파라미터 기본값 변경내역
- Previous Value: OFF
- New Value (8.4 LTS): ON
innodb_dedicated_server는 MySQL 8.0.3에서 추가된 시스템 파라미터입니다.
이 설정을 ON으로 하면 다음 4개의 파라미터를 자동으로 설정합니다.
- innodb_buffer_pool_size
- innodb_log_file_size
- innodb_log_files_in_group
- innodb_flush_method
MySQL 8.4부터 innodb_dedicated_server는 설정시 일부 변경되어 다음의 2개 파라미터를 자동으로 설정합니다.
- innodb_buffer_pool_size
- 서버 메모리가 1GB 미만인 경우 128MB입니다.
- 서버 메모리가 1GB에서 4GB 사이인 경우 서버 메모리 * 0.5입니다.
- 서버 메모리가 4GB보다 많은 경우 서버 메모리 * 0.75입니다.
- innodb_redo_log_capacity
- (사용 가능한 논리 프로세서 수/2) GB, 최대 16GB까지입니다.
- innodb_log_file_size 와 innodb_log_files_in_group 파라미터는 8.0.30 버전에서 deprecated 되었으며 innodb_redo_log_capacity 파라미터로 대체되었습니다.
MySQL 8.4 LTS 버전에서는 innodb_flush_method는 innodb_dedicated_server가 활성화되었을 때 자동으로 구성되지 않습니다.
innodb_flush_method 파라미터의 기본값도 변화가 있으며 아래에 내용이 있습니다.
innodb_adaptive_hash_index
AHI(InnoDB Adaptive Hash Index)는 오랫동안 일부 성능 문제의 원인이었습니다. 이전 버전에 존재하던 쿼리 캐시 기능과 유사하게(마찬가지) 해당 기능을 비활성화하는 것을 고려 해볼수 있습니다.
파라미터 기본값 변경내역
- Previous Value: ON
- New Value (8.4 LTS): OFF
AHI는 데이터가 변경되지 않고 버퍼 풀에 완전히 캐시된 경우 읽기 쿼리(SELECT)에 약간의 이점을 제공할 수 있습니다.
쓰기 작업이 많이 발생하거나 시스템 부하가 높아지거나 읽기에 필요한 모든 데이터를 캐시 할 수 없는 경우 적응형 해시 인덱스(AHI)는 많은 성능적 병목 현상을 발생시킬 수도 있습니다.
보다 예측 가능한 응답 시간을 가지려면 비활성화하는 것을 고려할 수 있습니다.
innodb_doublewrite_files
innodb_doublewrite_files 파라미터는 이중 쓰기(doublewrite) 파일 수를 정의합니다.
각 버퍼 풀 인스턴스에 대해 두 개의 이중 쓰기 파일 생성이 기본값입니다.
파라미터 기본값 변경내역
- Previous Value: innodb_buffer_pool_instances * 2
- New Value (8.4 LTS): 2
이전에는 기본값이 버퍼 풀 수에 따라 계산되었으나 8.4 버전에서는 단순화하기 위해 이제 기본값은 2입니다.
8.4 버전에서는 기본값 2라는 것은 buffer pool instance 수 x 2 라는 것을 의미하는 것은 이전과 동일 합니다.
8.4 버전에서 기본값 2를 사용하고, buffer pool instance 가 2일 경우 이중 쓰기(double write) 파일은 4개 입니다.
innodb_doublewrite_pages
innodb_doublewrite_pages 변수(MySQL 8.0.20에 도입됨)는 스레드당 최대 이중 쓰기 페이지 수를 제어합니다.
값을 지정하지 않으면 innodb_doublewrite_pages가 innodb_write_io_threads 값으로 설정됩니다.
파라미터 기본값 변경내역
- Previous Value: innodb_write_io_threads (4 by default)
- New Value (8.4 LTS): 128
테스트를 통해서 성능상으로 이점과 이유로 기본값을 늘리는 것이 권장되었으며 그에 따라서 기본값이 더 큰 값이 더 낫다는 것으로 판단되었습니다.
innodb_flush_method
innodb_flush_method은 MySQL의 InnoDB 스토리지 엔진에서 사용되는 파라미터 중 하나입니다. 이 파라미터는 디스크에 데이터를 쓸 때 사용할 파일 시스템 플러시 방법을 결정합니다. 이 파라미터는 서버의 데이터 일관성과 성능에 영향을 미칩니다.
파라미터 기본값 변경내역
- Previous Value: fsync
- New Value (8.4 LTS): O_DIRECT (or fsync)
시스템에서 지원되는 경우 O_DIRECT는 오래동안 항상 선호되는 값이었으며 파일 시스템 캐시를 우회하여 InnoDB 변경 사항을 디스크(데이터 파일 및 로그 파일의 경우)에 플러시하는 데 이 값을 사용하는 것이 좋습니다.
O_DIRECT가 지원되지 않으면 이전 fsync 메서드를 사용합니다. 이것은 Unix의 경우이며 Windows에서 기본값은 버퍼링되지 않습니다.
innodb_io_capacity
innodb_io_capacity 파라미터는 InnoDB 백그라운드 작업에서 사용 가능한 초당 I/O 작업 수(IOPS)를 정의합니다. 이러한 작업에는 버퍼 풀에서 페이지를 플러시하고 변경 버퍼(체인지 버퍼)에서 데이터를 병합하는 작업이 포함됩니다.
이 파라미터 값은 시스템이 초당 수행할 수 있는 I/O 작업 수(IOPS)에 대략적으로 설정되어야 합니다. innodb_io_capacity가 설정되면 InnoDB는 설정된 값에 기반하여 백그라운드 작업에 사용 가능한 I/O 대역폭을 추정합니다.
파라미터 기본값 변경내역
- Previous Value: 200
- New Value (8.4 LTS): 10000
이 파라미터는 InnoDB 백그라운드 작업에 사용할 수 있는 IOPS 수를 정의하므로 값이 너무 낮으면 성능이 제한되며, 최근 시스템(RAID, SSD 등)에 비해 파라미터 기본값이 낮았고 그에 따라 파라미터 기본값이 상향 조정된 것으로 보입니다.
다만 이 값이 너무 높으면 데이터가 버퍼 풀과 변경 버퍼(체인지 버퍼)에서 너무 빨리 내려쓰는 만큼 많은 쓰기 I/O가 동반될 수 있기 때문에 업무나 워크로드에 따라서 적절한 값 설정이 필요합니다.
연관된 innodb_io_capacity_max 파라미터까지 고려한다면 innodb_io_capacity 파라미터 값 설정은 많은 고려가 필요할 것으로 보입니다.
또한 MySQL이 사용되는 모든 환경이 온디멘드 서버에 NVMe SSD나 PCIe SSD와 같이 고성능 저장 시스템을 사용하는 것이 아닌 클라우드 RDS 등에서 제한된 IOPs 디스크 시스템을 사용할 수도 있기 때문에 해당 파라미터 값은 사용하는 시스템의 사양 및 워크로드에 따라 적절한 설정이 필요합니다.
innodb_io_capacity_max
플러싱 활동이 뒤처지면 InnoDB는 innodb_io_capacity 변수로 정의된 IOPS보다 더 높은 속도로 더 공격적으로 플러시할 수 있습니다. innodb_io_capacity_max 파라미터는 이러한 상황에서 InnoDB 백그라운드 작업에 의해 수행되는 최대 IOPS 수를 정의합니다.
파라미터 기본값 변경내역
- Previous Value: 2 * innodb_io_capacity (min 2000)
- New Value (8.4 LTS): 2 * innodb_io_capacity
InnoDB가 보다 적극적으로 플러시해야 하는 경우 이 변수는 InnoDB가 백그라운드 작업을 수행하는 데 사용할 수 있는 최대 IOPS 수를 정의합니다. 새로운 기본값은 innodb_io_capacity의 두 배로 더 간단한 계산식으로 되었습니다.
innodb_log_buffer_size
로그 버퍼는 디스크의 로그 파일에 쓰기 위해 데이터를 보유하는 메모리 영역입니다. 이러한 로그 버퍼 크기는 innodb_log_buffer_size 변수에 의해 정의됩니다.
파라미터 기본값 변경내역
- Previous Value: 16 MB
- New Value (8.4 LTS): 64 MB
큰 로그 버퍼는 트랜잭션이 커밋되기 전에 리두 로그 데이터를 디스크에 쓰지 않고도 대규모 트랜잭션이 실행될 수 있도록 합니다.
따라서 많은 행을 업데이트, 삽입 또는 삭제하는 트랜잭션이 있는 경우 로그 버퍼 크기를 증가시키면 디스크 I/O를 절약할 수 있습니다.
이러한 이유로 8.4 LTS 버전에서는 기본값이 증가되었습니다.
innodb_numa_interleave
innodb_numa_interleave 파라미터는 시스템이 NUMA를 지원하는 경우 InnoDB 버퍼 풀을 할당하는 동안 mysqld에 대해 NUMA 메모리 정책을 MPOL_INTERLEAVE로 설정합니다. 이 작업은 메모리 할당을 모든 numa 노드에 임의로 분산하여 해당 노드 간에 더 나은 분산을 제공합니다.
파라미터 기본값 변경내역
- Previous Value: OFF
- New Value (8.4 LTS): ON
시스템에 여러 NUMA 노드가 있는 경우에만 이점을 얻을 수 있습니다.
NUMA 노드 수를 확인하는 방법은 다음과 같습니다.
$ numactl --hardware
이러한 numa의 활용은 다른 종류의 데이터베이스에서도 사용되고 있습니다. 다만 회사마다 운영 정책으로 numa 에 대해서 미사용이 정책이라면 해당 파라미터의 기본값 변경은 큰 변화점이기 때문에 MySQL 8.4 버전으로 업그레이드 변경시 주요한 변경점으로 인지가 필요할 것으로 보입니다.
innodb_page_cleaners
InnoDB는 백그라운드에서 특정 작업을 수행하는데, 이에는 버퍼 풀에서 더티 페이지를 플러시하는 것이 포함됩니다. 더티 페이지란 수정되었지만 아직 디스크의 데이터 파일에 기록되지 않은 페이지를 의미합니다.
MySQL 8.0에서는 버퍼 풀 플러싱이 페이지 클리너 스레드(page clear threads)에 의해 수행됩니다. innodb_page_cleaners 파라미터는 이러한 페이지 클리너 스레드의 수를 설정하는데 사용됩니다.
파라미터 기본값 변경내역
- Previous Value: 4
- New Value (8.4 LTS): innodb_buffer_pool_instances
새로운 기본값은 버퍼 풀 인스턴스가 있는 만큼의 스레드를 사용하여 버퍼 풀 인스턴스에서 더티 페이지를 플러시하는 것입니다.
innodb_parallel_read_threads
innodb_parallel_read_threads 파라미터는 8.0.14 버전에서 추가된 "InnoDB now supports parallel clustered index reads" 기능에 관련된 파라미터입니다.
"InnoDB now supports parallel clustered index reads" 기능은 인덱스 생성시에 생성과 관련된 데이터를 조회시에 사용되는 기능으로 "InnoDB now supports parallel clustered index reads" 기능은 PK인 Clustered Index 에서만 사용할 수 있는 기능입니다
파라미터 기본값 변경내역
- Previous Value: 4
- New Value (8.4 LTS): logical processors / 8 (min 4)
성능상의 이유로, 많은 양의 논리 CPU가 있는 시스템에서는 병렬 클러스터형 인덱스 읽기에 사용되는 스레드 수가 자동으로 증가하도록 새롭게 기본값이 변경되었습니다.
innodb_parallel_read_threads 와 InnoDB now supports parallel clustered index reads 에 대한 내용은 다음 포스팅을 참조하시면 됩니다.
innodb_purge_threads
InnoDB는 SQL 문으로 행을 삭제할 때 즉시 데이터베이스에서 행을 물리적으로 제거하지 않습니다. 행과 해당 인덱스 레코드는 InnoDB가 삭제를 위해 작성된 UNDO 로그 레코드를 삭제할 때만 물리적으로 제거됩니다.
MVCC(다중 버전 동시성 제어) 또는 롤백에서 행이 더 이상 필요하지 않은 후에만 발생하는 이 제거 작업을 수행합니다. innodb_purge_threads 파라미터는 이와 같은 InnoDB 제거 작업에 사용되는 백그라운드 스레드 수입니다.
활성 퍼지 스레드가 너무 많으면 사용자 스레드와 경합이 발생할 수 있으므로 적절한 innodb_purge_threads 값 설정이 필요합니다.
파라미터 기본값 변경내역
- Previous Value: 4
- New Value (8.4 LTS): 1 if logical processors <= 16 else 4
파라미터는 vCPU가 16보다 적을 경우 (<=16) 기존 버전에 비해 적은 기본값 1이 되며(기존 기본값 4), vCPU 수가 많은(>=16) 시스템에 대해서도 4로 구성됩니다.
MySQL팀에서는 4개의 퍼지 스레드에 대해서 일부 소규모 시스템이나 많지 않은 vCPU 시스템에서는 경합적인 문제가 발생될 수 있다는 것을 확인하였고 그에 따라서 기본값이 변경되었다고 합니다.
innodb_read_io_threads
InnoDB의 읽기 작업을 위한 I/O 스레드 수 설정에 관련된 파라미터입니다.
파라미터 기본값 변경내역
- Previous Value: 4
- New Value (8.4 LTS): logical processors / 2 (min 4)
이 파라미터는 8.4 LTS버전에서 8개 이상의 vCPU가 있는 경우 자동으로 증가합니다.
innodb_use_fdatasync
fdatasync() 시스템 호출을 지원하는 플랫폼에서 innodb_use_fdatasync 변수가 운영 체제 플러시를 위해 fsync() 시스템 호출 대신 fdatasync()를 사용하도록 허용합니다.
fdatasync() 호출은 후속 데이터 검색에 필요하지 않는 한 파일 메타데이터의 변경 사항을 플러시하지 않으므로 잠재적인 성능 이점을 제공합니다.
파라미터 기본값 변경내역
- Previous Value: OFF
- New Value (8.4 LTS): ON
innodb_flush_method 설정 중 일부인 fsync, O_DSYNC 및 O_DIRECT와 같은 옵션에서도 fsync() 시스템 호출을 사용합니다. innodb_use_fdatasync 변수는 해당 설정을 사용할 때 적용됩니다.
temptable_max_ram
temptable_max_ram은 MySQL에서 사용되는 파라미터 중 하나입니다. 이 파라미터는 특정 쿼리에 의해 생성된 임시 테이블의 최대 RAM 사용량을 제어합니다.
이 값을 설정하면 MySQL이 임시 테이블을 메모리 내에 유지하려고 시도할 때 사용할 수 있는 최대 메모리 양을 제한합니다. 이 파라미터는 MySQL의 성능과 메모리 사용에 영향을 미칠 수 있으므로 적절하게 조정하는 것이 중요합니다.
파라미터 기본값 변경내역
- Previous Value: 1 GB
- New Value (8.4 LTS): 3% of total memory (within a range of 1-4 GB)
이제 새로운 기본값은 시스템이 많은 양의 메모리를 사용하면 자동으로 증가합니다. 그러나 기본값에서는 최대 4GB로 제한됩니다. 따라서 132GB 이상의 메모리를 사용하는 시스템의 경우 기본값으로 temptable_max_ram의 값이 4GB로 설정됩니다.
temptable_max_mmap
temptable_max_mmap 파라미터는 MySQL 8.0.23에서 도입되었으며 TempTable 스토리지 엔진이 디스크에 있는 InnoDB 내부 임시 테이블을 사용하기 전에 메모리 매핑 파일에서 할당할 수 있는 최대 메모리 양을 정의합니다.
연관된 파라미터는 temptable_use_mmap 입니다.
파라미터 기본값 변경내역
- Previous Value: 1 GB
- New Value (8.4 LTS): 0 (disabled)
temptable_max_mmap=0 설정은 메모리 매핑 파일에서의 할당을 비활성화하며, temptable_use_mmap 설정과는 상관없이 사용을 비활성화합니다.
8.4 버전에서 새로운 기본값은 메모리 매핑된 임시 파일의 메모리 할당 기능을 비활성화합니다.
temptable_use_mmap
temptable_max_mmap 파라미터를 설정하여 임시 데이터가 먼저 메모리 매핑된 임시 파일에 오버플로될지, 디스크의 InnoDB 내부 임시 테이블에 오버플로될지 선택할 수 있습니다.
파라미터 기본값 변경내역
- Previous Value: ON
- New Value (8.4 LTS): OFF
temptable_use_mmap파라미터는 MySQL 8.0.16에 도입되어 MySQL 8.0.26버전에서부터 Deprecated 되어 실제로는 사용되지 않은 파라미터입니다.
8.0.26 버전부터 temptable_use_mmap를 사용하지 않기 위해서는 temptable_max_mmap 파라미터를 0으로 설정하는 내용이 적용되었습니다.
8.4에서 버전에서 temptable_use_mmap의 기본값이 OFF로 변경되었으나 실질적으로 이전 버전부터 사용되지 않은 파라미터로 실질적은 변경은 없으며, temptable_max_mmap 파라미터의 기본값이 0으로 된 것이 실질적인 변경사항이라고 할 수 있습니다.
MySQL 8.4 주요 변경사항
MySQL 8.4 LTS 버전에서 변경된 여러가지 내용 중에서 주요한 변경사항에 대해서 확인해보도록 하겠습니다.
복제 관련 변경사항
MySQL 8.4 LTS 버전에서는 이전 8.0버전에서 계속 안내되고 이미 Deprecated 된 복제 명령어 및 용어에 대해서 Removed가 되었습니다.
MySQL 8.4 버전으로 업그레이드시 사용하는 복제 모니터링 및 HA 솔루션 등에서 MySQL 복제 관련 명령어 관련하여 수정 및 대응이 필요합니다.
복제 SQL Statement Removed
removed 된 SQL 명령문이 나열 되어있으며 괄호 안의 내용은 대체되는 항목입니다.
- START SLAVE (START REPLICA)
- STOP SLAVE (STOP REPLICA)
- SHOW SLAVE STATUS (SHOW REPLICA STATUS)
- SHOW SLAVE HOSTS (SHOW REPLICAS)
- RESET SLAVE (RESET REPLICA)
- CHANGE MASTER TO (CHANGE REPLICATION SOURCE TO)
- RESET MASTER (RESET BINARY LOGS AND GTIDS)
- SHOW MASTER STATUS (SHOW BINARY LOG STATUS)
- PURGE MASTER LOGS (PURGE BINARY LOGS)
- SHOW MASTER LOGS (SHOW BINARY LOGS)
위의 나열된 Statement은 내부적으로 사용되는 모든 MySQL 테스트 프로그램 및 파일 및 기타 다른 곳에서도 제거되었습니다.
복제 관련 SQL Statement 옵션 Removed
명령어의 옵션 중에서 Removed 된 내역입니다. 괄호 안의 내용은 대체되는 항목입니다.
- MASTER_AUTO_POSITION (SOURCE_AUTO_POSITION)
- MASTER_HOST (SOURCE_HOST), MASTER_BIND (SOURCE_BIND)
- MASTER_USER (SOURCE_USER), MASTER_PASSWORD (SOURCE_PASSWORD)
- MASTER_PORT (SOURCE_PORT), MASTER_CONNECT_RETRY (SOURCE_CONNECT_RETRY)
- MASTER_RETRY_COUNT (SOURCE_RETRY_COUNT), MASTER_DELAY (SOURCE_DELAY)
- MASTER_SSL (SOURCE_SSL), MASTER_SSL_CA (SOURCE_SSL_CA)
- MASTER_SSL_CAPATH (SOURCE_SSL_CAPATH), MASTER_SSL_CIPHER (SOURCE_SSL_CIPHER)
- MASTER_SSL_CRL (SOURCE_SSL_CRL), MASTER_SSL_CRLPATH (SOURCE_SSL_CRLPATH)
- MASTER_SSL_KEY (SOURCE_SSL_KEY),
- MASTER_SSL_VERIFY_SERVER_CERT(SOURCE_SSL_VERIFY_SERVER_CERT)
- MASTER_TLS_VERSION (SOURCE_TLS_VERSION)
- MASTER_TLS_CIPHERSUITES (SOURCE_TLS_CIPHERSUITES)
- MASTER_SSL_CERT (SOURCE_SSL_CERT), MASTER_PUBLIC_KEY_PATH (SOURCE_PUBLIC_KEY_PATH)
- GET_MASTER_PUBLIC_KEY (GET_SOURCE_PUBLIC_KEY)
- MASTER_HEARTBEAT_PERIOD (SOURCE_HEARTBEAT_PERIOD)
- MASTER_COMPRESSION_ALGORITHMS (SOURCE_COMPRESSION_ALGORITHMS)
- MASTER_ZSTD_COMPRESSION_LEVEL (SOURCE_ZSTD_COMPRESSION_LEVEL)
- MASTER_LOG_FILE (SOURCE_LOG_FILE), and MASTER_LOG_POS (SOURCE_LOG_POS)
START REPLICA 명령어 옵션 Removed
START REPLICA 명령어의 옵션에서 Removed 된 내역이며 괄호 안의 내용은 대체되는 항목입니다.
- MASTER_LOG_FILE (SOURCE_LOG_FILE)
- MASTER_LOG_POS (SOURCE_LOG_POS)
Status variables removed
복제 관련 용어의 제거와 연관된 내용으로 SHOW STATUS와 같은 문에서 더 이상 출력되지 않습니다. 이러한 변수는 다음과 같으며 괄호 안에는 대체 변수명이 표시되어 있습니다.
- Com_slave_start (Com_replica_start)
- Com_slave_stop (Com_replica_stop)
- Com_show_slave_status (Com_show_replica_status)
- Com_show_slave_hosts (Com_show_replicas)
- Com_show_master_status (Com_show_binary_log_status)
- Com_change_master (Com_change_replication_source)
default_authentication_plugin 파라미터 Remove
default_authentication_plugin 파라미터가 MySQL 8.4 버전에서 사라(Removed)지면서 default_authentication_plugin 파라미터를 사용하면 MySQL 기동시 에러가 발생합니다.
[ERROR] [MY-000067] [Server] unknown variable 'default_authentication_plugin=mysql_native_password'
기존에 패스워드 인증 방식인 "mysql_native_password" 플러그인은 Deprecated 되었으나 사라지지 않았았으며 다른 파라미터를 설정하여 사용할 수 있습니다.
## mysql.cnf mysql_native_password=ON
기본 패스워드 인증 방식인 caching_sha2_password 상태에서 다음과 같이 mysql_native_password 방식으로 패스워드 방식 설정사용하게 되면 에러가 발생합니다.
mysql> alter user '계정명'@'%' IDENTIFIED WITH mysql_native_password BY '비밀번호'; ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.
mysql_native_password=ON 파라미터 설정 후에 mysql_native_password 파라미터를 제거하거나 명시적으로 값을 OFF 설정한 경우에 기존에 mysql_native_password 으로 패스워드 인증 방식으로 설정된 계정은 로그인이 되지 않습니다.
# 로그인시 에러 메세지 ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded
그 외 MySQL 8.4버전에서 Removed 된 파라미터 정보는 다음 문서를 참조하시면 됩니다.
caching_sha2_password 패스워드 플러그인에 대한 내용은 다음 포스팅 글을 참조하시면 됩니다.
새로운 권한 - FLUSH_PRIVILEGES
MySQL 8.4 버전에서 FLUSH PRIVILEGES문의 사용과 관련된 권한을 추가되었습니다. 기존 RELOAD 권한과 달리 새로운 FLUSH_PRIVILEGES 권한은 FLUSH PRIVILEGES 문에만 적용됩니다.
이 권한은 범위가 전역적이며 사용자 및 Role에 적용할 수 있습니다.
-- 권한 부여 grant FLUSH_PRIVILEGES on *.* to '계정명'; -- 권한 회수 revoke FLUSH_PRIVILEGES on *.* from '계정명';
MySQL 5.7에서 MySQL 8.4으로 Upgrade 불가
MySQL 5.7에서 MySQL 8.4로의 직접 업그레이드는 지원되지 않으며, 이를 반영하여 코드와 동작이 업데이트되었습니다.
MySQL 8.4버전으로 업그레이드를 진행하기 전에 MySQL 5.7버전은 MySQL 8.0 버전으로 먼저 업그레이드를 해야 합니다.
5.7버전에서 8.0버전으로 업그레이드에 대한 내용은 다음 글을 참조하시면 됩니다.
Removed - ignore client side character
MySQL 8.3버전 부터해서 Client side의 캐릭터셋 설정 무시에 관련된 파라미터 2개가 모두 Removed 되었습니다.
- character-set-client-handshake
- skip-character-set-client-handshake
그래서 MySQL 8.4 LTS 버전에서도 2개 파라미터 모두 제거가 필요하며 파라미터가 제거됨에 따라 클라이언트 측의 캐릭터셋 설정 무시 기능을 사용할 수 없습니다.
Reference
Reference URL
• dev.mysql.com/news-8-4-0
• mysql.com/8.4-added-deprecated-removed
• lefred.be/mysql-8-4-lts-new-production-ready-defaults-for-innodb
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
현호님 잘 지내시죠? mysql팀 류수미예요. 해당 내용 다른분께도 도움이 될 듯하여 유저그룹에도 공유하고 싶은데 괜찮으시죠? 혹시 불편하시면 페메로 메세지주시면 내리겠습니다.
안녕하세요 수미님
MySQL 사용자 그룹에 공유해 주셔도 좋을 것 같습니다.!
먼저 챙겨주셔서 감사합니다.
좋은 하루 되세요!
좋은 내용 감사합니다.
댓글 감사합니다.
좋은 내용 감사합니다.
댓글 감사합니다.
좋은 하루되세요