반응형
17.3. 스토어드 프로시저, 함수, 트리거, 및 리플리케이션 : FAQ
MySQL 5.0의 스토어드 프로시저 및 함수를 리플리케이션과 함께 사용할 수 있습니까?
예, 스토어드 프로시저 및 함수에서 수행되는 표준 동작은 마스터 MySQL서버에서 슬레이브 서버로 복사본이 전달됩니다. 이 기능에는 몇 가지 제약 사항이 있으며, 자세한 내용은 Section 17.4, “스토어드 루틴과 트리거의 바이너리 로깅”을 참조하시기 바랍니다.
마스터 서버에서 생성된 스토어드 프로시저와 함수가 슬레이브 서버에 복사되어 집니까?
예, 마스터 서버상에서 정상적인 DDL명령문의 수행으로 생성된 스토어드 프로시저 와 함수는 슬레이브 서버로 복사본이 전달되며, 따라서 오브젝트는 양쪽 서버에 존재하게 됩니다. 스토어드 프로시저 및 함수에 대한ALTER 및 DROP;;;; 명령문 역시 복사 되어 집니다.
스토어드 프로시저 및 함수의 내부에서는 어떻게 복사가 이루어 집니까?
MySQL은 스토어드 프로시저에서 일어나는 각 DML 이벤트를 기록하고, 각 각의 개별 동작을 슬레이브 서버에 복사합니다. 스토어드 프로시저를 실행하는 실제 호출은 복사되지 않습니다.
데이터를 변경하는 스토어드 함수는 함수 호출(function invocation)로 로그 되어지고, 각 함수 내에서 발생하는 DML이벤트로 로그 되어지는 것은 아닙니다.
리플리케이션과 함께 스토어드 프로시저 및 함수를 사용하는데 있어서 특별히 보안적인 요구 사항이 필요합니까?
예. 슬레이브 서버가 마스터 서버의 바이너리 로그로부터 명령문을 읽기 위해서는 권한이 있어야 하기 때문에, 리플리케이션이 있는 스토어드 함수를 사용하기 위한 특정 보안 제약 사항이 있습니다. 만일 일반적인 상황(특정 시점 복구를 위해)에서 리플리케이션 또는 바이너리 로깅이 실행되면, MySQL DBA는 이것을 열기 위해 두 가지 보안 옵션을 가져야 합니다:
스토어드 함수를 생성하고자 하는 사용자는 반드시 SUPER 권한을 갖고 있어야 합니다.
다른 대안으로는, DBA이 log_bin_trust_function_creators 시스템 변수를 1로 설정할 수 있는데, 이렇게 하면 누구라도 표준 CREATE ROUTINE privilege권한을 갖고 스토어드 함수를 생성할 수 있게 됩니다.
Note: MySQL 5.0.16 이전에는, 이러한 제한 사항이 스토어드 프로시저에도 적용되었고 시스템 변수의 이름은log_bin_trust_routine_creators 입니다.
스토어드 프로시저와 함수의 동작을 복사하는 것에는 어떤 제약 사항이 있습니까?
스토어드 프로시저내에 임베디드 되어 있는Non-deterministic (랜덤) 또는 시간 기반 동작(time-based action)은 올바르게 복사되지 않을 수도 있습니다. 이러한 것들의 속성 때문에, 무작위로 생기게 되는 결과값은 예측할 수 없으며 정확히 재생산될 수도 없습니다. 따라서, 슬레이브에 복사되는 랜덤 동작은 마스터에서 수행되는 것과 장확히 미러(mirror)되지 않습니다. DETERMINISTIC으로 스토어드 함수를 선언하거나, log_bin_trust_function_creators 의 시스템 변수를 0으로 설정하는 것이 랜덤값 실행(random-valued opereation)을 호출하지 못하도록 하는 방법이라는 점을 알아두시기 바랍니다.
부가적으로, 스토어드 프로시저에 있는 이러한 동작들의 타이밍이 리플리케이션을 위해 사용된 바이너리 로그를 통해 재생산되지 않기 때문에 시간 기반 동작(time-based actions)은 슬레이브 상에서 재생산될 수 없습니다. 이것은 단지 이벤트만 기록하고 타이밍 제한치를 계산하는 것은 아닙니다.
마지막으로, 대단위 DML 동작(대량 삽입 같은)이 진행되는 동안 발생하는 에러를 위한 non-transactional 테이블은, DML동작으로부터 서버는 부분적으로 업데이트 되지만 에러로 인해 슬레이브는 업데이트가 되지 않는 리플리케이션 이슈를 경험할 수도 있습니다. 이 문제에 대한 대비책으로는 IGNORE키워드를 가지고 DML 행위를 하는 것인데, 이렇게 하면 에러를 유발하는 서버상의 업데이트는 무시되고, 에러를 유발하지 않는 업데이트는 슬레이브에 복사 되어 집니다.
앞에서 열거한 제약 사항으로 인해 MySQL의 특정 시간 복구(point-in-time) 기능이 영향을 받습니까?
리플리케이션에 영향을 주는 제한 사항은 특정 시간 복구에도 적용됩니다.
앞서 말한 제약 사항을 수정하기 위해 MySQL을 노력을 하고 있습니까?
MySQL 의 향후 버전에서는 리플리케이션을 어떻게 다룰 것인지에 대한 선택 방법을 제시할 것입니다:
명령문 기반 리플리케이션(Statement-based replication) (현 수행 방식).
로우 레벨(Row-level)리플리케이션(앞서 열거한 모든 제약 사항을 해결).
트리거는 리플리케이션과 같이 동작합니까?
Triggers and replication in MySQL 5.0에서 트리거와 리플리케이션은 다른 데이터 베이스 엔진에서와 똑같이 동작을 합니다: 마스터 서버상에서 트리거를 통해 수행되는 동작은 슬레이브에 복사되지 않습니다. 대신에, MySQL마스터 서버상에 있는 테이블에 존재하는 트리거는 MySQL슬레이브 서버위에 이에 대응하는 테이블을 생성할 필요가 있는데, 이렇게 하면 트리거는 서버뿐만 아니라 슬레이브에서도 동작을 하게 됩니다.
서버에 있는 트리거를 통해 슬레이브에 어떻게 복사가 되어 집니까?
첫 번째, 마스터에 존재하는 트리거는 슬레이브상에서 재생성 되어야 합니다. 일단 이것이 수행되면, 레프리케이션 플로우는 리플리케이션에 참여하는 다른 어떤 표준 DLM명령문처럼 동작을 합니다. 예를 들면, AFTER삽입 트리거를 갖고 있는 EMP 테이블이 있고, 이것이 MySQL 마스터 서버에 존재한다고 가정합니다. 동일한 EMP 테이블 및 AFTER 삽입 트리거는 슬레이브에도 역시 존재합니다. 리플리케이션 플로우는 다음과 같습니다:
INSERT 명령문으로 EMP를 만듬.
EMP상의 AFTER트리거가 동작함.
INSERT 명령문이 바이너리 로그에 쓰여짐.
리플리케이션 슬레이브가 INSERT 명령문을 가져와서 EMP 에 넣고 이것을 실행함.
슬레이브에 있는 EMP상의 AFTER 트리거가 동작을 함.
MySQL 5.0의 스토어드 프로시저 및 함수를 리플리케이션과 함께 사용할 수 있습니까?
예, 스토어드 프로시저 및 함수에서 수행되는 표준 동작은 마스터 MySQL서버에서 슬레이브 서버로 복사본이 전달됩니다. 이 기능에는 몇 가지 제약 사항이 있으며, 자세한 내용은 Section 17.4, “스토어드 루틴과 트리거의 바이너리 로깅”을 참조하시기 바랍니다.
마스터 서버에서 생성된 스토어드 프로시저와 함수가 슬레이브 서버에 복사되어 집니까?
예, 마스터 서버상에서 정상적인 DDL명령문의 수행으로 생성된 스토어드 프로시저 와 함수는 슬레이브 서버로 복사본이 전달되며, 따라서 오브젝트는 양쪽 서버에 존재하게 됩니다. 스토어드 프로시저 및 함수에 대한ALTER 및 DROP;;;; 명령문 역시 복사 되어 집니다.
스토어드 프로시저 및 함수의 내부에서는 어떻게 복사가 이루어 집니까?
MySQL은 스토어드 프로시저에서 일어나는 각 DML 이벤트를 기록하고, 각 각의 개별 동작을 슬레이브 서버에 복사합니다. 스토어드 프로시저를 실행하는 실제 호출은 복사되지 않습니다.
데이터를 변경하는 스토어드 함수는 함수 호출(function invocation)로 로그 되어지고, 각 함수 내에서 발생하는 DML이벤트로 로그 되어지는 것은 아닙니다.
리플리케이션과 함께 스토어드 프로시저 및 함수를 사용하는데 있어서 특별히 보안적인 요구 사항이 필요합니까?
예. 슬레이브 서버가 마스터 서버의 바이너리 로그로부터 명령문을 읽기 위해서는 권한이 있어야 하기 때문에, 리플리케이션이 있는 스토어드 함수를 사용하기 위한 특정 보안 제약 사항이 있습니다. 만일 일반적인 상황(특정 시점 복구를 위해)에서 리플리케이션 또는 바이너리 로깅이 실행되면, MySQL DBA는 이것을 열기 위해 두 가지 보안 옵션을 가져야 합니다:
스토어드 함수를 생성하고자 하는 사용자는 반드시 SUPER 권한을 갖고 있어야 합니다.
다른 대안으로는, DBA이 log_bin_trust_function_creators 시스템 변수를 1로 설정할 수 있는데, 이렇게 하면 누구라도 표준 CREATE ROUTINE privilege권한을 갖고 스토어드 함수를 생성할 수 있게 됩니다.
Note: MySQL 5.0.16 이전에는, 이러한 제한 사항이 스토어드 프로시저에도 적용되었고 시스템 변수의 이름은log_bin_trust_routine_creators 입니다.
스토어드 프로시저와 함수의 동작을 복사하는 것에는 어떤 제약 사항이 있습니까?
스토어드 프로시저내에 임베디드 되어 있는Non-deterministic (랜덤) 또는 시간 기반 동작(time-based action)은 올바르게 복사되지 않을 수도 있습니다. 이러한 것들의 속성 때문에, 무작위로 생기게 되는 결과값은 예측할 수 없으며 정확히 재생산될 수도 없습니다. 따라서, 슬레이브에 복사되는 랜덤 동작은 마스터에서 수행되는 것과 장확히 미러(mirror)되지 않습니다. DETERMINISTIC으로 스토어드 함수를 선언하거나, log_bin_trust_function_creators 의 시스템 변수를 0으로 설정하는 것이 랜덤값 실행(random-valued opereation)을 호출하지 못하도록 하는 방법이라는 점을 알아두시기 바랍니다.
부가적으로, 스토어드 프로시저에 있는 이러한 동작들의 타이밍이 리플리케이션을 위해 사용된 바이너리 로그를 통해 재생산되지 않기 때문에 시간 기반 동작(time-based actions)은 슬레이브 상에서 재생산될 수 없습니다. 이것은 단지 이벤트만 기록하고 타이밍 제한치를 계산하는 것은 아닙니다.
마지막으로, 대단위 DML 동작(대량 삽입 같은)이 진행되는 동안 발생하는 에러를 위한 non-transactional 테이블은, DML동작으로부터 서버는 부분적으로 업데이트 되지만 에러로 인해 슬레이브는 업데이트가 되지 않는 리플리케이션 이슈를 경험할 수도 있습니다. 이 문제에 대한 대비책으로는 IGNORE키워드를 가지고 DML 행위를 하는 것인데, 이렇게 하면 에러를 유발하는 서버상의 업데이트는 무시되고, 에러를 유발하지 않는 업데이트는 슬레이브에 복사 되어 집니다.
앞에서 열거한 제약 사항으로 인해 MySQL의 특정 시간 복구(point-in-time) 기능이 영향을 받습니까?
리플리케이션에 영향을 주는 제한 사항은 특정 시간 복구에도 적용됩니다.
앞서 말한 제약 사항을 수정하기 위해 MySQL을 노력을 하고 있습니까?
MySQL 의 향후 버전에서는 리플리케이션을 어떻게 다룰 것인지에 대한 선택 방법을 제시할 것입니다:
명령문 기반 리플리케이션(Statement-based replication) (현 수행 방식).
로우 레벨(Row-level)리플리케이션(앞서 열거한 모든 제약 사항을 해결).
트리거는 리플리케이션과 같이 동작합니까?
Triggers and replication in MySQL 5.0에서 트리거와 리플리케이션은 다른 데이터 베이스 엔진에서와 똑같이 동작을 합니다: 마스터 서버상에서 트리거를 통해 수행되는 동작은 슬레이브에 복사되지 않습니다. 대신에, MySQL마스터 서버상에 있는 테이블에 존재하는 트리거는 MySQL슬레이브 서버위에 이에 대응하는 테이블을 생성할 필요가 있는데, 이렇게 하면 트리거는 서버뿐만 아니라 슬레이브에서도 동작을 하게 됩니다.
서버에 있는 트리거를 통해 슬레이브에 어떻게 복사가 되어 집니까?
첫 번째, 마스터에 존재하는 트리거는 슬레이브상에서 재생성 되어야 합니다. 일단 이것이 수행되면, 레프리케이션 플로우는 리플리케이션에 참여하는 다른 어떤 표준 DLM명령문처럼 동작을 합니다. 예를 들면, AFTER삽입 트리거를 갖고 있는 EMP 테이블이 있고, 이것이 MySQL 마스터 서버에 존재한다고 가정합니다. 동일한 EMP 테이블 및 AFTER 삽입 트리거는 슬레이브에도 역시 존재합니다. 리플리케이션 플로우는 다음과 같습니다:
INSERT 명령문으로 EMP를 만듬.
EMP상의 AFTER트리거가 동작함.
INSERT 명령문이 바이너리 로그에 쓰여짐.
리플리케이션 슬레이브가 INSERT 명령문을 가져와서 EMP 에 넣고 이것을 실행함.
슬레이브에 있는 EMP상의 AFTER 트리거가 동작을 함.
반응형