17.4.3 복제 설정 업그레이드
복제 설치에 관련된 서버를 업그레이드 할 때 업그레이드 단계는 현재 서버 버전과 업그레이드 버전에 따라 다릅니다.
이 섹션은 이전 버전의 MySQL에서 MySQL 5.6에 복제를 업그레이드하기로 할당됩니다. 4.0 서버는 4.0.3 이상이어야합니다. 마스터 복제 사용자는 해시 방식의 변경으로 인해 MySQL 버전 4.1.1 이후에 생성 된 암호 해시가 필요합니다. 자세한 내용은 섹션 6.1.2.4 "MySQL에서 암호 해시" 를 참조하십시오.
이전의 MySQL 릴리즈 시리즈에서 5.6 마스터를 업그레이드 할 때 먼저이 마스터의 모든 슬레이브가 동일한 5.6.x 버전을 사용하고 있는지 확인하십시오. 그렇지 않은 경우는 먼저 슬레이브를 업그레이드하십시오. 각 슬레이브를 업그레이드하려면 종료하고 적절한 5.6.x 버전으로 업그레이드하고 다시 시작하고 복제를 다시 시작하십시오. 업그레이드 후 슬레이브에 의해 생성되는 릴레이 로그는 5.6 형식입니다.
엄격한 SQL 모드에서의 조작에 영향을주는 변경되면 업데이트 된 슬레이브 복제가 실패 할 수 있습니다. 예를 들어, MySQL 5.6.13 이후 버전에서는 서버 엄격 모드 ( STRICT_TRANS_TABLES 또는 STRICT_ALL_TABLES )에서 시간 데이터 형식의 DEFAULT 값에 0의 삽입을 제한합니다. 명령문 기반 로깅 ( binlog_format=STATEMENT )를 사용하는 경우 복제 비 호환되는 노예가 업그레이드 된 경우 업그레이드되지 않은 마스터가 오류없이 실행 문이 슬레이브에서 실패 할 수 있고, 그러면 복제가 중지됩니다. 이를 해결하려면 마스터의 모든 새로운 문을 중지하고 슬레이브가 따라 잡을 때까지 기다립니다. 그리고 슬레이브를 업그레이드합니다. 또는 새로운 문을 중지 할 수 없으면 마스터 일시적으로 행 기반 로깅 변경 ( binlog_format=ROW ) 모든 슬레이브가이 변경 시점에 생성 된 모든 바이너리 로그를 처리 할 때까지 기다립니다. 그리고 슬레이브를 업그레이드합니다.
슬레이브가 업그레이드 된 후 마스터를 종료하고 노예와 같은 5.6.x 버전으로 업그레이드 한 후 다시 시작합니다. 일시적으로 마스터를 열 기반 로깅을 변경 한 경우에는 명령문 기반 로깅으로 되돌립니다. 5.6 마스터는 업그레이드 전에 기록 된 오래된 바이너리 로그를 읽고 그들을 5.6 슬레이브에 보낼 수 있습니다. 슬레이브는 이전 형식을 인식하고 적절하게 처리합니다. 업그레이드 후 마스터에 의해 생성되는 바이너리 로그는 5.6 형식입니다. 이들도 5.6 슬레이브에 의해 인식됩니다.
즉, MySQL 5.6으로 업그레이드 할 때 마스터를 5.6로 업그레이드하기 전에 슬레이브가 MySQL 5.6이어야합니다. 5.6에서 이전 버전으로 다운 그레이드는 그렇게 쉽게 작동하지 않습니다. 다운 그레이드를 진행하기 전에 5.6 바이너리 로그 또는 릴레이 로그를 삭제할 수 있도록 그들이 완전히 처리 된 것을 확인해야합니다.
복제 설정을 이전 버전으로 다운 그레이드하는 것은 문베이스에서 열 기반 리플리케이션로 전환 한 뒤, 그리고 첫 번째 행 기반 문이 binlog에 기록 된 후에는 실행되지 않습니다. 섹션 17.1.2 "복제 형식" 을 참조하십시오.
업그레이드에 따라있는 MySQL 시리즈에서 다음에 마이그레이션 할 때 데이터베이스 객체를 삭제하고 다시 작성해야 할 경우가 있습니다. 예를 들어, 데이터 정렬 변경은 테이블 인덱스의 재 구축이 필요할 수 있습니다. 이러한 작업이 필요한 경우 내용을 섹션 2.11.1.3 「MySQL 5.5에서 5.6로 업그레이드 " 에서 참조하십시오. 이러한 작업을 슬레이브와 마스터에서 개별적으로 수행하고 이러한 작업을 마스터에서 슬레이브에 복제하는 것을 해제하는 것이 가장 안전합니다. 이것을 실현하려면 다음 단계를 사용하십시오.
모든 슬레이브를 중지하고 그들을 업그레이 드합니다. 마스터에 연결하지 않도록,
--skip-slave-start옵션으로 그들을 다시 시작합니다. 데이터베이스 오브젝트의 재 작성에 필요한 테이블 복구 또는 다시 작성 작업 (REPAIR TABLE,ALTER TABLE의 사용 등) 또는 테이블 또는 트리거 덤프 및 리로드를 실행합니다.마스터에서 바이너리 로그를 비활성화합니다. 마스터를 다시 시작하지 않고 이렇게에는
SET sql_log_bin = 0문을 실행합니다. 또는 마스터를 중지하고--log-bin옵션없이 다시 시작합니다. 마스터를 다시 시작하는 경우 클라이언트 연결을 거부 할 수도 좋습니다. 예를 들어, 모든 클라이언트가 TCP / IP를 사용하여 연결하는 경우 마스터를 다시 시작할 때--skip-networking옵션을 사용합니다.바이너리 로그가 비활성화 된 데이터베이스 오브젝트의 재 작성에 필요한 테이블 복구 또는 재 구축 작업을 수행합니다. 이러한 작업이 기록되어 나중에 슬레이브로 전송되는 것을 방지하려면이 과정에서 바이너리 로그를 비활성화해야합니다.
마스터에서 바이너리 로그를 다시 활성화합니다. 이전에
sql_log_bin를 0으로 설정하면SET sql_log_bin = 1문을 실행합니다. 바이너리 로그를 비활성화하기 위해 마스터를 다시 시작하면 클라이언트와 슬레이브가 연결될 수 있도록--log-bin있고,--skip-networking없이 다시 시작합니다.이번에는
--skip-slave-start옵션없이 슬레이브를 다시 시작합니다.
글로벌 트랜잭션 식별자를 가지는 복제가 MySQL 5.6.7에서 도입되었습니다. GTID를 지원하지 않는 버전의 MySQL에서 지원하는 버전으로 기존의 복제 설치를 업그레이드하는 경우 GTID 기반 복제의 모든 요구 사항을 설치가 충족하는지 확인하기 전에 마스터 또는 슬레이브로 GTID를 사용하지 바랍니다. 섹션 17.1.3.2 "GTID를 사용한 복제 설정" 을 참조하십시오. GTID 기반 복제를 사용하기 위해 기존의 복제 설정을 변환에 대한 정보가 포함되어 있습니다.