반응형

http://mysqldba.tistory.com/173


Replication의 현재 상태의 가장 빨리 파악할 수 있는  show slave status의 상태값 중 Seconds_Behind_Master값에 대한 것을 정리해 보자.

 

이 필드는 slave가 얼마나 늦었는지를 보여주는 항목이다.

  • slave가 update를 할 때, 이 필드는 Master에서 받은 로깅된 timestamp의 값과, 현재 slave에서 실행되는 현재의 timestamp의 값의 차이를 보여준다.
  • slave에서 아무런 이벤트도 실행하고 있지 않다면, 그 값은 0 이다.

본질적으로, 이 필드는 SQL thread와 I/O thread의 차이를 측정하려는 것이다. 만약, Master와 Slave사이의 네트웍이 매우 빠르다면, slave I/O thread는 Master 로 부터 매우 빨리 이벤트를 가지고 올 것이고, 그래서 이 필드는 Master와 SQL thread 가 얼마나 많이 차이가 나는지 좋은 근사값을 얻을 수 있다. 만약, 네트웍이 느리다면, 이것은 좋은 근사값이 되지 못한다. SQL thread는 느리게 이벤트를 읽는 I/O thread를 자주 따라 잡을 것이기 때문이다. 그래서, 그런 상황에서 I/O thread가 Master에 비교하여 느릴지라도  Seconds_Behind_Master는 자주 0으로 보이게 될 것이다. 다른 말로 하면, 이 컬럼은 단지 빠른 네트웍 상에서만 유용하다.

 

Master와 Slave가 동일한 시간을 가지고 있지 않다고 하더라도, 이 시차 계산식은 동작하는데, slave의 I/O thread가 시작될때 계산된 값을 사용하여 시간차에 대한 값을 계산한다. NTP update를 포함하는 어떤 변경사항이라도 시간 왜곡이 발생할 수 있는데, 이것은 Seconds_Behind_Master를 좀 신뢰할 수 없게 만들 수 있다.

 

MySQL 5.6.9 이후에서, 이 필드는 만약, SQL thread가 동작하지 않거나, SQL thread가 모든 relay log를 다 적용하였는데도, slave I/O thread가 동작하지 않은 상황이 되면 NULL로 표시된다. 전에, 이 필드는 SQL thread나 I/O thread가 동작하지 않거나, master에 연결되지 않으면 NULL로 설정되었다. (Bug #12946333) 예를 들어, MySQL Ver.5.6.9 이전인 경우에, I/O thread가 master에 연결되지 않거나, 대기상태임에도 불구하고, 실행중이면, 그 값이 NULL로 보였었다. 이제는 이러한 경우는 Master에 연결테스트가 되지 않는 것이다. 대신에, 만약, I/O thread가 relay log를 다 적용하고도 실행중에 있다면, Seconds_Behind_Master는 0으로 설정된다.

 

Seconds_Behind_Master의 값은 replicated되는 이벤트에 저장된 timestamps의 값을 기초로 한다. 이것은 즉, m1이 m0의 slave라면, m0으로 부터 받은 m1의 바이너리 로그의 이벤트는 m0의 timestamp 값을 가진다. 이것은 MySQL이 TIMESTAMP을 성공적으로 replicate하게 enable한다.

그러나, 만약, M1이 클라이언트로 부터 직접 update를 받는다면,  Seconds_Behind_Master의 값이 불규칙하게 변한다는데에  Seconds_Behind_Master의 문제가 있다. 때문에, m0으로 부터 받은 이벤트가 나올수도 있고, m1이 직접 생성한 이벤트가 나올수도 있기 때문이다.

 

MySQL Version 5.6.3 이상에서 multi-threaded slave를 사용할 때, 사용자는 이 값이 Exec_Master_Log_Pos를 기본으로 하여 만들어 진다는 것을 기억해야 한다. 그리고, 가장 최근에 커밋한 트랜잭션의 위치를 반영하지 않을 수도 있다는 것도 기억해야 한다.

 

반응형

+ Recent posts