Last Updated on 12월 21, 2022 by Jade(정현호)
안녕하세요
AWS RDS for MySQL 관한 포스팅 으로 아래 포스팅에서 이어지는 연재 포스팅 입니다.
1. 파라미터 그룹
이전 포스팅에서 생성한 MySQL RDS 인스턴스의 파라미터 변경을 진행하도록 하겠습니다. 파라미터 그룹을 생성 후 적용시 한번의 재기동이 필요함으로 초기에 적용하거나 미리 파라미터 그룹을 생성 해두고 인스턴스 생성시 지정하는 형태가 좋습니다.
그렇기 때문에 보통은 인스턴스나 ReplicaSet 단위로 만들어서 사용이 됩니다
1-1 파라미터 그룹 생성
파라미터 그룹 -> 파라미터 그룹 생성 을 선택 합니다.
1-2 그룹 생성
그룹 이름 과 설명을 입력 후 하단의 생성을 선택 합니다. 파라미터명은 포스팅에서의 예시 입니다.
정상적으로 생성 되었다면 아래와 같이 새로 생성된 파라미터 그룹이 확인 됩니다.
1-3 인스턴스 수정
데이터베이스 -> RDS 인스턴스를 선택 -> 수정 을 선택합니다.
1-4 파라미터 그룹 선택
추가 구성 -> DB 파라미터 그룹 에서 위에서 생성한 파라미터 그룹을 선택 후 하단의 계속 을 선택 합니다.
1-5 적용
수정사항에 대한 반영 시점을 선택 해야 합니다. 다음 유지 관리 때 적용 할지, 즉시 적용 할지 선택할 수 있으며 포스팅에서는 즉시 적용으로 적용 하였습니다.
DB 인스턴스 수정 을 하게 되면 수분 간 아래 처럼 상태가 수정 중으로 확인 됩니다.
인스턴스의 상태가 사용 가능 으로 확인 된다면 구성 탭에서 파라미터 그룹 을 확인 시 "재시작 보류 중" 으로 확인된다면 인스턴스 재시작을 진행하면 됩니다.
1-6 인스턴스 재부팅
인스턴스 선택 -> 작업 -> 재부팅 메뉴를 선택해 RDS 인스턴스 재시작을 합니다. 재시작 중에는 당현히 기존 세션의 접속은 끊기게 되어 다시 재 접속이 필요 합니다.
확인 을 선택해 재부팅을 진행 합니다.
Multi-AZ 를 사용 중이라면 아래와 같이 장애조치 재시작을 사용할 수 있습니다.
그럼 인스턴스 failover 가 진행되면서 세션의 접속 불가 시간이 조금 더 줄어들게 됩니다.
3:44:29 AM UTC Multi-AZ instance failover started. 2022, 3:44:40 AM UTC DB instance restarted 2022, 3:45:04 AM UTC The user requested a failover of the DB instance. 2022, 3:45:04 AM UTC Multi-AZ instance failover completed
1-7 파리미터 수정 진행
인스턴스 재부팅 후 구성 탭의 파라미터 그룹을 확인 하면 아래와 같이 상태가 동기화 로 표기되며 적용이 된 상태로 확인 가능하며, 파라미터를 변경 하기 위해서 그룹을 선택(클릭) 합니다.
1-8 파라미터 편집
포스팅에서는 예시로 max_connections 파라미터를 변경 하도록 하겠습니다 파라미터 검색 후 파라미터 편집 을 선택 합니다.
원하는 값을 지정 후 "변경 사항 저정" 을 클릭하여 저장을 완료 합니다. max_connections 파라미터는 적용 유형이 dynamic 임으로 재기동 없이 바로 반영 됩니다.
새로 접속하면 바로 반영되어있는것을 확이 할 수 있습니다.
mysql> show variables like '%max_connections%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 66 | +-----------------+-------+ 1 row in set (0.01 sec) mysql> exit Bye User$ mysql -u admin -p -h rds1.master.rds.amazonaws.com Enter password: <... 중략 ...> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show variables like '%max_connections%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 1000 | +-----------------+-------+ 1 row in set (0.00 sec)
위에서는 파라미터 타입이 dynamic 임으로 바로 적용 되지만 아래와 같이 적용 유형이 static 이라면 인스턴스 재시작이 필요 합니다.
처음 생성 또는 기본 생성 시 지정되어 있는 Default 파라미터 에서는 수정이 불가능 함으로 별도로 생성 을 진행하여 적용한 것입니다(위의 단계에서)
2. 읽기 전용 복제본
Amazon RDS 의 MySQL 엔진의 기본 복제 기능을 사용하여 원본 DB 인스턴스의 읽기 전용 복제본이라고 하는 특수한 유형의 DB 인스턴스를 생성 할 수 있습니다. 기본 DB 인스턴스에 적용된 변경 사항에 대해서 읽기 전용 복제본에는 비동기식으로 복제가 수행됩니다. 애플리케이션에서 읽기 쿼리를 읽기 전용 복제본 인스턴스를 활용하여 기본 DB 인스턴스의 로드(부하)를 줄일 수 있습니다.
[AWS Read Replica]
읽기 전용 복제본을 생성하면 먼저 기존 DB 인스턴스를 원본으로 지정합니다. 그러면 Amazon RDS가 원본 인스턴스의 스냅샷을 생성한 후 이 스냅샷에서 읽기 전용 인스턴스를 생성합니다.
읽기 복제본을 생성하기 위해서는 Master 인스턴스의 백업 활성화가 필수 입니다. 읽기 복제본을 위해서 백업을 활성화 하는 과정에서 마스터 인스턴스의 재시작은 한번 수행 됩니다. 그러므로 마스터 인스턴스는 가급적 생성시 또는 생성 직후에 백업을 활성화 해놓는 것이 중요 합니다.
참고로 반대로 백업 활성화 -> 비활성화 역시도 RDS 인스턴스의 재시작은 수행됩니다.
3. 읽기 복제본 생성
읽기 복제본을 생성 하기 위해서는 아래와 같은 절차로 진행을 하게 됩니다.
3-1 읽기 복제본 생성 선택
RDS -> 데이터베이스 -> 복제할 (Source) RDS 선택 -> 작업 -> 읽기 복제본 생성 을 선택 합니다.
3-2 읽기 복제본 이름 지정
3-3 인스턴스 크기 스토리지 유형
DB 인스턴스 의 크기(종류) 와 스토리지 유형 과 설정을 합니다 포스팅에서는 프리티어 등급의 db.t2.micro 로 선택 하였습니다.
3-4 가용영역 선택 및 네트워크 선택
가용 영역(다중 AZ) 과 네트워크 및 퍼브릭 엑세스 가능 여부를 선택 합니다.
3-5 데이터베이스 인증
포스팅에서는 암호 인증 을 선택하였습니다.
3-6 추가 구성 및 생성
추가 구성 설정을 완료 후 하단의 "Create read replica" 를 클릭 합니다
3-7 생성 과정
생성을 시작하면 원본(Source,Master) 는 수정중 으로 나오게 되며 Read Replica 는 생성중으로 처음에는 표기 됩니다 원본 인스턴스의 스냅샷을 생성한 후 이 스냅샷을 통해서 읽기 복제본을 생성하기 때문에 이 진행과정에서 원본 인스턴스에 수정중 으로 표기 됩니다
• 마스터 인스턴스의 "수정 중" 에서 진행되는 로그 내역
그 다음 과정으로 진행되면 원본 인스턴스는 사용 가능 으로 표기 되고 읽기 복제본은 수정 중으로 표기 됩니다
생성이 완료 되면 생성시 선택한 설정에 따라 다른 AZ 에 생성 되며 상태는 사용 가능으로 확인 됩니다. 또한 역할에서 Master 는 기본 으로 표시되며, Replica는 복제본 이라고 표현 됩니다.
생성이 완료 된 후 읽기 복제본(Read Replica) 에도 접속을 위한 엔드포인트 주소가 확인 되며 해당 주소를 통해 접속 가능 합니다. 
접속 후 파라미터를 확인 해보면 아래와 같이 read_only=ON 상태 인것도 확인 할 수 있습니다.
User$ mysqlsh -u admin -p -h rds2.replication_node.rds.amazonaws.com Please provide the password for 'admin@rds2.replication_node.rds.amazonaws.com': ************* MySQL Shell 8.0.23 Copyright (c) 2016, 2021, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type '\help' or '\?' for help; '\quit' to exit. Creating a session to 'admin@rds2.replication_node.rds.amazonaws.com' Fetching schema names for autocompletion... Press ^C to stop. Your MySQL connection id is 16 Server version: 8.0.23 Source distribution No default schema selected; type \use <schema> to set one. MySQL rds2.replication_node.rds.amazonaws.com:3306 ssl JS > \sql Switching to SQL mode... Commands end with ; MySQL rds2.replication_node.rds.amazonaws.com:3306 ssl SQL > show variables like '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | ON | | super_read_only | OFF | | transaction_read_only | OFF | | tx_read_only | OFF | +-----------------------+-------+ 5 rows in set (0.0026 sec) MySQL rds2.replication_node.rds.amazonaws.com:3306 ssl SQL >
4. 승격
복제된 Replica 인스턴스 를 기본 인스턴스(Source/Master) 로 분리-> 변경 할 수 있으며 승격 기능을 이용하게 됩니다
Replica Instance 를 Master 로 승격 시키면서 Master <-> Replica 의 Switch 형태가 아닌 Master 의 읽기 복제본에서 별도의 쓰기 가능한 Master(Standalone) 인스턴스로의 변경을 의미 합니다. 그러므로 읽기 복제본 인스턴스에 쓰기 가능한 Master 형태의 인스턴스로 사용하기 위해서 승격을 이용할 수 있습니다.
4-1 승격 메뉴 실행
RDS -> 데이터베이스 -> 인스턴스 선택 -> 메뉴 작업 -> 승격 을 선택 합니다.
4-2 기본 설정
기본 설정을 해야하며, 해당 인스턴스가 프로모션 이후 단독으로 사용이 확실하고 백업이 불필요 하다면 자동 백업 활성화를 사용하지 않아도 됩니다.
다만 해당 인스턴스가 백업의 필요성도 있고, 추후 Read Replica 구 추가 될 예정이라면 이 단계에서 백업을 활성화 하는 것이 좋습니다.
여러번 언급된 내용 처럼 백업 활성화시(Read Replica 생성시에도 백업 필요) 1번의 재시작이 있기 때문 입니다.
설정이 완료 되었다면 하단의 계속 버튼을 선택 합니다.
4-3 실행
마지막으로 확인이 모두 되었다면 "읽기 전용 복제본 승력" 을 선택 하여 진행을 완료 합니다
4-4 변경
승격을 실행하면 아래와 같이 인스턴스 상태는 수분 간 수정 중 으로 표시 되면서 내부적으로 작업이 진행 됩니다.
시간이 조금 지나면 재부팅 중으로 확인 됩니다.
완료가 되면 상태는 사용 가능 으로 확인 되며, 역할도 기본/복제본 에서 인스턴스/인스턴스 로 변경 된 것을 확인 할 수 있습니다.
추가로 백업 활성화 하고 프로모션(승격)을 하게 되면 승격이 완료된 다음에 바로 백업이 진행이 되게 됩니다.
7:23:52 AM UTC Promoted Read Replica to a stand-alone database instance 7:24:01 AM UTC DB instance shutdown 7:24:13 AM UTC DB instance restarted 7:24:49 AM UTC Backing up DB instance <---- 백업 실행!! 7:31:54 AM UTC Finished DB Instance backup <---- 백업 종료!!
백업이 수행되는 과정에서 재시작이나 다운이 발생되지 않기 때문에 DB에 접속 과 업무진행은 가능 합니다.
다만 그 뒤에 RDS의 추가적인 변경 작업이 예정 되어 있다면 RDS 상태는 계속 수정중 으로 되어 있기 때문에 용량이 큰 DB 라면 TASK 간의 시간 산정이나 배분에 관련해서 확인을 해야할 부분이긴 합니다.
다음 포스팅에서는 Multi-AZ 와 업그레이드 에 대해서 확인 해보도록 하겠습니다.
다음 이어지는 글
연관된 다른 글
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