• MySQL매뉴얼
    • MySQL 5.6 매뉴얼
    • MySQL 5.1 매뉴얼
    • MySQL 5.0 매뉴얼
    • MySQL HA 매뉴얼
  • 기술문서
    • Xtrabackup 구성
    • 메모리 사용량 모니터링
  • 라이선스
  • 온라인문의
  • 회사소개
  • → 목 록 (MySQL5.6 한글메뉴얼) [close]
  • 1. MySQL 5.6 새로운 기능
  • 2. MySQL 설치 및 업그레이드
  • 3. MySQL Tutorial
  • 4. MySQL 프로그램
  • 5. MySQL 서버관리
  • 6. 보안
  • 7. 백업 및 복구
  • 8. 최적화
  • 9. Language Structure(언어구조)
  • 10. Character Sets(Globalization)
  • 11. 데이터형(Data Types)
  • 12. 함수와 연산자
  • 13. SQL 문법
  • 14. InnoDB 스토리지 엔진
  • 15. 기타 스토리지 엔진
  • 16. 고가용성 및 확장성
  • 17. 리플리케이션
  • 1. Replication 구성
    2. Replication 구현
    3. Replication 솔루션
    1. 백업을 위해 Replication 사용
    2. 다른 Master 및 Slave 스토리지 엔진에서 복제
    3. 확장(Scale-Out)을 위한 복제
    4. 다른 데이터베이스를 다른 Slave에 복제
    5. Replication 성능을 향상
    6. 장애 발생시 Master 전환
    7. SSL을 사용하여 Replication 설정
    8. Semisynchronous Replication(반동기 복제)
    9. 복제 지연(Delayed Replication)
    4. Replication Notes and Tips
  • 18. MySQL Cluster
  • 19. 파티셔닝
  • 20. Stored Programs and Views
  • 21. INFORMATION_SCHEMA
  • 22. PERFORMANCE SCHEMA
  • 23. 컨넥터 및 API
  • 24. MySQL 확장
  • 25. MySQL Enterprise Edition
  • 26. MySQL Workbench
  • 27. 제약 및 제한
  • 28. MySQL 5.7 새로운 기능

17.3.5 Replication 성능을 향상

마스터에 연결하는 슬레이브의 수가 증가함에 따라 각 슬레이브가 마스터에 대한 클라이언트 연결을 사용하기 때문에 최소한이지만 부하도 증가합니다. 또한 각 슬레이브가 마스터 바이너리 로그의 전체 사본을 수신해야하기 때문에 마스터의 네트워크 부하도 증가하고 병목이되는 경우가 있습니다.

하나의 마스터에 연결되는 매우 많은 노예를 사용하고 그 마스터도 요청 처리에 바쁜 경우에는 (예를 들어, 스케일 아웃 솔루션의 일부로) 복제 프로세스의 성능을 향상시킬 을 권장합니다.

복제 프로세스의 성능을 개선하는 방법 중 하나는 깊은 복제 구조를 만들고 마스터는 하나의 슬레이브 만 복제하고 나머지 슬레이브는 개별 복제 요구 사항으로 인해이 주 슬레이브에 연결합니다 . 이 구조의 샘플 그림 17.3 "성능을 개선하기 위해 추가 복제 호스트 사용" 입니다.

그림 17.3 성능을 개선하기 위해 추가 복제 호스트를 사용하는

성능을 개선하기 위해 추가 복제 호스트를 사용

이 기능하려면 MySQL 인스턴스를 다음과 같이 구성해야합니다.

  • 마스터 1은 기본 마스터에서 모든 변경 및 업데이트가이 데이터베이스에 기록됩니다. 바이너리 로깅이 기계에서 활성화해야합니다.

  • 마스터 2는 마스터 1 슬레이브에 복제 구조의 나머지 슬레이브에 복제 기능을 제공합니다. 마스터 2는 마스터 1에 연결을 허용하는 유일한 시스템입니다. 마스터 2의 바이너리 로깅도 활성화되어 있고, --log-slave-updates 옵션은 마스터 1에서 복제 명령이 마스터 2의 바이너리 로그에 기록되기 때문에 그들을 진정한 슬레이브에 복제 할 수 있습니다.

  • 슬레이브 1 슬레이브 2, 슬레이브 3 마스터 2의 보조 역할을하게 마스터 2에서의 정보 (실제로 마스터 1에 로그가 기록 된 업데이트로 구성)를 복제합니다.

위의 솔루션은 클라이언트 부하와 기본 마스터에서 네트워크 인터페이스 부하를 줄이기 위해 직접 데이터베이스 솔루션으로 사용할 때 기본 마스터의 전반적인 성능을 개선하는 것입니다.

슬레이브가 마스터 복제 과정을 따라갈에 문제가있을 경우에는 사용 가능한 옵션이 몇 가지 있습니다.

  • 가능하면 릴레이 로그 및 데이터 파일을 다른 물리적 드라이브에 넣습니다. 이를 위해서는 --relay-log 옵션을 사용하여 릴레이 로그의 위치를 지정합니다.

  • 슬레이브가 마스터보다 훨씬 느린 경우 다른 데이터베이스를 다른 슬레이브에 복제 할 책임을 분할하는 것이 좋습니다. 섹션 17.3.4 "다른 데이터베이스를 다른 슬레이브에 복제" 를 참조하십시오.

  • 마스터가 트랜잭션을 사용하기 때문에 슬레이브에서의 트랜잭션 지원에 관심이없는 경우, 슬레이브에서 MyISAM 또는 다른 비 트랜잭션 엔진을 사용하십시오. 섹션 17.3.2 "다른 마스터 및 슬레이브 스토리지 엔진에서 복제 사용" 을 참조하십시오.

  • 슬레이브가 마스터로 작동하지 않고 장애시 확실하게 마스터를 회복 할 수있는 잠재적 인 솔루션이 구현되는 경우, --log-slave-updates 를 해제 할 수 있습니다. 그러면 "댐"슬레이브가 실행 한 이벤트 로그가 자신의 바이너리 로그에 기록되지 않습니다.


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