• 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)
    1. 리플리케이션 기능 및 이슈 사항
    2. MySQL 버전간의 리플리케이션 호환성
    3. 리플리케이션 설정 업그레이드하기
    4. 리플리케이션 FAQ
    5. 리플리케이션 문제 해결
    4. 리플리케이션 구현
  • 2. Chapter MySQL ndb Cluster

1.3.5. 리플리케이션 문제 해결

 

구성 지침대로 실행을 하였지만 리플리케이션이 구동을 하지 않는다면, 우선 에러 로그 메시지를 검사하도록 한다. 많은 사용자들이 이 작업을 수행하지 않고 시간만 허비하고 있다.

 에러 로그를 통해서도 문제의 원인을 발견할 수 없다면, 아래의 방법을 시도해 보도록 한다:

·         SHOW MASTER STATUS 명령문을 입력해서 마스터 서버에 바이너리 로깅이 활성화 되었는지를 검증한다. 활성화 되어 있다면, Position은 0이 아닌 값이 된다. 활성화가 되어 있지 않다면, 마스터를 --log-bin 과 --server-id 옵션을 가지고 구동 시켰는지 확인한다.

·         슬레이브가 구동 중인지를 확인한다. SHOW SLAVE STATUS를 사용해서 Slave_IO_Running과 Slave_SQL_Running 값이 모두 Yes인지를 검사한다. 아니라면, 슬레이브 서버를 시작할 때 사용한 옵션을 검사한다. 예를 들면, --skip-slave-start는 사용자가START SLAVE 명령문을 입력할 때까지는 슬레이브 쓰레드를 시작하지 못하도록 한다.

·         슬레이브가 구동 중이라면, 마스터와 접속이 이루어져 있는지를 검사한다. SHOW PROCESSLIST를 사용해서, I/O 와 SQL 쓰레드를 찾고 State 컬럼을 검사한다. I/O 쓰레드 상태가 Connecting to master라고 한다면, 다음을 검사하도록 한다:

    • 마스터에서 리플리케이션을 사용할 수 있도록 사용자 권한이 설정되어 있는지 검사한다.
    • 마스터의 호스트 이름이 올바르게 되어 있고 올바른 포트 번호를 사용해서 마스터에 접속했는지 검사한다. 리플리케이션용 포트는 클라이언트 네트워크 커뮤니케이션용으로 사용하는 것과 같은 것이다 (디폴트는 3306). 호스트 이름의 경우에는 올바른 IP 주소를 사용하고 있는지 검사한다.
    • 마스터와 슬레이브 네트워크가 활성화 되었는지 확인한다. 구성 파일의 skip-networking 옵션을 검사한다.
    • 마스터에 방화벽 또는 IP 필터링이 구성되어 있다면, MySQL이 사용하는 포트가 필터링 되지 않도록 만든다.
    • ping 또는 traceroute/tracert를 사용해서 마스터에 접근할 수 있는지를 확인한다.
  • 슬레이브가 구동은 했으나 멈춰버렸다면, 마스터에서 진행되었던 명령문들이 슬레이브에서 실패를 했기 때문이다. 마스터 스냅샷을 올바르게 가지고 있고, 슬레이브 쓰레드 밖에 있는 슬레이브 상에서 데이터를 결코 수정하지 않았다면, 이러한 일은 결코 발생하지 않는다. 슬레이브가 예상과 달리 멈춰 버렸다면, 그것은 버그 또는 리플리케이션 제약 사항으로 인한 것일 것이다.

·         마스터에서 진행되었던 명령문들이 슬레이브에서는 거부가 되었고, 슬레이브의 데이터 베이스를 삭제하고 마스터에서 새로운 스냅샷을 복사하는 방법으로는 전체 데이터 베이스를 재 동기화 (resynchronization)할 수 없다면, 아래의 과정을 시도해 본다:

1.      슬레이브 테이블이 마스터 테이블과 다른지를 검사한다. 이런 일이 발생한 원인을 알아보도록 한다. 그런 다음에 슬레이브 테이블을 마스터 테이블과 같게 만들고 START SLAVE를 실행한다.

2.      1의 과정이 동작을 하지 않거나 또는 적용이 되지 않을 경우에는, 수동으로 업데이트를 하는 것이 안전한지를 판단하고 마스터에서 오는 그 다음 명령문을 무시한다.

3.      마스터에서 오는 그 다음 명령문을 무시하기로 결정했다면, 아래의 명령문을 입력한다:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;

mysql> START SLAVE;

마스터에서 오는 그 다음 명령문이 AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하지 않는다면, N의 값은 1이 된다. 그렇지 않으면, 그 값은 2가 된다. AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하는 명령문에 대해 2 값을 사용하는 이유는, 이것들이 마스터 바이너리 로그에서 두 개의 이벤트를 가져가기 때문이다.

4.      슬레이브가 마스터와 완벽하게 동기화 된 상태로 시작되었고, 슬레이브 쓰레드 외부에 업데이트된 테이블이 없다고 확신을 한다면, 에러 원인이 버그로 인한 불일치라고 생각할 수 있다. 가장 최신 MySQL 버전을 사용하고 있다면, 발생된 문제점을 보고해 주길 바란다. 예전 버전을 사용하고 있다면, 해당 문제점이 계속 발생되는지 알아보기 위해서 최신 버전 제품으로 업그레이드를 하도록 한다.

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