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 키 쌍 교환을 사용하여 데이터베이스에 연결하는 방법을 보여줍니다.

mysql -h<rds_endpoint> -u<user_name> -p<password> --ssl-mode=DISABLED --get-server-public-key
Bash

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로 수정할 수 있습니다.

ALTER USER 'username'@'hostname' IDENTIFIED WITH caching_sha2_password BY 'password';
Bash

다음 쿼리를 사용하여 mysql_native_password 인증 플러그인이 있는 모든 사용자를 나열할 수 있습니다.

SELECT user, host, plugin FROM mysql.user where plugin='mysql_native_password';
Bash

사용자를 마이그레이션하기 전에 클라이언트 드라이버가 caching_sha2_password 인증 플러그인과 호환되는지 확인하세요.

Non-unique 키 또는 Partial 키를 외래 키로 제한적으로 사용

MySQL 커뮤니티에서는 테이블을 생성하거나 변경하는 동안 Non-unique 또는 Partial 키를 외래 키로 사용하는 기능을 더 이상 사용하지 않으며 향후 버전에서 제거할 예정입니다.
이 전환을 관리하기 위해 MySQL 8.4에는 기본적으로 ON으로 설정되는 restrict_fk_on_non_standard_key라는 새 파라미터가 포함되어 있습니다. 이 설정은 Non-unique 또는 Partial 키를 외래 키로 사용하는 것을 방지합니다. OFF로 설정하면 이전 동작으로 되돌릴 수 있습니다. 그러나 모범 사례에 따라 Unique 키만 외래 키로 사용하도록 스키마를 수정하는 것이 좋습니다.

자동 히스토그램 업데이트 소개

MySQL 8.4에는 쿼리 최적화의 효율성과 정확성을 향상시키기 위해 설계된 자동 히스토그램 업데이트라는 기능이 도입되었습니다. 이전 버전에서는 히스토그램을 업데이트하려면 수동으로 ANALYZE TABLE..UPDATE HISTOGRAM.. 명령이 필요했습니다. MySQL 8.4에는 특정 임계값이 충족되면 호출되는 자동 업데이트가 도입되었습니다. 특정 히스토그램에 대한 자동 업데이트를 활성화하려면 AUTO UPDATE 옵션과 함께 ANALYZE TABLE..UPDATE HISTOGRAM..을 실행하세요.

mysql > analyze table table1 update histogram on col2 with 10 buckets AUTO UPDATE;
*************************** 1. row ***************************
   Table: testdb.table1
      Op: histogram
Msg_type: status
Msg_text: Histogram statistics created for column 'col2'.
1 row in set (0.01 sec)
SQL

히스토그램 자동 업데이트가 활성화되어 있는지 확인하려면 information_schema.column_statistics 테이블의 HISTOGRAM 열을 쿼리하면 됩니다. JSON 출력에서 ‘auto-update’: true 속성을 찾으세요.

mysql> select * from information_schema.column_statistics \G
*************************** 1. row ***************************
SCHEMA_NAME: testdb
 TABLE_NAME: table1
COLUMN_NAME: col2
  HISTOGRAM: {"buckets": [], "data-type": "int", "auto-update": true, "null-values": 0.0, "collation-id": 8, "last-updated": "2024-11-12 01:01:10.234206", "sampling-rate": 1.0, "histogram-type": "singleton", "number-of-buckets-specified": 10}
1 row in set (0.00 sec)
SQL

특히 InnoDB 엔진을 사용하는 테이블의 경우 innodb_stats_auto_recalc 파라미터는 테이블 행의 10% 이상이 수정되면 자동 히스토그램 업데이트를 호출합니다. 이 임계값을 사용하면 지속적인 수동 새로 고침 없이 통계의 관련성이 유지되므로 특히 복잡한 쿼리에서 쿼리 성능을 향상시키는 데 도움이 될 수 있습니다.

자동 히스토그램 재계산은 비동기식이므로 중요한 데이터 변경 후 즉시 발생하지 않을 수 있습니다. 대부분의 경우 지연 시간은 일반적으로 몇 초로 최소화되지만 이를 통해 MySQL은 시스템 성능과 최신 통계 요구 사항의 균형을 맞출 수 있습니다. MySQL 8.4의 자동 히스토그램 업데이트는 쿼리 최적화를 간소화하고 유지 관리 오버헤드를 줄여 보다 일관되고 효율적인 데이터베이스 성능을 제공합니다.

데이터가 자주 변경되거나 상당한 변경이 있는 테이블의 경우 자동 기능을 사용하거나 필요에 따라 재계산 임계값을 조정할 수 있습니다. 자세한 내용은 영구 최적화 프로그램 통계 파라미터 구성을 검토하세요. 또는 히스토그램 업데이트를 정밀하게 제어해야 하는 테이블에 MANUAL UPDATE 옵션을 지정하면 로드가 많은 환경에서 유연성을 제공하여 잦은 재계산으로 인해 성능에 미칠 수 있는 영향을 줄일 수 있습니다.

그룹 복제 플러그인 업데이트

MySQL 8.4에는 일반적으로 분산 시스템에서 지속적인 가용성 또는 내결함성을 구현하는 데 사용되는 그룹 복제 플러그인에 대한 여러 업데이트가 도입되었습니다. 주요 변경 사항 중 일부는 다음과 같습니다.

  • 시스템 변수 기본값 변경group_replication_consistency의 기본값이 이제 BEFORE_ON_PRIMARY_FAILOVER로 설정되어 이전 기본값인 EVENTUAL을 대체합니다. 이는 장애 조치 이벤트 중에 더 엄격한 트랜잭션 일관성을 제공합니다. 또한, 이제 group_replication_exit_state_action의 기본값은 OFFLINE_MODE로 설정되어 READ_ONLY에서 전환되어 노드가 오류 상황을 처리하는 방법을 변경합니다.
  • 버전 간 멤버십 지원 – 8.4 시리즈 내에서 서로 다른 8.4 버전이 있는 서버는 여전히 동일한 복제 그룹에 가입할 수 있으므로 버전 관리가 더욱 유연해집니다.
  • 그룹 복제 상태 변수 도입 – 그룹 복제는 해당 작업에 대한 자세한 인사이트를 제공하기 위해 새로운 상태 변수 세트를 도입했습니다. 이러한 변수는 합의(Consensus) 제안, 인증 가비지 수집, 메시지 전송, 트랜잭션 일관성 등과 같은 다양한 측면에 대한 정보를 제공합니다. 이러한 상태 변수에는 로컬 관찰을 반영하는 구성원 범위가 있으며 그룹 부트스트랩, 멤버 가입, 자동 재가입 또는 서버 다시 시작 시 재설정됩니다. 자세한 내용은 MySQL 참조 매뉴얼을 참조하세요.

이러한 업데이트는 MySQL 그룹 복제를 더욱 강력하게 만들어 버전 관리에 더 나은 일관성 보장과 유연성을 제공합니다.

쿼리 구문, 파라미터 그룹 및 저장 프로시저에서 비포함 용어 제거

MySQL 커뮤니티는 모든 비포괄적 언어를 적극적으로 폐기해 왔습니다. MySQL 8.4부터 커뮤니티는 더 이상 사용되지 않는 복제 관련 SQL 문에 대한 지원을 중단했습니다. 이제 이러한 문을 사용하려고 하면 구문 오류가 발생합니다. 예를 들어 SHOW MASTER STATUS는 이제 SHOW BINARY LOG STATUS이고 SHOW SLAVE STATUS는 이제 SHOW REPLICA STATUS입니다. 더 이상 사용되지 않는 용어가 포함된 저장 프로시저를 검토하고 업데이트하세요. 업그레이드가 실패할 수 있기 때문입니다. 변경된 복제 문 구문의 전체 목록은 MySQL 참조 매뉴얼을 참조할 수 있습니다.

마찬가지로 Amazon RDS는 MySQL 8.4부터 포괄적 언어를 사용하도록 전환했습니다. 예를 들어, 파라미터 이름에서 slave라는 용어는 replica라는 용어로 대체되었습니다. 이 변경 사항은 모든 구성 파라미터 및 시스템 변수로 확장됩니다. 예를 들어, slave_parallel_workers는 이제 replica_parallel_workers입니다. 기존 자동화 스크립트, 모니터링 도구 및 사용자 지정 구성을 새 매개 변수 이름으로 업데이트하는 것이 좋습니다. RDS 사용자 가이드에서 이러한 전환에 대해 자세히 알아볼 수 있습니다.

MySQL용 Amazon RDS 데이터베이스를 MySQL 8.4 LTS로 업그레이드하면 메이저 버전 업그레이드 프로세스에서 모든 RDS 저장 프로시저를 포괄적인 용어로 자동 업데이트합니다. 다음 표에서는 새로운 프로시저 이름과 기존 프로시저 이름을 보여줍니다.

새롭게 포함되는 용어
(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_trackingWRITESETS으로 설정하는 것과 동일합니다. 이 변경은 다중 스레드 복제 시나리오의 성능 최적화를 향상시키는 것을 목표로 합니다.

지금까지 이 게시물에서는 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 1.3 Protocol
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
        
TLS 1.2 Protocol
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-CHACHA20-POLY1305
Bash

지원되는 TLS 버전 및 암호화 제품군과 클라이언트 애플리케이션의 호환성을 확인하는 것이 좋습니다. 이는 원활한 연결을 제공하고 새로운 암호화 라이브러리가 제공하는 향상된 보안을 유지하는 데 중요합니다.

InnoDB_dedicated_server를 기본적으로 활성화되도록 설정

MySQL 8.4부터 Amazon RDS는 기본적으로 innodb_dedicated_server 파라미터를 활성화합니다. 이를 통해 데이터베이스 엔진은 기본 인스턴스를 기반으로 innodb_buffer_pool_sizeinnodb_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_formatROW로 설정하면 읽기 전용 복제본에서 이진 로그를 재생할 때 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 릴리즈의 새로운 기능과 워크로드 성능 향상을 사용해 보시기 바랍니다.

Yujin Cho

Yujin Cho

조유진 테크니컬 어카운트 매니저는 다양한 데이터베이스의 운영과 데이터 분석 경험을 바탕으로 고객이 데이터 기반의 비즈니스 목표를 달성할 수 있도록 고객과 함께 효율적인 아키텍처와 안정적인 운영 환경을 구성하기 위해 노력하고 있습니다.

Lee Youngdong

Lee Youngdong

이영동 클라우드 서포트 엔지니어는 데이터베이스와 데이터 엔지니어링 경험을 기반으로, Amazon Database 서비스에 대한 고객사의 기술 문의 및 이슈를 분석하여 데이터베이스가 안정적으로 운영될 수 있도록 노력하고 있습니다.