RCS Biz Center 용량 증설 및 고도화 프로젝트 - 데이터 동기화를 위한 Replication 연동

이 페이지에서는 RCS Biz Center 용량 증설 프로젝트 수행 중 겪은 Connection Block 확인 및 조치사항에 대해서 다룬다.

이 프로젝트의 개요는 아래와 같다

 

2021.06.17 - [수행 프로젝트 일지/MySQL] - RCS Biz Center 용량 증설 및 고도화 프로젝트 - 개요

이글을 읽기 전, 해당 페이지글을 먼저 읽고 오면 좋다.

2021.07.09 - [MySQL/기타 지식] - MySQL / MariaDB Replication -Slave 서버 데이터 기입

 

 

 

 

해당 프로젝트 진행 중, DB 서버를 spec-up 이 된 서버로 이관하는 작업을 계획하게 되어 이에 대한 작업을 지원하게 되었다. 이 때, 서비스 운영 파트에서 기존 운영서버를 (실무에서는 보통 이러한 이관 작업 시, 기존 서버를 AS-IS 서버로 명칭하므로 이후 후술은 AS-IS 서버로 명칭하겠다) 무중단으로 운영하면서 신규 서버 (실무에서는 보통 이러한 이관 작업 시, 기존 서버를 TO-BE 서버로 명칭하므로 이후 후술은 TO-BE 서버로 명칭하겠다) 로 데이터를 이관하고, 그 후 AP 서버들을 하나씩 신규 서버로 연결하면서 두 서버간 데이터 동기화를 끊을 수 있는지를 문의 했었다.

 

필자는 이에 대한 문의를 받았을 시, Replication 을 먼저 생각했었으나 이에 대해서 아래와 같이 고려할 점이 있었다.위의 게시글을 보면 알겠지만 MySQL / MariaDB 의 기본적인 Replication 구조는 아래와 같다.

 

 

 

 

이 상태에서 서비스 운영 파트 요청을 받은 구조는 아래와 같게 될 것 이다.

 

 

 

 

물론 이상태에서는 AP 서버가 read 용으로 쓰는 Slave 서버에도 데이터 기입을 해야 하므로 Read-Only 속성을 부여하지 않고 데이터 기입을 허용 해야한다.

 

 

 

 

이 구조로 진행을 하게 되면 단방향 동기화 상태이기에 Slave 변동분과 Master 데이터 변동분 사이에 대한 DB 간 정합성조절을 내부적으로 처리하지 못하여 정합성 오류가 나게 된다. Replication 을 양방향 Master 로 쓸수도 있으나 타 DB 대비 (ex Oracle RAC) MySQL / MariaDB 는 양방향 Master 또한 정합성을 보장하지 못할 확률이 크기에 이에 대한 리스크를 서비스 운영 파트에 공유했고, 서비스 파트는 아래의 상황을 공유하여서 정합성 불일치를 어느정도 허용하는 걸로 의견을 주었다.

 

 

- 해당 서버에는 PK 가 있는 테이블이 없어서 테이블간 Null, Unique 등에 대한 조건 제한을 고려 할 필요없다.

(만약 해당 조건으로 정합성 문제가 생기면 Replication 오류가 생겨서 이에 대한 오류 skip 을 DB에서 설정 해야한다.)

 

- 서버 전환간에 발생 할 수 있는 소량의 데이터 누수는 허용하고 진행 할 수 있다.

 

- 해당 서버는 update, delete 없이 단순 insert 만 서비스 운영 logic 으로 수행된다.

 

 

위의 조건을 통해서 해당 작업에 대한 리스크를 감수하고 작업을 수행하게 되었다.

만일 위의 조건이 없었다면 여러 파라미터를 조절 해야하는 어려움이 있었을 것으로 보이는데 다행히도 작업을 마무리 할 수 있었다.

 

다만 이후에 정합성까지 정확하게 판별하는 작업 요청이 들어온다면 이에 따른 다양한 테스트가 선행 되어야 할 것으로 보인다.