[MySQL/MariaDB] Replication의 작동원리

[replication의 작동원리]

 

1. Master 서버에서는 bin-log를 로깅하면 binlog dump라는 프로세스가

Slave 서버에 이벤트를 보낸다

2. Slave 서버의 slve_io_thread 가 마스터의 bin-log를 복사해 온다.

3. 그후 slave_io_thread가 relay-log 를 로깅.

4. 다시 slave 서버의 slave_SQL_thread가 relay-log를 바탕으로 마스터의

 

SQL구문을 재생.(동기화)

 

위의 4단계가 리플리케이션의 작동원리 입니다.

Relay-log를 다시 재생하는 (slave_SQL_thread )과정에서  불필요한 부하가 생기는 방식이 아닌가 의문이 드시겠지만

Relay-log는 보통 운영체제의 캐시에 저장이 되므로 오버헤드가 매우 낮습니다.

 

위와 같이 슬레이브에서 이벤트를 가져오고 재생하는 과정으로 인해 리플리케이션은 비동기식으로 작동하게 됩니다.

 

따라서 특정주기로 리플리케이션의 복제가 일어나는 것이 아니라 마스터의 변경사항은 그 즉시 동기화가 됩니다.

동기화는 즉시 일어나지만 네트워크의 속도로 인하여 지연이 발생한다고 보시면 됩니다.

 

실제 테스트를 해보면

 

먼저 마스터 서버에서

 

Mysql > create table test.lag_test(

→ Id int not null auto_increment primary key,

→ Now_usec varchar(26) not null

→ );

Mysql > insert into test.lag_test(now_usec) values (now_usec());

 

다음 슬레이브에서

 

Mysql > create table test.master_val (

→ Id int not null auto_increment primary key,

→ Now_usec varchar(26) not null

→ ) engine=federated

→ Connection=’mysql://user:root@192.168.13.147/lag_test’;

 

TIMESTMPDIFF() 함수로 마스터와 슬레이브에서 실행된 쿼리의 지연시간을 마이크초 단위로

찍어보면

 

Mysql > select m.id , timestampdiff ( frac_second, m.now_usec, s.now_usec ) AS user_lag

→ From test.lag_test as s

→ Inner join test.master_val as m using(id);

 

+------+-------------------+

|  id   |  usec_lag      |

+------+-------------------+

|  1   |  476           |

+------+-------------------+

 

400밀리초가 소요 됨을 확인 하였습니다.

 

대부분의 작은 쿼리는 마스터의 실행 시간에서 슬레이브의 실행시간까지의 복제에 0.3밀리초가 걸립니다.

이론상으론 마스터에서 슬레이브까지의 복사시간은 거의 측정불가이며 네트워크 속도가 리플리케이션

복제 속도라고 이해하시면 되겠습니다.

 

 

 

덧붙여 슬레이브 상태정보를 통해 지연되는 정보확인은

 

Mysq >  show slave status\G

로 확인 하실수 있습니다.

*************************** 1. row ***************************

….(중략)…..

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

…(중략)…

Seconds_Behind_Master: 0

붉은색 표시된 이부분이 마스터와 슬레이브의 격차를 시간으로 표시하는 부분입니다.

…(중략)…

***************************************************************