• MySQL매뉴얼
    • MySQL 5.6 매뉴얼
    • MySQL 5.1 매뉴얼
    • MySQL 5.0 매뉴얼
    • MySQL HA 매뉴얼
  • 기술문서
    • Xtrabackup 구성
    • 메모리 사용량 모니터링
  • 서비스
    • MySQL유지보수
    • MySQL라이선스
  • 온라인문의
  • 회사소개
  • → 목 록 (MySQL HA 한글메뉴얼) [close]
  • 1. Chapter 리플리케이션
  • 1. 리플리케이션 구성
    2. 리플리케이션 솔루션
    3. 리플리케이션 노트 (Notes) 및 팁 (Tips)
    4. 리플리케이션 구현
    1. 리플리케이션 구현 상세 설명
    2. 리플리케이션 마스터 쓰레드 상태
    3. 리플리케이션 슬레이브 I/O 쓰레드 상태
    4. 리플리케이션 슬레이브 SQL 쓰레드 상태
    5. 리플리케이션 슬레이브 연결 쓰레드 상태
    6. 리플리케이션 릴레이 및 상태 파일
    7. 서버의 리플리케이션 규칙 평가 방법
  • 2. Chapter MySQL ndb Cluster

1.4.1. 리플리케이션 구현 상세 설명

 

MySQL 리플리케이션은 세 개의 쓰레드를 사용해서 구현된다 (하나는 마스터에서 구현되며 나머지 두 개는 슬레이브에서 구현된다). START SLAVE 명령문이 슬레이브 서버에 입력되면, 슬레이브 서버는 하나의 I/O 쓰레드를 생성하는데, 이 쓰레드는 마스터에 접속하여 마스터 바이너리 로그에 기록되어 있는 업데이트 사항을 요청한다. 마스터는 쓰레드를 하나 생성해서 바이너리 로그의 내용을 슬레이브에 보낸다. 이 쓰레드는 마스터 서버에서 실행되는 SHOW PROCESSLIST 결과에서 Binlog Dump 쓰레드 형태를 갖게 된다. 슬레이브 I/O 쓰레드는 마스터 Binlog Dump 쓰레드가 로컬 파일로 보내서 복사본을 만드는 릴레이 로그라는 업데이트 내용을 슬레이브 데이터 디렉토리에서 읽는다. 세 번째 쓰레드는 SQL 쓰레드이며, 이것은 슬레이브가 릴레이 로그를 읽고 그 안에 있는 것들을 실행하기 위해 생성하는 쓰레드다.

앞에서 설명을 하였듯이, 마스터/슬레이브 접속 별로 세 개의 쓰레드가 존재한다. 여러 개의 슬레이브를 가지고 있는 하나의 마스터는 현재 접속되어 있는 각각의 슬레이브 별로 하나의 쓰레드를 생성하고, 각 슬레이브는 자신만의 I/O 와 SQL 쓰레드를 가지게 된다.

슬레이브는 마스터에서 업데이트된 것을 읽고 이것들을 실행시키기 위해 서로 별도의 일을 처리하는 두 개의 쓰레드를 사용한다. 따라서, 설사 명령문을 실행하는 속도가 느리다고 하더라도 명령문을 읽는 업무는 느려 지지 않는다. 예를 들면, 슬레이브 서버가 한동안 구동 되지 않았다면, 비록 SQL쓰레드의 속도가 꽤 느리다고 하더라도, 슬레이브 I/O쓰레드는 슬레이브가 구동될 때 마스터로부터 재빠르게 모든 바이너리 로그 내용을 읽어 온다. SQL쓰레드가 읽어온 모든 명령문을 실행하기 전에 슬레이브 서버가 멈추게 된다면, I/O 쓰레드는 명령문 복사본을 슬레이브 릴레이 로그에 로컬로 안전하게 저장할 수 있고, 슬레이브가 다시 구동될 때 실행을 계속할 수 있는 최소한의 것들을 갖게 된다. 이를 통해 마스터는 더 이상 슬레이브가 자신의 업데이트를 읽도록 기다릴 필요가 없기 때문에 마스터 서버 자신의 바이너리 로그를 잠시 후에 깨끗이 지울 수 있게 된다.

SHOW PROCESSLIST 명령문은 리플리케이션에 관련하여 마스터와 슬레이브 서버에서 어떤 일이 있었는지를 보여 준다. 아래의 SHOW PROCESSLIST 명령문은 세 개의 쓰레드가 어떻게 보여지는지를 나타내고 있다.

마스터 서버의 경우, SHOW PROCESSLIST 결과는 아래처럼 보인다: 
 

mysql> SHOW PROCESSLIST\G

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

     Id: 2

   User: root

   Host: localhost:32931

     db: NULL

Command: Binlog Dump

   Time: 94

  State: Has sent all binlog to slave; waiting for binlog to

         be updated

   Info: NULL

여기에서, 쓰레드 2는 접속 슬레이브의 Binlog Dump 리플리케이션 쓰레드다. State 정보는 모든 업데이트 사항이 슬레이브에 전달 되었으며 마스터는 다른 업데이트가 발생하는 것을 대기하고 있다는 것을 알려준다. 마스터 서버에서 Binlog Dump 쓰레드를 볼 수 없다면, 그것은 리플리케이션이 구동 되지 않고 있음을 의미하는 것이다 — 즉, 현재 어떠한 슬레이브도 연결되어 있지 않다.

슬레이브 서버의 경우, SHOW PROCESSLIST 실행 결과는 다음과 같다: 

 

mysql> SHOW PROCESSLIST\G

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

     Id: 10

   User: jake

   Host:

     db: NULL

Command: Connect

   Time: 11

  State: Waiting for master to send event

   Info: NULL

*************************** 2. row ***************************

     Id: 11

   User: system user

   Host:

     db: NULL

Command: Connect

   Time: 11

  State: Has read all relay log; waiting for the slave I/O

         thread to update it

   Info: NULL

위에서는 쓰레드 10이 마스터 서버와 통신을 하는 I/O 쓰레드이고, 쓰레드 11은 릴레이 로그에 저장되어 있는 업데이트 사항을 실행하는 SQL 쓰레드라는 것을 알려 준다. SHOW PROCESSLIST 가 실행 되었을 때에는 양쪽 쓰레드는 모두 아이들 (idle) 상태였으며, 또 다른 업데이트를 기다리고 있는 중이었다.

Time 컬럼에 있는 값은 슬레이브가 마스터와 비교해서 얼마나 늦는지를 알려주는 것이다.

서울시 강남구 영동대로 602 6층  TEL: 02-6061-0006
주식회사 이노클러스터  등록번호 : 727-86-02261
Copyright © innocluster Co. ltd. all rights reserved