MySQL5.6 복제와 시스템 함수

17.4.1.15 복제와 시스템 함수

일부 함수는 조건에 따라 적절하게 복제되지 않습니다.

USER() , CURRENT_USER() (또는 CURRENT_USER ), UUID() , VERSION() 및 LOAD_FILE() 함수는 변경없이 복제되지만, 열 기반 리플리케이션이 활성화되어있는 경우를 제외하고 슬레이브에서 기능에 신뢰성이 없습니다. ( 섹션 17.1.2 "복제 형식" 을 참조하십시오.)

USER() 및 CURRENT_USER() 는 MIXED 모드 사용시에 열 기반 리플리케이션을 사용하여 자동으로 복제되어 STATEMENT 모드에서는 경고를 생성합니다. ( 섹션 17.4.1.7 "CURRENT_USER () 복제" 를 참조하십시오.) 이것은 VERSION() 및 RAND() 에도 적용됩니다.
NOW() 의 경우, 바이너리 로그는 타임 스탬프를 포함합니다. 이것은 마스터에서이 함수를 호출하여 리턴 된 값이 슬레이브에 복제되는 것을 의미합니다. 시간대가 다른 MySQL 서버간에 복제 할 때 예기치 않은 결과를 방지하려면 마스터와 슬레이브로 시간대를 설정하십시오. 섹션 17.4.1.30 "복제 및 시간대" 를 참조하십시오.

시간대가 다른 서버간에 복제 할 때 발생할 수있는 문제를 설명하기 위해 마스터는 뉴욕에 있으며, 슬레이브는 스톡홀름에 두 서버가 로컬 시간을 사용하는 것으로합니다 . 또한 여기에 같이 마스터에서 테이블 mytable 을 만들고이 테이블에서 INSERT 문을 실행 한 다음 테이블에서 선택해야합니다.
```
mysql> CREATE TABLE mytable (mycol TEXT);
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO mytable VALUES ( NOW() );
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
```
스톡홀름 현지 시간 뉴욕보다 6 시간 늦습니다. 따라서 슬레이브에서 SELECT NOW() 를 완전히 같은시기에 발행하면 값 2009-09-01 18:00:00 리턴됩니다. 따라서 위의 CREATE TABLE 과 INSERT 문이 복제 된 다음에는 mytable 노예 복사를 선택하면 mycol 값 2009-09-01 18:00:00 이 포함될 것으로 예상 할 수 있습니다. 그러나 이것은 그렇게되지 않습니다. mytable 노예 복사를 선택하면 마스터와 완전히 같은 결과가됩니다.
```
mysql> SELECT * FROM mytable;
+---------------------+
| mycol               |
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
```
SYSDATE() 함수는 NOW() 와 달리 복제에 안전하지 않습니다. 바이너리 로그에서 SET TIMESTAMP 명령문에 영향을받지 않고, 명령문 기반 로깅이 사용되는 경우는 비 결정적이기 때문입니다. 행 기반 로깅을 사용하는 경우이 문제가 아닙니다.

다른 방법은 --sysdate-is-now 옵션을 사용하여 SYSDATE() 가 NOW() 의 별칭입니다. 제대로 작동하려면 이것을 마스터와 슬레이브로해야합니다. 이런 경우에도이 함수는 경고가 발행되지만, --sysdate-is-now 가 마스터와 슬레이브로 사용되는 한 무시해도 안전합니다.

MySQL 5.5.1 이후에서는 SYSDATE() 는 MIXED 모드 사용시에 열 기반 리플리케이션을 사용하여 자동으로 복제되어 STATEMENT 모드에서 경고를 생성합니다. (Bug # 47995)

섹션 17.4.1.30 "복제 및 시간대" 를 참조하십시오.
다음의 제한은 문 기반 복제에만 적용되고 열 기반 리플리케이션에 적용되지 않습니다. 사용자 수준 잠금을 취급 GET_LOCK() , RELEASE_LOCK() , IS_FREE_LOCK() 및 IS_USED_LOCK() 함수는 슬레이브가 마스터에서 병렬 문맥을 모르고 복제됩니다. 따라서 슬레이브의 내용이 달라지기 때문에 이러한 함수를 사용하여 마스터 테이블에 삽입하지 마십시오. 예를 들어, INSERT INTO mytable VALUES(GET_LOCK(...)) 등의 문을 발행하지 마십시오.

MySQL 5.5.1 이후에서는 이러한 함수는 MIXED 모드 사용시에 열 기반 리플리케이션을 사용하여 자동으로 복제되어 STATEMENT 모드에서 경고를 생성합니다. (Bug # 47995)

문 기반 복제를 사용할 때 위의 제한 사항에 대한 해결 방법으로 문제가있는 함수 결과를 사용자 변수에 저장하여 후속 문에서 변수를 참조하는 방법을 사용할 수 있습니다. 예를 들어, 다음 줄로 INSERT 는 UUID() 함수를 참조하는 데 문제가 있습니다.

 INSERT INTO t VALUES (UUID ());

이 문제를 해결하려면 대신이를 실행하십시오.

 SET @my_uuid = UUID ();
 INSERT INTO t VALUES (@my_uuid);

이 문 연속 복제됩니다. @my_uuid 값을 INSERT 문 앞에 사용자 변수 이벤트로 바이너리 로그에 저장되어 INSERT 에서 사용할 수있는 것입니다.

동일한 개념이 여러 행 삽입에 적용되지만 사용하는 것이 귀찮습니다. 2 행 삽입의 경우 이렇게 할 수 있습니다.

 SET @ my_uuid1 = UUID (); @ my_uuid2 = UUID ();
 INSERT INTO t VALUES (@ my_uuid1) (@ my_uuid2);

그러나 줄 수가 많은지 알 수없는 경우이 해결 방법은 어렵거나 실용적이며 없습니다. 예를 들어, 다음 문을 개별 사용자 변수가 각 행에 연관된 것으로 변환 할 수 없습니다.

 INSERT INTO t2 SELECT UUID () * FROM t1;

스토어드 함수에서 RAND() 함수의 실행 중에 한 번만 호출되는 한, 제대로 복제됩니다. (함수 실행 타임 스탬프와 난수 시드를 마스터와 슬레이브로 같은 암시 적 입력으로 볼 수 있습니다.)

FOUND_ROWS() 와 ROW_COUNT() 함수가 문 기반 복제를 사용하여 복제 될 때 신뢰할 수 없습니다. 해결 방법은 함수 호출의 결과를 사용자 변수에 저장 한 후 INSERT 문에서 이것을 사용하는 것입니다. 예를 들어, mytable 이라는 테이블에 결과를 저장하는 경우, 보통은 다음과 같이 실행할 수 없습니다.

 SELECT SQL_CALC_FOUND_ROWS FROM mytable LIMIT 1;
 INSERT INTO mytable VALUES (FOUND_ROWS ());

그러나 mytable 을 복제하려면 다음과 같이 SELECT ... INTO 를 사용하고 변수를 테이블에 저장하는 것이 좋습니다.

 SELECT SQL_CALC_FOUND_ROWS INTO @found_rows FROM mytable LIMIT 1;
 INSERT INTO mytable VALUES (@found_rows);

이렇게함으로써 사용자 변수는 컨텍스트의 일부로 복제 된 슬레이브에서 제대로 적용됩니다.

이 함수는 MIXED 모드 사용시 열 기반 리플리케이션을 사용하여 자동으로 복제되어 STATEMENT 모드에서 경고를 생성합니다. (Bug # 12092, Bug # 30244)

MySQL 5.6.15 이전에는 --replicate-ignore-db 와 --replicate-do-table 등의 필터링 옵션이 슬레이브로 설정되어 있었을 경우, LAST_INSERT_ID() 의 값은 제대로 복제되지 않았습니다. (Bug # 17234370, BUG # 69861)