BESPIN Tech Blog
  • Home
  • Tech
    • CSP

      AWS

      GCP

      NCP

      Cloud

      Migration

      LZ, Control Tower

      Backup

      Monitoring

      Container

      Infra

      OS

      Middleware

      Data

      RDB

      Big Data Platform

      Application

      CI/CD

      BESPICK 구독하기 ㅣ 1668-1280

  • Trend
  • IT
최신 리포트 다운로드 지금 바로 문의하기
BESPIN Tech Blog
  • Home
  • Tech
    • CSP

      AWS

      GCP

      NCP

      Cloud

      Migration

      LZ, Control Tower

      Backup

      Monitoring

      Container

      Infra

      OS

      Middleware

      Data

      RDB

      Big Data Platform

      Application

      CI/CD

      BESPICK 구독하기 ㅣ 1668-1280

  • Trend
  • IT
최신 리포트 다운로드 지금 바로 문의하기
BESPIN Tech Blog
BESPIN Tech Blog
  • Tech
    • CSP
      • AWS
      • GCP
      • NCP
    • Cloud
      • Migration
      • LZ, Control Tower
      • Backup
      • Monitoring
      • Container
    • Infra
      • OS
      • Middleware
    • Data
      • RDB
      • Big Data Platform
    • Application
      • CI/CD
  • Trend
  • IT
  • Contact US
TECHCSPRDBAWSData

DB Cluster parameter group 과 DB Instance parameter group 의 차이점 및 활용

by namryong.kim 2022년 06월 20일
2022년 06월 20일
20

서론

안녕하세요 베스핀글로벌입니다 🙂
오늘 전해 드릴 기술 내용은 많은 분들께서 관심 있어 하실 Aurora Parameter에 관한 내용입니다!


많은 고객님들께서 aurora cluster parameter group 과 instance parameter group의 차이가 정확히 무엇인지 궁금해 하십니다.



두 parameter group 에 동일한 parameter도 존재한다면 어떤 값이 우선적으로 적용이 되는지 헷갈리는 점이 있기 때문에 이번 글을 준비해 보았습니다..


Cluster parameter vs Instance parameter

DB Cluster parameter group

: 클러스터에 포함된 모든 Instance에 적용 됨


DB Instance parameter group

: 개별 Instance에 적용되며 이 파라미터는 동일한 DB 클러스터에 있는 db 인스턴스 전반에 걸쳐 변경할 수 있는 속성과 관련 있음


즉, DB cluster parameter group 은 클러스터 수준 의 파라미터에 사용되며 클러스터의 모든 인스턴스에 적용됩니다.

반면, Instance parameter group은 인스턴스 수준 의 파라미터에 사용되며 메모리 버퍼 크기와 같이 DB 클러스터 내의 DB 인스턴스간에 다른 속성을 설정할 때 사용합니다.

cluster parameter vs instance parameter


만약, Aurora 클러스터 내에서 인스턴스들 마다 다른 인스턴스 크기를 가진다고 가정합니다. ( 예를 들어, 마스터는 db.m5.4xlarge, 나머지 읽기 전용 복제본들은 db.m5.large)

이처럼 마스터와, 다른 나머지 복제본들과 구성을 다르게 설정하셔야 할 때 db instance parameter group 의 파라미터를 이용하여 다르게 설정해주실 수 있습니다.

물론 이런 설정은 모든 인스턴스에 공통된 값을 적용하는 db cluster parameter group 으로는 어려울 것입니다.


두 parameter group 사용법의 차이를 간단히 다시 요약하자면,

파라미터가 클러스터 내의 모든 인스턴스 (예 : 시간대)에서 동일해야하는 경우 Cluster parameter group을 사용하고, 그렇지 않은 경우 Instance parameter group을 사용합니다.



DB Cluster parameter group 과 DB Instance parameter group 중 우선순위

서론

DB Cluster Parameter group 과 Instance parameter group의 변수를 보면 max_connections 과 같이 동일한 변수들을 확인할 수 있습니다.

이런 경우, 순서에 따라 적용되는지 혹은 어떤 값의 우선순위가 높은지 의문이 들 수 있습니다.

결론적으로,  **instance parameter group**의 설정 값이 DB Cluster parameter group 값보다 우선순위가 높습니다.

아래 테스트를 통해 증명해보고자 합니다.


Test

Test 1

클러스터에 설정/적용할 값을 선택할 때 Aurora가 어떤 우선 순위를 따르는지 알고 싶습니다.

첫 번째 테스트는 Cluster parameter group 의 값만 변경하고, Instance parameter group은 기본 값을 유지할 때에 관한 테스트입니다.

다음은 수행한 테스트의 예와 각 테스트의 결과입니다.

  1. 클러스터 파라미터 그룹 내에서 파라미터 값을 수정하지만 DB 파라미터 그룹값이 기본값인 경우 클러스터 파라미터 그룹의 변경된 파라미터 값이 클러스터에 우선합니다.
  2. DB 클러스터 파라미터 그룹에서 max_connections = 70 으로 설정했습니다.
  3. DB 파라미터 그룹에서 max_connections를 수정하지 않았습니다(기본값으로 두었습니다).
  4. 클러스터에서 어떤 매개변수를 사용하고 있는지 확인하기 위해 “show variables like “‘max_connections’;”를 실행했습니다.


사전 설정

  • Aurora 생성
  • name : hanna-pm-test
  • 엔진 : Aurora MySQL
  • Cluster parameter group과 DB parameter group 모두 기본(default)으로 생성 됨.
Cluster parameter group 확인하기
DB parameter group 확인하기

Test.1

  1. default 값으로 설정되어 있는 max_connections 값 확인
    1. DB Instance 접속 bastion host에서 Aurora writer 인스턴스에 접속하였다.
      mysql -h hanna-parameter-aurora-instance-1.cslhbb9jqvu2.ap-northeast-2.rds.amazonaws.com -u admin -P 3306 -p
    2. 콘솔에서 확인하기
기본값으로 설정되어 있다

2. 명령어를 통해 ‘max_connections’ 값 확인하기

MySQL [(none)]> show variables like ‘max_connections’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 45 |
+—————–+——-+
1 row in set (0.00 sec)

‼️참고
db.t3.small 의 기본 max_connections 값은 45입니다. 정상적으로 적용되어 있는 것을 확인할 수 있습니다.

3. Cluster parameter group을 생성 후 적용 기본 파라미터 그룹은 수정할 수 없으므로 사용자 지정 파라미터 그룹을 생성하고 파라미터를 변경한 다음 새 파라미터 그룹을 사용하도록 인스턴스를 수정해야 합니다.

만약 max_connection 값을 수정하기 위해 기본 파라미터 그룹에서 값을 수정하면 아래와 같은 에러가 발생합니다.

cluster parameter group 생성

  1. max_connection 값 수정
    값을 45 → 70 으로 변경하였다.
    1. aurora에 적용
    2. 인스턴스에서 확인
      MySQL [(none)]> show variables like 'max_connections';
      +-----------------+-------+
      | Variable_name | Value | +
      -----------------+-------+
      | max_connections | 45 | +
      -----------------+-------+
      1 row in set (0.00 sec)


      이론상으로라면, 변경이 되어야 하는데, 변경되지 않았습니다.변경되지 않은 이유? 파라미터 그룹을 변경하신 뒤에는 반드시 수동으로 DB 인스턴스를 재시작 해주어야 새로운 파라미터 그룹이 적용됩니다.

      e. 인스턴스 재부팅 후 조회

      MySQL [(none)]> show variables like 'max_connections';
      +-----------------+-------+
      | Variable_name | Value | +
      -----------------+-------+
      | max_connections | 70 | +
      -----------------+-------+
      1 row in set (0.00 sec)

      70 으로 정상적으로 변경 된 것을 확인할 수 있습니다.


Test.1 결론

  • Cluster Parameter Group 의 값을 변경하여 적용하면, Instance Pararmeter Group 의 default 값 보다 우선순위가 높다.
  • 새로운 Parameter group 을 적용하려면, DB 인스턴스를 수동으로 재부팅 해주어야 한다.

Test. 2

두번째 테스트는 Cluster parameter group 의 값을 기본 값으로 변경한 후, Instance parameter group의 값을 변경했을 시의 테스트입니다.

다음은 수행한 테스트의 예와 각 테스트의 결과입니다.

  1. 클러스터 파라미터 그룹을 기본 값으로 변경합니다. (다시 max_connections 값을 45로 변경)
  2. 이 후, DB 파라미터 그룹을 생성하여 max_connections 값을 80 으로 변경했습니다
  3. 클러스터 파라미터 그룹 내에서 이 파라미터 값을 기본값으로 유지하는 경우 DB 파라미터 그룹의 사용자 정의 설정 파라미터 값이 클러스터에 우선합니다.

Test.2

  1. 클러스터 파라미터 그룹을 기본 값으로 변경
  2. db instance parameter group 생성 후 적용
    1. 인스턴스 파라미터 그룹 생성
  • name : hanna-instance-pg
  • 그룹 이름 : DB Parameter Group

3. 인스턴스에 적용

4. 재부팅 후 mysql 에서 확인
MySQL [(none)]> show variables like 'max_connections';

+-----------------+-------+

| Variable_name | Value |

+-----------------+-------+

| max_connections | 80 |

+-----------------+-------+

1 row in set (0.00 sec)

DB Parameter group 의 값인 80 으로 변경된 것을 확인하였다.

Test.2 결론

  • Cluster Parameter Group 과 DB Instance Group 모두 기본 파라미터 그룹(default) 보다 변경한 사용자 지정 파라미터 그룹의 값이 우선적으로 적용된다.

Test.3

세 번째 테스트는 Cluster parameter group 의 값을 70 으로 변경한 후, Instance parameter group의 값 역시 변경했을 때의 테스트입니다.

다음은 수행한 테스트의 예와 각 테스트의 결과입니다.

  1. DB 클러스터 파라미터 그룹에서 max_connections = 70(다시)으로 설정했습니다.
  2. DB 파라미터 그룹을 사용하여 max_connections 값을 80 으로 변경했습니다
  3. 클러스터 파라미터 그룹 내에서 이 파라미터 값을 기본값으로 유지하는 경우 DB 파라미터 그룹의 사용자 정의 설정 파라미터 값이 클러스터에 우선합니다.

Test.3

  1. Cluster Parameter Group으로 적용 후 다시 cluster parameter의 max_connections 값을 변경함 -> 90 으로 설정
  2. mysql 에서 확인
    MySQL [(none)]> show variables like 'max_connections';
    +-----------------+-------+
    | Variable_name | Value |
    +-----------------+-------+
    | max_connections | 80 |
    +-----------------+-------+
    1 row in set (0.00 sec)

    Cluster Parameter Group의 값을 90으로 설정해주고 적용하였으나, cluster parameter 값이 반영되지 않음. DB Parameter Group의 값이 적용된 것을 보아, DB Parameter Group의 값이 더 우선순위가 높은 것을 확인할 수 있음.
  3. DB instance parameter 값을 변경 DB Parameter Group 의 값을 80 → 100 으로 변경
  4. 재부팅 후, mysql 에서 확인

    MySQL [(none)]> show variables like 'max_connections';
    +-----------------+-------+
    | Variable_name | Value |
    +-----------------+-------+
    | max_connections | 100 | +
    -----------------+-------+
    1 row in set (0.00 sec)

    Cluster parameter Group의 값이 아닌, DB Parameter Group 의 변경된 값이 정상적으로 적용한 것을 확인할 수 있음.

Test.3 결론

  • Cluster Parameter Group 과 DB Parameter Group 둘 다 기본 그룹이 아니라 사용자 지정 파라미터 그룹을 사용한다면, DB Parameter Group의 값이 우선적으로 적용된다.

결론

“비서버리스 클러스터의 경우 DB 클러스터 파라미터 그룹에서 수정하는 모든 구성 값이 DB 파라미터 그룹의 기본값을 재정의합니다. DB 파라미터 그룹에서 해당 값을 편집하면 해당 값이 DB 클러스터 파라미터 그룹의 설정을 재정의합니다. 수정한 모든 DB 파라미터 설정이 DB 클러스터 파라미터 그룹 값보다 우선합니다. 수정하는 모든 DB 파라미터 설정은 구성 파라미터를 기본값으로 다시 변경하더라도 DB 클러스터 파라미터 그룹 값보다 우선합니다.”

  • DB Cluster parameter group 을 변경하고, DB Parameter group 이 default parameter group인 경우, DB Cluster parameter group의 값이 우선시된다.
  • DB Cluster parameter 와 DB Parameter 중 DB Parameter 값이 더 우선시 된다.

추가적인 문의 사항이나 궁금하신 점은 베스핀글로벌 기술지원 센터를 이용해주시길 바랍니다!!

관련

AuroraRDSParameter

HOT Trend

Recent Posts

  • 딜로이트도, 맥킨지도, 베스핀글로벌도: AI 에이전트로 일 바꾸는 시대

    2025년 07월 04일 클라우드베스핀글로벌clouddata데이터AI인공지능HelpNow AIbespinglobalAI에이전트helpnow업무자동화딜로이트
  • ⚔️데이터센터에서 시작된 전쟁? 요즘 뜨는 AIDC 개념부터 트렌드까지!

    2025년 06월 27일 클라우드clouddata데이터AI데이터센터클라우드 데이터센터bespinglobalAIDCAI 인프라베스핀글로벌
  • 구글부터 엔비디아까지, 빅테크 기업들의 AI 전략 최신본📖

    2025년 06월 20일 cloud베스핀글로벌클라우드data데이터AI구글마이크로소프트엔비디아AI에이전트google I/ONVIDIA GTC 2025Microsoft build 2025
  • AI를 연결한다고? 업계가 주목하는 ‘MCP’ 알아보기🔍

    2025년 06월 13일 베스핀글로벌클라우드cloudAIMCP
  • [WhaTap] RDS Failover/Reboot 관제 2 – RDS Failover

    2025년 05월 30일 RDSRDS FailoverRebootFailoverbespin global

베스핀글로벌은 모든 기업의 AI 혁신을 실현하기 위해, 세상에서 가장 혁신적이고 자동화된 AI 서비스와 솔루션을 만들어갑니다.
상호 : 베스핀글로벌 주식회사 ㅣ 대표자명 : 김써니, 허양호 ㅣ 사업자등록증번호 : 638-87-00223 ㅣ 통신판매번호 : 2019-서울서초-0347 ㅣ 대표전화 : 1668-1280
사업장주소지 : 서울특별시 서초구 강남대로 327, 13,14,15,16층(서초동,대륭서초타워) ㅣ 이메일 : info@bespinglobal.com ㅣ 개인정보 처리방침 ㅣ 개인정보 처리방침 안내

© 2026 BESPIN GLOBAL, All Rights Reserved.

BESPINGLOBAL
패밀리 사이트
China MEA SEA US

BESPIN Tech Blog
  • Home
  • Tech
    • CSP

      AWS

      GCP

      NCP

      Cloud

      Migration

      LZ, Control Tower

      Backup

      Monitoring

      Container

      Infra

      OS

      Middleware

      Data

      RDB

      Big Data Platform

      Application

      CI/CD

      BESPICK 구독하기 ㅣ 1668-1280

  • Trend
  • IT