• 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 구성
    1. Replication 설정 방법
    2. Replication Formats
    3. 글로벌 트랜잭션 식별자를 사용하여 복제
    1. GTID 개념
    2. GTID를 사용한 복제 설정
    3. Failover 및 확장에 GTID 사용
    4. GTID 기반 Replication 제약
    4. Replication 및 바이너리 Logging 옵션 과 변수
    5. 일반적인 Replication 관리 작업
    2. Replication 구현
    3. 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.1.3.3 Failover 및 확장에 GTID 사용

MySQL 5.6.9에서 글로벌 트랜잭션 식별자 (GTID)에 따라 MySQL Replication을 사용하면 더 나중에 새로운 슬레이브 (확장 할 수 있으며, 필요에 따라 장애 복구시 마스터로 승격되는)를 제공하기 위해 몇 가지 기술이 있습니다. 이 섹션에서는 다음과 같은 4 가지 기술에 대해 설명합니다.

  • 단순한 복제

  • 데이터와 트랜잭션을 노예로 복사

  • 빈 트랜잭션 주입

  • gtid_purged 트랜잭션 제외

글로벌 트랜잭션 식별자는 특히 복제 데이터 흐름 및 장애 조치 활동의 일반 관리를 단순화하기 위해 MySQL Replication에 추가되었습니다. 각 식별자는 전체 트랜잭션을 구성하는 바이너리 로그 이벤트 세트를 고유하게 식별합니다. GTID는 데이터베이스에 변경 사항을 적용 할 때 중요한 역할을합니다. 서버는 이전에 처리 된 것으로 인식하고있는 식별자의 트랜잭션을 자동으로 건너 뜁니다. 이 동작은 자동 복제 포지셔닝 및 정확한 장애 조치를 위해 중요합니다.

트랜잭션을 구성하는 식별자와 이벤트 세트 사이의 매핑은 바이너리 로그에서 획득됩니다. 이는 다른 기존의 서버에서 데이터에 새로운 서버를 프로비저닝 할 때 몇 가지 문제를 제기합니다. 새로운 서버 식별자 세트를 재생하려면 기존 서버에서 새로운 서버에 식별자를 복사하여 식별자와 실제 이벤트 사이의 관계를 유지해야합니다. 이것은 페일 오버 또는 스위치 오버에 새로운 주인이 될 후보로 즉시 사용 가능한 슬레이브를 복원하는 데 필요합니다.

단순한 복제 이것은 새로운 서버에서 모든 식별자와 트랜잭션을 재생하기위한 가장 쉬운 방법입니다. 단순히 새로운 서버를 모든 실행 기록을 가진 마스터 슬레이브하여 두 서버에서 글로벌 트랜잭션 식별자를 사용합니다. 자세한 내용은 섹션 17.1.3.2 "GTID를 사용한 복제 설정" 을 참조하십시오.

복제가 시작 된 후 새로운 서버는 마스터에서 바이너리 로그를 복사하여 모든 GTID에 대한 모든 정보를 가져옵니다.

이 방법은 간단하고 효과적이지만, 슬레이브는 마스터에서 바이너리 로그를 읽을 수 있어야합니다. 새로운 슬레이브가 마스터를 따라 잡기 위해 비교적 긴 시간이 걸릴 수 있으며,이 방법은 신속한 장애 복구 또는 백업에서 복원에는 적합하지 않습니다. 이 섹션에서는 바이너리 로그 파일을 새 서버로 복사하여 마스터에서 모든 실행 기록을 가져 오는 것을 방지하는 방법에 대해 설명합니다.

데이터와 트랜잭션을 노예로 복사 재생을 거래 내역에 걸쳐 진행에 시간이 걸릴 수 있으며, 새로운 리플리케이션을 설정할 때 큰 병목 현상입니다. 이 요구 사항을 해소하기 위해 마스터에 포함 된 데이터 세트의 스냅 샷 바이너리 로그 및 글로벌 트랜잭션 정보가 노예로 가져옵니다. 바이너리 로그가 재생 된 후 복제를 시작 할 수 있기 때문에 슬레이브는 나머지 트랜잭션에 유지할 수 있습니다.

이 방법에는 몇 가지 종류가 있으며, 여기에 같이 데이터 덤프 및 바이너리 로그에서 트랜잭션이 슬레이브에 전송되는 방법에 차이가 있습니다.

데이터 세트 거래 내역
  • mysql 클라이언트를 사용하여 mysqldump로 생성 된 덤프 파일을 가져옵니다. --master-data 옵션을 사용하여 바이너리 로깅 정보를 수집, AUTO (기본값) 또는 ON 의 --set-gtid-purged (MySQL 5.6.9 이후에 사용 가능)를 사용하여 실행 된 트랜잭션에 대한 정보를 가져옵니다. 슬레이브에서 덤프를 가져올 때, --gtid-mode=ON 으로하십시오. (Bug # 14832472)

  • 슬레이브를 중지하고 마스터 데이터 디렉토리의 내용을 슬레이브 데이터 디렉토리에 복사 한 후 슬레이브를 다시 시작합니다.

gtid_mode 가 ON 이 아닌 경우 GTID 모드를 활성화 한 상태에서 서버를 다시 시작합니다.

  • mysqlbinlog를 --read-from-remote-server 및 --read-from-remote-master 옵션으로 사용하여 바이너리 로그를 가져옵니다.

  • 마스터의 바이너리 로그 파일을 슬레이브에 복사합니다. mysqlbinlog --read-from-remote-server --raw 을 사용하여 슬레이브에서 복사본을 만들 수 있습니다. 이들은 다음 중 하나의 방법으로 노예로 읽을 수 있습니다.

    • 노예 binlog.index 파일을 업데이트하여 복사 된 로그 파일을 가리 킵니다. 다음은 mysql 클라이언트에서 CHANGE MASTER TO 문을 실행하고 첫 번째 로그 파일을 가리킨 START SLAVE 를 실행하고 그들을 읽습니다.

    • mysqlbinlog > file ( --raw 옵션없이)을 사용하여 mysql 클라이언트가 처리 할 수있는 SQL 파일에 바이너리 로그 파일을 내 보냅니다.

섹션 4.6.8.3 "바이너리 로그 파일의 백업을위한 mysqlbinlog 사용" 을 참조하십시오.

이 방법은 새로운 서버를 거의 즉시 사용할 수 있다는 장점이 있습니다. 그러나 스냅 샷 또는 덤프 파일이 재생되는 동안 커밋 된 트랜잭션 만은 기존의 마스터에서 가져온해야합니다. 이것은 슬레이브는 즉시 사용할 수 없음을 의미하지만, 슬레이브가 이러한 소량의 나머지 트랜잭션 따라 잡기 위해 비교적 짧은 시간 밖에 필요없는 것입니다.

미리 대상 서버에 바이너리 로그를 복사하는 것은 트랜잭션 실행 내역 전체를 실시간으로 마스터에서 읽을보다 일반적으로 빠릅니다. 그러나 크기 및 기타 고려 사항에 따라 필요한 경우 이러한 파일을 대상으로 이동하는 것이 항상 실현 가능하지는 않을 수 있습니다. 이 섹션에서 설명하는 새로운 슬레이브를 제공하기위한 나머지 두 가지 방법은 다른 방법을 사용하여 트랜잭션에 대한 정보를 새로운 슬레이브에 전송합니다.

빈 트랜잭션 주입 마스터의 글로벌 gtid_executed 변수는 마스터에서 실행되는 모든 트랜잭션 세트가 포함되어 있습니다. 새로운 서버를 프로비저닝하기 위해 스냅 샷을 만들 때 바이너리 로그를 복사하는 대신 스냅 샷이 생성 된 서버에서 gtid_executed 의 내용에 주목합니다. 새로운 서버를 복제 체인에 추가하기 전에 마스터의 gtid_executed 에 포함 된 트랜잭션 식별자마다 새로운 서버에서 다음과 같이 단순히 빈 트랜잭션을 커밋합니다.

 SET GTID_NEXT = 'aaa-bbb-ccc-ddd : N';

 BEGIN;
 COMMIT;

 SET GTID_NEXT = 'AUTOMATIC';

모든 트랜잭션 식별자가 하늘의 트랜잭션을 사용하여 이렇게 회복 된 후, 여기에 같이 슬레이브의 바이너리 로그를 플러시하여 제거해야합니다. 여기서 N 은 현재의 바이너리 로그 파일명의 제로가 아닌 접미사입니다.

 FLUSH LOGS;
 PURGE BINARY LOGS TO 'master-bin.00000 N ';

나중에 마스터로 승격 된 경우이 서버가 잘못된 트랜잭션 복제 스트림이 넘치는 것을 방지하기 위해이를 수행하는 것이 좋습니다. ( FLUSH LOGS 문을 강제로 새로운 바이너리 로그 파일을 만듭니다. PURGE BINARY LOGS 는 하늘의 트랜잭션을 제거하지만, 그 식별자를 유지합니다.)

이 방법은 본질적으로 스냅 샷이더라도 나중에 마스터가 될 서버를 만듭니다 (바이너리 로그 기록을 복제 스트림의 그것과 일치했을 때, 즉 마스터 따라 잡았 때). 이 결과는 나머지 프로비저닝 방법을 사용하여 얻은 결과에 실질적으로 비슷합니다 (다음 몇 단락에서 설명합니다).

gtid_purged 트랜잭션 제외 마스터의 글로벌 gtid_purged 변수는 마스터의 바이너리 로그에서 제거 된 모든 트랜잭션 세트가 포함되어 있습니다. 앞에서 설명한 방법과 마찬가지로 ( 빈 트랜잭션의 주입 을 참조하십시오) 스냅 샷이 생성 된 서버 (바이너리 로그를 새 서버로 복사하는 대신) gtid_executed 값을 기록 할 수 있습니다. 이전 방법과는 달리 빈 트랜잭션을 커밋 할 필요가 없습니다 ( PURGE BINARY LOGS 를 발행 할 필요가 없습니다). 대신 백업 또는 스냅 샷이 생성 된 서버의 gtid_executed 의 값에 따라 슬레이브에서 직접 gtid_purged 을 설정할 수 있습니다.

참고

MySQL 5.6.9 이전에는 gtid_purged 을 설정할 수 없습니다. (Bug # 14797808)

하늘의 트랜잭션을 사용하는 방법과 마찬가지로이 방법은 기능적으로 스냅 샷이더라도 나중에 마스터가 될 서버를 만듭니다 (바이너리 로그 기록을 복제 마스터 또는 그룹의 그것과 일치 할 때 ).

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