MySQL5.6 Statement-Based 및 Row-Based Replication의 장점 과 단점

17.1.2.1 Statement-Based 및 Row-Based Replication의 장점 과 단점

각각의 바이너리 로깅 형식으로 장점과 단점이 있습니다. 대부분의 사용자에게 데이터 무결성과 성능의 최고의 조합을 얻을 수는 혼합 복제 형식 인 것입니다. 그러나 특정 작업을 수행 할 때 문 기반 또는 열 기반 리플리케이션 포맷 고유의 기능을 이용하는 경우, 관련된 장점과 단점의 요약을 설명하는이 섹션의 정보를 사용하여 어느 요구에 적합하다 여부를 결정할 수 있습니다.

문 기반 복제의 이점
문 기반 복제의 단점
열 기반 리플리케이션의 장점
열 기반 리플리케이션의 단점

명령문 기반 복제의 이점

버전 3.23 이후 MySQL에 존재하는 입증 된 기술입니다.
로그 파일에 기록 된 데이터가 적습니다. 업데이트 또는 삭제가 많은 행에 영향을 미치는 경우 이로 인해 로그 파일에 필요한 스토리지 용량이 훨씬 적습니다. 즉, 백업 검색 및 복구를보다 빠르게 달성 할 수 있습니다.
로그 파일에는 변경된 모든 문이 포함되어 있기 때문에 데이터베이스의 감사에 사용할 수 있습니다.

명령문 기반 복제의 단점

SBR에게 안전하지 않은 문 데이터를 변경하는 모든 문 ( INSERT DELETE , UPDATE , REPLACE 문 등)를 문 기반 복제를 사용하여 복제 할 수있는 것은 아닙니다. 문 기반 복제를 사용하는 경우 비 결정적 동작은 복제가 어렵습니다. 그런 DML (데이터 수정 언어) 문의 예에는 다음이 포함됩니다.
- 비 결정적인 UDF 또는 저장 프로그램에 의존하는 문. 그런 UDF 또는 저장 프로그램에 의해 반환되는 값은 그에 제공된 매개 변수 이외의 요인에 의존하기 때문에. (단, 열 기반 리플리케이션은 UDF 또는 저장 프로그램에 의해 반환되는 값을 단순히 대체하는 테이블 행 및 데이터에 대한 그 영향은 마스터와 슬레이브 모두 동일합니다.) 자세한 내용은 섹션 17.4.1.11 "불려 기능의 복제 " 를 참조하십시오.
- ORDER BY 없이 LIMIT 절을 사용하여 DELETE 및 UPDATE 문은 비 결정적입니다. 섹션 17.4.1.16 "복제 및 LIMIT" 를 참조하십시오.
- 다음 중 하나의 함수를 사용하는 문은 문 기반 복제가 제대로 복제 할 수 없습니다.
  - LOAD_FILE()
  - UUID() , UUID_SHORT()
  - USER()
  - FOUND_ROWS()
  - SYSDATE() (마스터 및 슬레이브 모두 --sysdate-is-now 옵션으로 시작되는 경우를 제외합니다)
  - GET_LOCK()
  - IS_FREE_LOCK()
  - IS_USED_LOCK()
  - MASTER_POS_WAIT()
  - RAND()
  - RELEASE_LOCK()
  - SLEEP()
  - VERSION()
  그러나 NOW() 등을 포함하여 다른 모든 함수는 명령문 기반 리플리케이션에서 올바르게 복제됩니다.
  
  자세한 내용은 섹션 17.4.1.15 "복제와 시스템 함수" 를 참조하십시오.
문 기반 복제 제대로 복제 할 수없는 문은 여기에 나타나는 것과 같은 경고가 기록됩니다.
```
 [Warning] Statement is not safe to log in statement format.
```
이런 경우 비슷한 경고가 클라이언트에 발급됩니다. 클라이언트는 SHOW WARNINGS 을 사용하여 그것을 볼 수 있습니다.
INSERT ... SELECT 는 열 기반 리플리케이션보다 많은 행 수준 잠금이 필요합니다.
WHERE 절에 인덱스가 사용되지 않기 때문에 테이블 스캔을 필요로하는 UPDATE 문은 열 기반 리플리케이션의 경우보다 많은 행을 잠글 필요가 있습니다.
InnoDB 의 경우 : AUTO_INCREMENT 를 사용하는 INSERT 문은 충돌하지 않는 다른 INSERT 문을 차단합니다.
복잡한 문의 경우, 행이 갱신 또는 삽입되기 전에 슬레이브에서 문을 평가하고 실행해야합니다. 열 기반 리플리케이션의 경우, 슬레이브는 문 전체를 실행하는 것이 아니라, 영향을받는 행만 변경해야합니다.
노예의 평가에 오류가있을 경우, 특히 복잡한 문을 실행할 때 명령문 기반 리플리케이션은 영향을받는 행 전체 오류의 마진이 매우 천천히 증가 할 수 있습니다. 섹션 17.4.1.26 "복제중인 슬레이브 오류" 를 참조하십시오.
스토어드 함수는 호출 문과 동일 NOW() 값으로 실행합니다. 그러나 이것은 저장 프로 시저에는 적용되지 않습니다.
결정적인 UDF는 슬레이브에 적용되어야합니다.
테이블 정의는 마스터와 슬레이브로 (거의) 동일해야 안됩니다. 자세한 내용은 섹션 17.4.1.9 "테이블 정의가 다른 마스터와 슬레이브로 복제" 를 참조하십시오.

row 기반 리플리케이션의 장점

모든 변경 사항을 복제 할 수 있습니다. 이것은 가장 안전한 형태의 복제입니다.

mysql 데이터베이스는 복제되지 않습니다. 대신 mysql 데이터베이스는 노드 관련 데이터베이스로 볼 수 있습니다. 열 기반 리플리케이션이 데이터베이스의 테이블에서 지원되지 않습니다. 대신, GRANT , REVOKE 및 트리거, 스토어드 루틴 (저장 프로 시저를 포함) 및 뷰 작업 등 일반적이 정보를 업데이트하는 문은 문 기반 복제 슬레이브에 모두 복제됩니다.

CREATE TABLE ... SELECT 등의 문의 경우, CREATE 문은 테이블 정의에서 생성 된 명령문 기반 형식을 사용하여 복제되는 한편, 행 삽입 행 기반 형식을 사용하여 복제됩니다.
이 기술은 대부분의 다른 데이터베이스 관리 시스템과 동일합니다. 다른 시스템에 대한 지식은 MySQL에서 통용합니다.
마스터에 필요한 행 잠금은 적기 때문에 다음과 같은 유형의 문은 병렬성이 높아집니다.
- INSERT ... SELECT
- AUTO_INCREMENT 있는 INSERT 문
- 키를 사용하지 않거나 검사 된 행의 대부분을 변경하지 WHERE 절 함께 UPDATE 또는 DELETE 문.
INSERT , UPDATE 또는 DELETE 문의 경우, 슬레이브에 필요한 행 잠금이 적습니다.

row 기반 리플리케이션의 단점

RBR는 로그에 기록되어야하는 데이터가 늘어날 수 있습니다. 문 기반 복제는 DML 문 ( UPDATE , DELETE 문 등)를 복제하기 위해 문만 바이너리 로그에 기록합니다. 한편, 열 기반 리플리케이션에서 변경된 모든 행을 바이너리 로그에 기록합니다. 문이 많은 행을 변경하는 경우 열 기반 리플리케이션이 매우 많은 데이터를 바이너리 로그에 쓸 수 있습니다. 이것은 롤백되는 문에도 적용됩니다. 즉, 백업 검색 및 복구에 더 많은 시간이 걸릴 수 있습니다. 또한 데이터를 기록하기 위해 바이너리 로그가 잠길 시간이 길어지기 때문에 동시성 문제가 발생할 수 있습니다.
큰 BLOB 값을 생성하는 결정적 UDF의 경우 명령문 기반 리플리케이션보다 열 기반 리플리케이션 쪽이 복제에 시간이 걸립니다. 이것은 데이터를 생성하는 문이 아니라 BLOB 컬럼 값이 로그에 기록되기 때문입니다.
로그를 검사해서 어떤 문이 실행되었는지를 확인하지 못하고, 마스터에서 어떤 명령문이 도착하고 실행되었는지를 슬레이브로 확인할 수 없습니다.

그러나 옵션 --base64-output=DECODE-ROWS 및 --verbose 으로 mysqlbinlog를 사용하면 어떤 데이터가 변경되었는지 알 수 있습니다.
MyISAM 스토리지 엔진을 사용하는 테이블의 경우 INSERT 문을 행 기반 이벤트로 바이너리 로그에 적용 할 때 더 문으로 적용 할 때보 다 슬레이브에서 더 강한 잠금이 필요합니다. 이것은 MyISAM 테이블에 동시 삽입은 열 기반 리플리케이션을 사용할 때 지원되지 않는 것을 의미합니다.