aurora_binlog_replication_sec_index_parallel_workers

aurora_binlog_replication_sec_index_parallel_workers 파라미터는 Aurora MySQL의 Binlog 복제 작업에서 보조 인덱스(secondary index)의 변경 사항을 적용할 떄 사용할 수 있는 병렬 워커 수를 설정하는 데 사용됩니다.복제 과정에서 Binlog는 소스 DB에서 발생한 변경 사항을 저장하고 이를 복제본으로 전달합니다. 특히 보조 인덱스가 포함된 데이터 변경

Overlay Image Overlay Image
« Back to Glossary Index

aurora_binlog_replication_sec_index_parallel_workers 파라미터는 Aurora MySQL의 Binlog 복제 작업에서 보조 인덱스(secondary index)의 변경 사항을 적용할 떄 사용할 수 있는 병렬 워커 수를 설정하는 데 사용됩니다.
복제 과정에서 Binlog는 소스 DB에서 발생한 변경 사항을 저장하고 이를 복제본으로 전달합니다. 특히 보조 인덱스가 포함된 데이터 변경 작업에서는 추가적인 계산이 필요하기 때문에 복제 속도가 느려질 수 있습니다. 이 파라미터는 복제본에서 이러한 작업을 병렬로 처리하도록 설정하여 성능을 개선합니다.
aurora_binlog_replication_sec_index_parallel_workers 값을 적절히 조정하면, 인덱스 관련 작업을 복수의 워커 스레드가 동시에 처리하도록 하여 복제 속도를 높이고 지연을 줄일 수 있습니다. 즉, 이 파라미터는 단일 스레드로 처리되던 인덱스 업데이트를 병렬화하여 복제 성능 최적화를 돕는 기능이라고 할 수 있습니다.

aurora_binlog_replication_sec_index_parallel_workers 파라미터란?

  • Aurora MySQL 3.06.0에 새로 추가된 파라미터입니다.
  • 바이너리 로그 복제 과정중에 활용됩니다. 또한, SQL을 적용하는 경우에 활용되는 기능인지라, Replication Source로 사용될 때가 아닌, Replication Target (=Slave)으로 사용되는 경우에만 활용되게 됩니다. 실질적으로 Cross-Region Replication 기능을 사용할 때에나 사용된다고 보시면 됩니다.
  • 기본 MySQL 기능 중 병렬 복제 기능을 활용하는 기능입니다. AWS Aurora의 경우 3.04버전 이후에는 병렬 Replication이 기본적으로 켜있으며, 이 때 Logical_Clock 기반으로 동작하고, 4개의 병렬 스레드를 사용합니다. (=기본값. 변경 가능)

동작 과정을 요약해보면,

  1. Aurora MySQL 3.06.0 이상을 사용하며,
  2. Cross-Region Replication 기능등을 사용하여, 바이너리 로그를 이용해 DB 복제를 할 때에,
  3. Binarylog Replication Target으로 사용되는 Aurora MySQL Cluster에는 병렬로 SQL Applier Thread를 띄울 수 있는데,
  4. 버전이 3.04보다 높으므로, 파라미터들을 기본값으로 그냥 놔두기만 해도, Logical_Clock 기반의 / 4 Thread / Parallel SQL Applier Thread (replica_parallel_workers)를 사용하게 됩니다.
  5. 여기에 더해 aurora_binlog_replication_sec_index_parallel_workers 설정을 2이상으로 설정하면 (기본값=0=비활성화)
  6. 복수개의 SQL Applier Thread가 세컨더리 인덱스의 변경 사항 적용에 활용됩니다. 당연히, SQL Applier Thread가 4개라면, 최대 4개까지만 이 작업에 활용할 수 있습니다.

추가 정보

이 기능은, 기본 MySQL에는 아직 존재하지 않는, Aurora MySQL 전용의 기능입니다.

자세한 내용은 Aurora MySQL의 이진수 로그 복제 최적화 페이지 참고바랍니다.

레퍼런스 매뉴얼 상, 보조 인덱스(Secondary Index)가 존재하는 큰 테이블에서 사용된다고 합니다. ‘큰 테이블’이란 것이 구체적으로 어느 정도 규모를 큰 테이블이라 부르고 있는지는 추가적인 테스트가 필요할 것 같습니다.

설정 방법

RDS의 파라미터 그룹에서 aurora_binlog_replication_sec_index_parallel_workers 설정을 검색하여 값을 변경하면 됩니다.

aurora_binlog_replication_sec_index_parallel_workers 값을 aws 관리 콘솔에서 확인하는 장면 스크린샷

해당 파라메터는 DB Cluster 유형의 파라미터입니다.

0은 비활성화 이며, 1은 1개 쓰레드를 사용하겠다는 것이니, 2 이상의 값으로 설정하면 되겠습니다.

활용 시나리오

  • 대용량 변경 트랜잭션이 빈번한 환경: 대규모 업데이트, 삽입, 삭제 작업이 지속적으로 일어나는 OLTP 환경에서는 인덱스 업데이트 부하가 상당히 발생합니다. 이때 워커 스레드를 늘려서 병렬 작업을 수행하면 Replica에 대한 변경 적용 속도가 향상되고, 복제 지연 시간(replica lag)을 줄일 수 있습니다.
  • 다수의 Secondary Index를 가진 테이블: 인덱스가 여러 개인 테이블은 단순 PK 인덱스 업데이트보다 추가 작업이 많습니다. 병렬 워커를 통해 인덱스 업데이트를 효율적으로 처리하면 전체 복제 성능에 기여할 수 있습니다.

주의사항 및 튜닝 포인트

  • 너무 많은 워커 스레드 할당의 부작용: 워커 스레드를 과도하게 늘리면 오히려 CPU 오버헤드 증가나 스레드 컨텍스트 스위칭 비용 증가로 인해 성능 하락이 발생할 수 있습니다. 적정 워커 수를 찾기 위해서는 워크로드 특성, CPU 리소스, 디스크 I/O 성능을 종합적으로 고려해야 합니다.
  • 인덱스 구조 최적화 병행: 단순히 파라미터를 조정하는 것만으로는 한계가 있습니다. Secondary Index를 최소화하거나 필요한 인덱스만 유지하는 등의 스키마 개선, 그리고 적절한 쿼리 튜닝을 병행한다면 더욱 효율적인 복제 성능 확보가 가능합니다.

정리

aurora_binlog_replication_sec_index_parallel_workers 파라미터는 Aurora MySQL이 Binlog 기반 복제를 수행할 때, 세컨더리 인덱스 업데이트 작업을 병렬화하여 복제 성능을 향상시키는 역할을 합니다.
적절히 설정하면 복제 지연을 줄이고 전체 시스템 처리량을 높일 수 있으나, 적정 값을 찾기 위해서는 모니터링과 튜닝이 필수적입니다. 이를 통해 Aurora 환경에서 복제 성능을 최적화하고 안정적인 데이터 전파를 보장할 수 있을 것입니다.

« Back to Glossary Index