DB replication

 

 

사용이유

DataBase 안정성을 위해 사용됩니다 리플리카 서버는 아주 약간의 딜레이가 있지만 거의 실시간으로 마스터 서버와 동일한 데이터를 가지고 있기 때문에 장애 복구 시 데이터 소실이 최소화됩니다.

 

특징

리플리카 서버는 마스터 서버로 승격이 가능하기에 마스터 서버로 승격시켜 기존 마스터 서버를 대체하는 방식으로 복구가 진행됩니다

복제서버인 리플리카는 기본적으로 읽기 전용입니다

마스터 서버는 SQl 명령을 수신하면 그 SQL 명령을 리플리카 서버에도 똑같이 보냅니다 그러면 마스터 서버와 리플리카 서버의 데이터가 동일한 상태로 유지합니다

MySQL의 Replication은 기본적으로 비동기 복제 방식을 사용하고 있습니다. Master 노드에서 변경되는 데이터에 대한 이력을 로그에 기록하면 Relication Master Thread가 비동기적으로 이를 읽어서 Slave쪽으로 전송합니다.

 

 

장점

• Replication을 구성하면 N개의 Slave를 가질 수 있기 때문에 Read에 대한 부하가 그만큼 분산 됩니다. 마스터 DB에서는 쓰기 작업을 처리함으로써 시스템의 확장성이 향상 된다(대게 read 작업은 자원을 많이 소비 합니다.)
• 복제본을 이용하여 사용자들에게 더욱 가까운 곳에 위치시킴으로써 빠른 응답 속도를 제공할 수 있다
• Master의 내용을 복제하기 때문에 데이터 베이스를 지워 먹는다고 하더라도 Slave 중 하나를 Master로 활용하면 되기 때문에 데이터를 백업하는 용도로도 사용할 수 있습니다.

 

실습

실습을 직접 진행해보도록 하겠습니다.

 AWS를 통해 구현해보도록 하겠습니다. IAM 사용자로 접속하여 region은 서울로 설정합니다 RDS에서 master DB를 만들어보겠습니다

표준생성, MariaDB, 프리티어,버스터블 클래스, 퍼블릭 액세스 가능을 체크하고 나머지는 모두 기본 값으로 설정하겠습니다.

 

h 뒤에 master db의 엔드포인트를 복사붙여넣기 하여 접속하면 됩니다.

접속이 안되는 경우가 생기는데 그때는 해당 리전 EC2 보안그룹에 들어가

IPv4와 IPv6 모두를 포함하도록 인바운드 규칙을 설정해주시면 접속이 될 겁니다.

 

그 뒤 masterDB를 클릭하고 복사본을 만들기를 해보겠습니다.

 

리전은 singapore로 하였습니다. 

 

복제본 생성이 완료되었습니다. 

아까와 마찬가지로 복사본의 엔드포인트를 터미널 명령어에 붙여넣기 하여 접속이 되는지 확인합니다. 안된다면 아까처럼 인바운드 규칙을 수정해주시면 됩니다 

Master DB에 접속하여 DB를 하나 생성하도록 하겠습니다

 

그리고 복사본 DB에 접속하여 동기화가 잘 되었는지 확인하도록 SHOW DATABASES;를 하도록 하겠습니다

동기화가 잘 되었습니다.

아까 복사본 DB는 읽기만을 위한 DB로 설정되어있는게 맞는지 확인하기 위해 CREATE 명령어를 실행해보겠습니다

읽기만 가능하다고 ERROR 가 발생합니다

 

 

 

 

후기

제작한 웹페이지에 대해 많이 생각해보게 되었다. 물론 처음이라 그렇겠지만, N+1문제부터 DB replicaiton까지 신경을 쓰지 않고 만들었다. 백엔드 로드맵을 따라서 여러 것들을 공부해보니 다음 프로젝트 때에는 기본적인 설계부터 꼼꼼하게 신경써야겠다고 생각을 하게 되었다.

로컬에서만 돌리던 웹을 AWS로 조만간 배포할 예정인데, 이번에 배운 AWS를 통해 DB replication을 적용시켜 배포해봐야겠다.

 

 

 

 

Ref) https://velog.io/@zpswl45/DB-Replication-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC

[DB] Replication이란 무엇이고 장점과 한계점 정리