RDS-multi AZ/RR 구성 실습

사전구성

접속툴 : mysql workbench ,aws 계정

1. 서브넷 그룹 생성

   Multi-AZ : 각 zone이 전용선으로 연결되어 있어 네트워크 성능의 신뢰가 보장되어 메인 인스턴스에 적용한 데이터가 바로 동기화된다.(RDS의 HA를 위한 방법) → active-standby가 한쌍인 사이클을 가짐

   • multi az 를 활성화 하기 앞서 서브넷 그룹의 해당 가용영역을 지정

     

     >> 이름 및 vpc선택후 본인의 DB가 생성될 환경의 서브넷을 지정

   • 생성 확인

     

2. DB 생성
   • aws console → RDS → 생성

     

   • 엔진 선택

     

   • 버전 및 사용자의 요구사항의 맞도록

     

   • DB 사용자및 암호생성

     

   • db인스턴스 크기

     

   • multi az 활성화

     

     >> 실제 콘솔상에서는 나타나지 않지만 다른 가용영역에서 대기

   • 연결을 위한 설정진행

     

     >> 퍼블릭 액세스 기능을 활성화 함으로써 원격으로 db접속을 허용함

     

     >> 해당 파라미터 그룹에 맞게끔 설정(log를 확인하고 싶을시 파라미터생성후연동)

     

     >>암호화 및 Performance Insights를 활성화 (성능 개선 도우미 같은경우는 db를 운영하면

     생기는 부하등을 확인하기 위함)

     >> 기타 세부사항은 선택적으로 하면된다.

   • 추가적인 부분

     qurey문을 사용할시에 해당 query문을 확인하기 위해 general 로그를 파라미터 그룹에 생성

     

     >> db엔진에 맞게끔 설정

     

     

   • DB 생성

     multi -AZ 로 생성된 DB는 active db만 나타나며 실제 standby 인스턴스는 대기 상태로

     다른 가용영역에 나타나 있다.

     

     >> multi az 가 활성화가 되어있는지만 알수있다.

   • 접속 테스트

     

     >> 해당 DB의 엔드포인트를 사용하여 접속

     

   • 로그 확인을 위한 파라미터 편집

     long_query_time = 2 (2초 사용자 편의) - 안해도됨

     general_log = 1 ( true)

     slow_query_log =1 (true)

     log_output = file,table,none (선택)

     

     >> 쿼리시 해당 시점의 시간으로 로그생성

     

     

     >> 동일하게 실시간으로 해당 DB의 로그가 남는것을 확인할수있다.

3. multi -AZ 테스트

   aurora와 달리 RDS는 인스턴스를 지우면 failover 되는 것 이 아니다.

   

   >> RDS multi-AZ failover

   

   >> failover테스트가 동작했을시 이벤트로그상에서 대략 30~40초가량이 소요됨을확인

   >> 계획 되거나 계획되지 않은 중단이 발생시 자동으로 가용영역에 있는 예비 복제본으로 전환된다.(시간은 일반적으로 60~120초소요 → 규모에 따라 상이함)

   

   >> 다음과 같은경우에 failover가 이뤄진다.

   

   >> 가용 영역이 변경됨을 확인했다(자동으로 동작 하는 것은 테스트 상 진행이 불가 하여 수동으

   로 확인 결과 정상 작동임을 확인)

   

   >> 데이터 동기화 확인

   >> 다만 master 에서 만 모든 작업을 처리하게 되므로 DB의 부하를 고려 해야 할 수 있다.

   >> aurora는 읽기 복제 본 을 가지고 failover 처리(이점 : 항상 active-active 로 동작하기에 분산

   이 가능하여 cluster DB구성으로 모든 DB가 cluster volume 가르키고 있어 지연 시간도 최소화 할 수 있습니다. 비용만 감안한다면 훨씬 좋다고 생각된다..)

4. Read Replica테스트

   multi-AZ : 동기식 복제 active의 db의 정보의 일어난 작업 이후 뒷 단 slave쪽 까지

   동기화 작업이 이루어진 후 정합성 이 완료 되는 방식 → 고가 용 성

   read Replica : 비동기 식 복제 master의 정보 만 가지고 read db 정보까지는 작업을 처리 하지 않는 상태 → 분산 하여 master의 정보를 읽어 들이는 역할

   • 기본 master db 생성 → 읽기 복제 본 생성

     

     

     

     >> 복제 본 생성 소요 시간은 약 3 분 가량 소요된다. (복제본 생성과 동시에 원본 스냅샷을 가지고 동일한 스펙으로 생성)

     >> 완벽하게 완료되기까지는 10분 의 시간이 소요된다.(slave 에서 의 작업)

   • read replica 생성 과정
     1. 복제본 생성시 RDS의 원본 DB인스턴스의 스냅샷을 캡처하여 복제시작
     2. DB 스냅샷 캡처기간동안 원본 DB 인스턴스에서 짧은 I/O발생 → 1분정도
     3. 위의 경우를 방지하고자 원본 DB인스턴스를 다중 AZ로 한다→ 보조 인스턴스에서 스냅샷을 생성하기 때문.
     4. 다수의 복제본이 하나의 원본을 가지고 병렬 작업시 → 첫번째 생성시에만 스냅샷캡처
   • replica 생성시 고려 사항
     1. 백업 보존 기간을 0이 아닌 다른 값으로 설정하여 원본 DB 자동백업 활성화
     2. 자동 백업은 mysql 5.6이상을 실행하는 복제 본에서만 지원
   • slave로 wirte 작업 시

     

   • slave db엔진 변경

     데이터는 동기화가 이루어진 slave지만 db 엔진을 변경했을시는 독립적으로 움직인다.

     

     >> 여기서 master의 엔진을 변경할시 기존 slave엔진들이 변경하려는 버전보다 낮을시 변경

     이 되지 않으므로 해당 slave엔진은 항상 master보다 같거나 높은상태여야 변경이가능.

     

     

     >> slave 인스턴스의 버전 변경확인 나머지는 기존대로 .22를 운영

   • slave 승격

     재해 복구 구현 기본 DB 인스턴스가 실패할 경우 재해 복구 솔루션으로 읽기 전용 복제본을 독립형 인스턴스로 승격할수 있다. → 다만, multi-az나 aurora보단 자동으로 failover처리가 아닌 수동으로 해야하는 불편함이 존재....

     • 승격 이유
       1. DDL 작업실행 (mysql , mariad db 한정)
          • 인덱스 생성 및 리빌드 등의 DDL작업은 시간 및 성능 저하 초래
       2. 샤딩 - 무공유 아키텍처를 구현함으로써 기본적으로 대규모 db 에서 다수의 소규모 db로 분할하는 기술
       3. 장애 복구 실행 - 기본 db인스턴스가 장애가 발생할시 복제본을 데이터 복구 체계로 사용. → 동기식 복제, 장애 자동 감지 및 장애 조치 보완

     

     

     • 승격을 해주면된다.

     

     • 기존 읽기 유형의 인스턴스가 기본 master와 동일한 독립 인스턴스로 승격됌
     • 또한, 스냅샷도 독립적으로 한개가 생성이된다.

     

     • read에서 승격을 실행시킴과 동시에 약간의 재부팅시간이 존재함
     • 데이터 확인

       

       >혹시나 데이터가 날아갔나 하여 확인결과 정상적으로 남아있다.(master에서 작업시의 데이터가 지속적으로 업데이트 되기때문)

     

Uploaded by Notion2Tistory v1.1.0