AWS 기술 블로그
Amazon RDS MySQL LTS 버전 8.4 정식 출시
이 글은 AWS Database Delivery Blog에 게시된 Amazon RDS for MySQL LTS version 8.4 is now generally available by Mershad Irani and Vijay Karumajji 을 한국어 번역 및 편집하였습니다.
Amazon Relational Database Service(Amazon RDS)는 MySQL 커뮤니티의 최신 LTS(장기 지원) 메이저 버전인 MySQL 버전 8.4에 대한 지원이 발표되었습니다. 이를 통해 Amazon RDS는 이제 MySQL Community Edition 버전 8.0 및 8.4를 지원합니다. 커뮤니티에서 지원하는 두 가지 LTS 릴리즈 외에도 Amazon RDS는 RDS 확장 지원에 따라 MySQL 5.7도 제공합니다. 여기서 RDS는 엔진에 중요한 패치와 버그 수정을 제공합니다. 이러한 버전에 관계없이 기존 MySQL 코드, 애플리케이션 및 도구를 Amazon RDS로 가져올 수 있습니다.
MySQL 8.4를 통해 MySQL 커뮤니티는 MySQL 8.4 참조 매뉴얼에 나열된 여러 기능을 도입하거나 폐기했습니다. 이 게시물에서는 이러한 기능 중 일부를 살펴보고, 알려진 주요 변경 사항을 나열하고, 워크로드를 이 버전으로 쉽게 마이그레이션할 수 있는 권장 사항을 제공합니다.
RDS for MySQL 8.4에 대해 자세히 알아보기 전에 작년에 커뮤니티에서 도입한 새로운 MySQL 버전 관리 모델을 살펴보겠습니다. MySQL 커뮤니티는 이제 모든 엔진 릴리즈를 Innovation 릴리즈 또는 LTS(장기 지원) 릴리즈로 분류합니다.
- Innovation(혁신) 릴리즈: 이 버전은 자주 릴리즈되며(일반적으로 분기당 1개 릴리즈) 지원 주기가 짧기 때문에 개발자와 DBA가 조기에 신속하게 실험하는 데 이상적입니다. 이 글을 쓰는 시점에서 MySQL 커뮤니티는 버전 8.1, 8.2, 8.3, 9.0 및 9.1의 5가지 혁신 릴리즈를 발표했습니다. 이러한 릴리즈의 수명 주기가 짧기 때문에 Amazon RDS 데이터베이스 미리 보기 환경에서 이러한 버전을 제공합니다.
- LTS(장기 지원) 릴리즈: 대조적으로 LTS 릴리즈에는 이전 혁신 릴리즈에 도입된 기능을 포함하여 안정적이고 입증된 기능이 포함되어 있으며 5년 동안 커뮤니티 지원을 받습니다(RDS는 커뮤니티 중단 후 RDS 확장 지원에 따라 최대 3년 추가 제공 버전을 지원합니다). MySQL 커뮤니티는 LTS 릴리스의 첫 번째 버전, 예를 들어 8.4.0에서만 기능을 추가/제거할 것으로 예상합니다. MySQL 8.4.1 및 8.4.2와 같은 LTS 시리즈 내의 증분 릴리스는 이전 버전과의 호환성과 보안을 우선시합니다. MySQL 8.4는 커뮤니티의 첫 번째 LTS 릴리즈이며 추가 LTS 릴리즈는 약 2년마다 한 번씩 출시될 예정입니다. 장기적인 지원이 필요하고 주요 변경으로 인한 중단이 최소화되는 기업은 혁신 릴리즈보다 LTS 릴리즈를 선호합니다.
자세한 내용은 MySQL Release: Innovation 및 LTS를 검토하세요.
Amazon RDS for MySQL 8.0 데이터베이스를 MySQL 8.4로 업그레이드
MySQL 업그레이드 계획을 시작하기 전에 MySQL 커뮤니티의 업그레이드 방법 지침을 검토하는 것이 좋습니다. MySQL용 Amazon RDS는 MySQL 8.0에서 8.4로의 직접 업그레이드를 지원합니다. 8.0.22보다 낮은 마이너 버전을 실행하는 경우 MySQL 8.4로 업그레이드하기 전에 더 높은 마이너 버전으로 중간 업그레이드가 필요합니다. 또한 MySQL은 다중 버전 업그레이드를 지원하지 않습니다. 즉, 메이저 버전이나 LTS 업그레이드 중에 버전을 건너뛸 수 없습니다. 데이터베이스가 MySQL 5.7을 실행 중인 경우 먼저 MySQL 5.7을 MySQL 8.0으로 업그레이드한 다음 MySQL 8.0을 MySQL 8.4로 업그레이드해야 합니다.
Amazon RDS for MySQL 8.0 데이터베이스를 MySQL 8.4로 업그레이드할 때 Amazon RDS 블루/그린 배포 사용, 읽기 복제본 사용, In-Place 업그레이드 수행 등 다양한 옵션이 있습니다. 이 중에서 데이터베이스 업그레이드 중 위험과 가동 중지 시간을 최소화하려면 Amazon RDS 블루/그린 배포를 사용하는 것이 좋습니다. 새로운 메이저/LTS 버전과 기존 애플리케이션의 호환성을 확인하는 것은 업그레이드의 전반적인 성공에 중요한 역할을 합니다. Amazon RDS 블루/그린 배포는 현재 프로덕션 환경(블루)과 스테이징 환경(그린)이라는 두 가지 데이터베이스 환경을 생성합니다. 블루 및 그린 환경은 기본 논리 복제를 사용하여 서로 동기화 상태를 유지하므로 스테이징(그린) 환경에서 변경 사항을 안전하게 테스트하고 애플리케이션이 새 버전과 호환된다는 확신이 있는 경우에만 프라이머리 환경으로 승격할 수 있습니다. 이 접근 방식을 사용하면 프로덕션 설정과 함께 안전한 스테이징 환경에서 데이터베이스 업그레이드를 테스트할 수 있으며 프로덕션 환경에 영향을 주지 않고 문제를 식별하고 해결할 수 있습니다.
다음 섹션에서는 귀하의 애플리케이션과 관련이 있을 수 있는 MySQL 8.4에 도입된 주목할만한 변경 사항에 대해 논의합니다.
성능 관련 파라미터 기본값 변경
MySQL 8.4에서 커뮤니티는 플러시 동작에 영향을 미칠 수 있는 여러 파라미터 기본값을 변경했습니다. MySQL용 Amazon RDS는 동일한 기본값을 사용합니다. 업그레이드하기 전에 이러한 새로운 기본값으로 애플리케이션을 철저히 테스트하는 것이 좋습니다. 이러한 변경 사항은 전반적인 성능을 향상시키기 위해 설계되었지만 일부 워크로드에는 추가 파라미터 조정이 필요할 수 있습니다. 각 파라미터 변경 사항을 주의 깊게 검토하고 특정 사용 사례에 미치는 영향을 고려하세요. 다음 표는 MySQL 8.0과 8.4 사이의 기본 파라미터 값의 차이점을 보여줍니다.
파라미터 | Amazon RDS MySQL 8.0 기본값 | Amazon RDS MySQL 8.4 기본값 |
innodb_adaptive_hash_index |
ON |
OFF |
innodb_change_buffering |
ALL |
NONE |
innodb_buffer_pool_instances |
8 (또는 innodb_buffer_pool_size 가 1GB 미만인 경우 1) |
innodb_buffer_pool_size 가 1 GiB 작거나 같은 경우, innodb_buffer_pool_instances 의 기본값은 1 입니다.innodb_buffer_pool_size 가 1 GiB 보다 큰 경우, innodb_buffer_pool_instances 값은 1~64 범위 내에서 다음 두 가지 계산된 힌트의 최소값입니다Buffer pool hint: (innodb_buffer_pool_size / innodb_buffer_pool_chunk_size ) 값의 1/2로 계산됩니다.CPU 힌트: 사용 가능한 논리 프로세서의 1/4로 계산됩니다. |
innodb_page_cleaner_threads |
4 | innodb_page_buffer_pool_instances 와 같음 |
innodb_io_capacity |
200 | 10000 |
innodb_io_capacity_max |
2 * innodb_io_capacity, min of 2000 |
2* innodb_io_capacity |
innodb_read_io_threads |
4 | 사용 가능한 논리 프로세서 * 1/2, 최소 4개 |
innodb_purge_threads |
1 | Amazon RDS default: LEAST({DBInstanceVCPU/2}, 4) .업스트림 기본값: 사용 가능한 논리 프로세서 수가 16개 이하인 경우 1이고, 그렇지 않으면 4입니다. |
innodb_log_buffer_size |
16 MB | 64 MB |
temptable_max_ram |
1 GB | 1~4GiB 범위 내에서 총 메모리의 3% |
temptable_max_mmap |
1 GB | 0 , OFF 의 의미 |
temptable_use_mmap |
ON |
OFF |
기본 인증 플러그인을 caching_sha2_password로 설정
MySQL 8.4부터 Amazon RDS는 기본 인증 플러그인을 caching_sha2_password
로 전환했습니다. caching_sha2_password 플러그인은 성능 향상을 위해 서버 측 캐싱으로 SHA-256 비밀번호 해싱을 구현합니다.
인증 플러그인은 MySQL 서버에 연결을 시도하는 동안 사용자의 신원을 확인하는 데 사용되는 방법을 결정합니다. 자격 증명을 확인하고 데이터베이스 시스템에 대한 액세스 권한을 부여하는 데 사용되는 프로토콜과 알고리즘을 정의합니다.
이전 기본 인증 플러그인인 mysql_native_password
는 MySQL 8.0.34부터 커뮤니티에서 더 이상 사용되지 않으며 MySQL 9.0 및 후속 Innovation 릴리즈에서는 완전히 제거되었습니다. 새로운 사용자를 생성할 때 새로운 기본 인증 플러그인, 즉 caching_sha2_password
를 사용하는 것이 좋습니다.
caching_sha2_password
플러그인을 사용하여 생성된 사용자 계정으로 MySQL용 RDS DB 인스턴스에 연결할 때는 SSL을 사용해야 합니다. MySQL 5.7 이상 버전의 명령줄 클라이언트에는 기본적으로 SSL이 활성화되어 있습니다. 암호화되지 않은 연결을 사용하는 경우 연결은 보안을 유지하기 위해 RSA 키 쌍을 사용한 암호 교환을 지원해야 합니다.
다음 예에서는 SSL이 비활성화된 RSA 키 쌍 교환을 사용하여 데이터베이스에 연결하는 방법을 보여줍니다.
5.7 이전의 MySQL 클라이언트 버전은 caching_sha2_password
인증 플러그인을 지원하지 않습니다. 호환성을 보장하려면 MySQL 클라이언트를 최신 버전으로 업그레이드하는 것이 중요합니다.
기존 Amazon RDS 인스턴스를 MySQL 8.0에서 MySQL 8.4로 업그레이드한 경우 기본 사용자를 포함한 기존 데이터베이스 사용자는 계속해서 mysql_native_password
를 사용합니다. 그러나 모든 신규 사용자는 caching_sha2_password
인증 플러그인을 통해 생성됩니다. mysql_native_password
로 생성된 기존 사용자를 마이그레이션하여 caching_sha2_password
플러그인을 사용하는 것이 좋습니다. 다음 ALTER USER 명령을 사용하면 mysql_native_password
로 생성된 기존 사용자를 caching_sha2_password
로 수정할 수 있습니다.
다음 쿼리를 사용하여 mysql_native_password
인증 플러그인이 있는 모든 사용자를 나열할 수 있습니다.
새롭게 포함되는 용어 (RDS for MySQL 8.4) |
이전 용어 (RDS for MySQL 8.0 & RDS for MySQL 8.4) |
rds_reset_external_source | rds_reset_external_master |
rds_set_external_source_with_auto_position | rds_set_external_master_with_auto_position |
rds_next_source_log | rds_next_master_log |
rds_set_external_source | rds_set_external_master |
rds_set_external_source_with_delay | rds_set_external_master_with_delay |
rds_set_source_auto_position | rds_set_master_auto_position |
이전 버전과의 호환성을 보장하기 위해 두 저장 프로시저 세트 모두 Amazon RDS for MySQL 8.4에서 지원됩니다. 그러나 새롭고 포괄적인 명명 규칙을 채택하는 것이 좋습니다. 이전 절차는 MySQL용 Amazon RDS의 향후 릴리즈에서 제거될 예정이므로 새 이름으로 전환하면 장기적인 호환성을 보장하고 포괄적 언어에 대한 업계 모범 사례에 부합하는 데 도움이 됩니다.
사용자가 만든 모든 저장 프로시저의 경우 지원되지 않는 용어가 포함된 사용자 지정 저장 프로시저를 수동으로 검토하고 업데이트하는 것이 좋습니다. 그렇지 않으면 주요 버전 업그레이드 중에 문제가 발생할 수 있습니다. 업그레이드 사전 확인 프로세스에서는 영향을 받는 모든 절차를 식별하려고 시도하지만 목록이 완전하지 않을 수도 있습니다.
binlog_transaction_dependency_tracking 제거
MySQL 8.4부터 커뮤니티는 binlog_transaction_dependency_tracking
변수를 제거했습니다. MySQL은 이제 다중 스레드 복제본이 사용 중일 때 WRITESETS
를 사용하여 바이너리 로그에 대한 종속성 정보를 생성합니다. 이 동작은 이전 MySQL 버전에서 binlog_transaction_dependency_tracking
을 WRITESETS
으로 설정하는 것과 동일합니다. 이 변경은 다중 스레드 복제 시나리오의 성능 최적화를 향상시키는 것을 목표로 합니다.
지금까지 이 게시물에서는 8.4 LTS 릴리즈에서 MySQL 커뮤니티에 의해 추가되거나 제거된 기능에 대해 논의했습니다. 다음 섹션에서는 Amazon RDS for MySQL 8.4의 향상된 기능을 살펴보겠습니다.
암호화 라이브러리 공급자를 OpenSSL에서 AWS-LC로 대체
버전 8.4부터 Amazon RDS for MySQL은 AWS Libcrypto(AWS-LC) FIPS 모듈(인증서 #4816)과 통합되었습니다. MySQL 8.4용 Amazon RDS는 TLS 1.2 및 TLS 1.3을 지원하며 다음 암호화 제품군을 지원합니다.
지원되는 TLS 버전 및 암호화 제품군과 클라이언트 애플리케이션의 호환성을 확인하는 것이 좋습니다. 이는 원활한 연결을 제공하고 새로운 암호화 라이브러리가 제공하는 향상된 보안을 유지하는 데 중요합니다.
InnoDB_dedicated_server를 기본적으로 활성화되도록 설정
MySQL 8.4부터 Amazon RDS는 기본적으로 innodb_dedicated_server
파라미터를 활성화합니다. 이를 통해 데이터베이스 엔진은 기본 인스턴스를 기반으로 innodb_buffer_pool_size
및 innodb_redo_log_capacity
에 대한 최적의 값을 자동으로 계산할 수 있습니다. 이는 특정 워크로드에 대한 성능 향상을 제공할 수 있습니다. 테스트에서 innodb_dedicated_server
가 기본적으로 활성화된 경우 이 파라미터가 비활성화된 구성에 비해 DML 처리량이 최대 3배 향상된 것으로 나타났습니다.
innodb_redo_log_capacity
값은 vCPU 수를 기준으로 계산됩니다. 공식은 (vCPU수/2)GB이며, 최대 동적 기본값은 16GB입니다. 반면, innodb_buffer_pool_size
는 다음 표와 같이 DB 인스턴스 클래스 메모리를 기준으로 계산됩니다.
Detected Server Memory | Buffer Pool Size |
1 GB 미만 | 128 MB (기본 값) |
1 GB 에서 4 GB 까지 | 감지된 서버메모리 * 0.5 |
4 GB 초과 | 감지된 서버메모리* 0.75 |
innodb_dedicated_server
가 InnoDB 버퍼 풀 및 다시 실행 로그의 크기를 자동으로 계산하지만 innodb_redo_log_capacity
및 innodb_buffer_pool_size를 파라미터 그룹의 사용자 정의 값으로 재정의할 수 있는 옵션이 여전히 있습니다. 사용자 정의 값을 선택하는 경우 innodb_dedicated_server
를 활성화된 상태로 유지하는 것이 좋습니다. 이렇게 하면 파라미터 그룹에서 파라미터가 재설정되면 innodb_redo_log_capacity
의 경우 100MB, innodb_buffer_pool_size
의 경우 128MB라는 잠재적으로 부적합한 값을 기본값으로 설정하는 대신 innodb_dedicated_server
에서 계산한 값으로 되돌아갑니다. 자세한 내용은 전용 MySQL 서버에 대한 자동 InnoDB 구성 활성화를 참조하세요.
옵션 그룹에서 Memcached 플러그인을 제거
MySQL 커뮤니티는 버전 8.0.22에서 Memcached 플러그인을 더 이상 사용하지 않으며 MySQL 8.4부터 완전히 제거했습니다. 결과적으로 MySQL용 RDS 옵션 그룹은 더 이상 MEMCACHED
를 옵션으로 지원하지 않습니다. 대안으로 Amazon ElastiCache와 같은 Amazon RDS for MySQL 외부 캐싱 서비스를 사용하는 것이 좋습니다.
binlog_format 기본값을 ROW로 전환
binlog_format
변수의 기본값이 ROW
로 변경되었습니다. 이는 보다 정확하고 효율적인 데이터 복제를 제공하며 Amazon Redshift와 Amazon RDS zero-ETL 통합을 설정하기 위한 전제 조건입니다.
binlog_format
을 ROW
로 설정하면 읽기 전용 복제본에서 이진 로그를 재생할 때 MySQL은 테이블에 기본 키가 없는 경우 각 행 업데이트에 대해 전체 테이블을 검색해야 합니다. 이로 인해 특히 다중 행 업데이트 작업 중에 예상치 못한 대기 시간이 발생할 수 있습니다. 이 문제를 완화하려면 데이터베이스 스키마를 검토하고 모든 테이블에 적절한 기본 키가 정의되어 있는지 확인하는 것이 좋습니다.
읽기 가능한 대기가 2개 있는 RDS 다중 AZ 배포의 경우 binlog_format
이 클러스터 파라미터 그룹에서 제거되었습니다. 대신, 이제 기본 ‘binlog_format
‘ 설정인 ‘ROW
‘를 사용합니다.
vCPU 수에 따라 확장되도록 InnoDB_purge_threads 기본값을 변경
Purge는 MySQL 데이터베이스의 관리 작업입니다. InnoDB 스토리지 엔진은 이를 사용하여 MVCC(다중 버전 동시성 제어) 또는 롤백 작업에 더 이상 필요하지 않은 Undo 로그 및 삭제 표시된 테이블 레코드를 정리합니다. MySQL 8.4용 Amazon RDS에서 InnoDB Purge 스레드는 이제 기본 인스턴스의 vCPU 수에 따라 동적으로 확장되어 기록 목록 길이(History List Length)의 누적을 방지합니다. innodb_purge_threads
파라미터는 이전 버전처럼 고정된 값 1로 설정되는 대신 MySQL 8.4용 RDS에서 기본적으로 LEAST({DBInstanceVCPU/2}, 4)
로 설정됩니다. 특정 애플리케이션 워크로드에서 최적의 성능을 위해 InnoDB Purge 스레드를 미세 조정하는 방법에 대해 자세히 알아보려면 이 주제에 대한 포괄적인 블로그 게시물을 검토하세요.
결론
이 게시물에서는 MySQL 커뮤니티의 새로운 버전 관리 모델인 MySQL 8.4 LTS 개선 사항과 MySQL 8.4용 Amazon RDS에 도입된 변경 사항에 대해 논의했습니다. 또한 Amazon RDS 블루/그린 배포를 사용하여 가동 중지 시간을 최소화하면서 Amazon RDS for MySQL 8.4로 업그레이드하는 방법도 설명했습니다. Amazon RDS for MySQL 8.4 LTS 릴리즈의 새로운 기능과 워크로드 성능 향상을 사용해 보시기 바랍니다.