MySQL 5.5 Semi-Synchronous Replication에 대하여 알아보기전에 먼저

 

MySQL 5.1버전까직의 Replication 구조는 비동기방식 이었습니다.

 

master서버는 자신의 bin-log에 update내용을 쓰고나면 slave에 대하여 아무런 신경도 쓰지 않았습니다.

 

slave가 master측의 bin-log를 읽어서 자신의 relay-log에 쓴다음

자신의 storage engine에 반영하는 구조였습니다.

 

비동기방식은 master서버의 update가 빈번할 타이밍에 master서버에 장해가 발생하면

master와slave간의 동기화가 곧잘 틀어지고는 했습니다.

 

Semi-Synchronous Replication는 원래 Google의 Mark Callaghan에 의해 개발되었습니다.

좀더 쉬운 설명을 위해서 아래 그림을 보도록 하겠습니다.

그림은  Semi-Synchronous Replication의 동작을 그림으로 나타낸 것입니다.

 

①  어플리케이션(클라이언트）로부터 transaction을 COMMIT 한다.

②  바이너리 로그를 갱신한다.

③  storage engine(테이블）을 갱신한다.

④  ③과 동시에 바이너리 로그의 내용이 슬레이브에 송신된다.

⑤  슬레이브가 로그의 갱신을 받으면 마스터에ack를 돌려준다.

⑥  스토리지 엔진의 갱신과 슬레이브로부터의ack를 확인하면 클라이언트에 응답을 돌려준다.

⑦  슬레이브측에서 로그를 적용한다.(비동기)

 

지금까지의 Replication(MySQL 5.1)에서는 Slave측 입장에서는 비동기였죠.

Master측에서 Slave를 터치 하는 엑션은 전혀 없었습니다.

 

 

Slave측에서 relay log의 내용을 Storage Engine에 반영되는것은 비동기에 행해진다.

③ 과④는 병렬처리된다.

그 때문에 네트웍이 과부하 상태가 아니라면 commit성능에 대한 오버헤드는 매우 작게 된다.

slave로부터 최초의 ack를 받는 타이밍에서 클라이언트에 send_ok() 되어 진다.

 

만일 Master가 크래쉬 됬을 경우에도 commit하지만 완료한 모든 update는 slave측에 존재한다.

slave측에서 fail over 해도 update된 정보가 없어지는 일은 발생 되지 않는다.

 

크래쉬가 발생하면 다음과 같은 순서로 fail over가 실행된다.

 

① Slave가 파일시스템을 마운트한다.

② MySQL서버를 가동시킨다.

③ InnoDB의 로그를 스캔해 크래쉬 recovery(Redo/Undo)를 실행한다.

 

 특히 크래쉬 recovery는 맹신할수 없는 녀석이므로, InnDB log file size가 큰경우에는 장시간 소요된다.

또 InnoDB의 로그사이즈를 작게 설정되었더라도 몇분이 소요되며, 크래쉬에 update내용이 많았을때에는

Undo의 처리에 시간이 더 소요된다.

 

이것에 비교한다면 Semi-Synchronous Replication는 미적용된 relay log가 적용되는 것을 기다린다.

파일 시스템을 마운트할 필요도 MySQL서버를 기동시킬 필요도 없다.

 

relay log의 적용은 크래쉬 recovery에 비하면 매우 짧은 처리일것이다.

 

제대로 commit을 적절한 Size(작은size)로 TRANSACTION 상태라면 경우에 따라서는

1초 미만으로 fail over가 완료될것이다.

 

아울러서 Slave에 대해 모든 relay log 적용이 완료 되었는지 show slave status\G

그리고 Exec_Master_Log_Pos 와 Read_Master_Log_Pos 동일한지,

show processlist , SQL_Thread상태가

「Has read all relay log; waiting for the slave I/O thread to update it」인지 확인할수 있다.

 

또、Semi-Synchronous Replication를 이용해HA(을)를 구성했을 경우、

마스터측에서의 스토리지 엔진에의 갱신과、슬레이브에의 갱신의 전송은 병렬（비동기)로 행해진다

 

그 때문에、마스터에만 존재하는 데이터나 슬레이브에만 존재하는

데이터가 발생해 버리는 부정합인 상황이 보기 드물게 발생한다.

 

그러한 상황이 상정되기 위해、한 번 fail over가 발생했을 때는 마스터에 데이터를 다시

카피할 필요가 생길 것이다.

 

슬레이브로부터 풀백 업을 취득해 마스터에 restore 하는 것이다.

백업의 방법은LVMsnapshot、InnoDB Hot Backup、mysqldump등을 이용하면 좋다.

 

부하량이 적을 때를 계산하여 작업을 실시하면 좋을 것이다.

 

또한、슬레이브 측에 또다른 슬레이브를 추가해 두면、

추가된 슬레이브로부터 마스터에 restore를 실시하는 것이 가능하게 된다.

 

추가 슬레이브를 붙여 두면2중 장해에도 대응할 수 있게 하기 위해、

Semi-Synchronous Replication을 운용하는 경우에는 추가 슬레이브의 설치를 검토하자.

(추가 슬레이브를 설치하려면 슬레이브에 대해--log-slave-updates옵션을 이용하기 때문에

슬레이브의 fail over시에는FLUSH LOGS(을)를 할 필요가 있을 것이다.）