Loading...
MySQL 9.5 Reference Manual 9.5의 19.2 Replication Implementation의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
19.2.1 Replication Formats
19.2.2 Replication Channels
19.2.3 Replication Threads
19.2.4 Relay Log and Replication Metadata Repositories
19.2.5 How Servers Evaluate Replication Filtering Rules
Replication은 source server가 자신의 데이터베이스들에 대한 모든 변경 사항(업데이트, 삭제 등)을 바이너리 로그에 기록하는 것을 기반으로 합니다. 바이너리 로그는 server가 시작된 순간부터 데이터베이스 구조 또는 콘텐츠(데이터)를 수정하는 모든 이벤트에 대한 기록으로 사용됩니다. 일반적으로, SELECT 구문은 데이터베이스 구조나 콘텐츠를 수정하지 않기 때문에 기록되지 않습니다.
Source에 연결하는 각 replica는 바이너리 로그의 사본을 요청합니다. 즉, source가 데이터를 replica로 푸시하는 것이 아니라 replica가 source에서 데이터를 풀합니다. Replica는 또한 자신이 수신한 바이너리 로그의 이벤트들을 실행합니다. 이는 source에서 이뤄졌던 원래 변경 사항들을 그대로 반복하는 효과를 냅니다. 테이블이 생성되거나 그 구조가 변경되고, 데이터는 source에서 원래 수행되었던 변경에 따라 삽입, 삭제, 갱신됩니다.
각 replica는 서로 독립적이기 때문에, source의 바이너리 로그로부터의 변경 사항 재생은 source에 연결된 각 replica에서 독립적으로 일어납니다. 추가로, 각 replica는 source로부터 요청을 통해서만 바이너리 로그의 사본을 받기 때문에, replica는 자신의 속도에 맞춰 데이터베이스 사본을 읽고 갱신할 수 있으며, replication 프로세스를 임의로 시작하고 중지할 수 있습니다. 이는 source나 replica 측에서 최신 데이터베이스 상태로의 업데이트 기능에 영향을 주지 않습니다.
Replication implementation의 세부 사항에 대한 더 많은 정보는 Section 19.2.3, “Replication Threads”를 참조하십시오.
Source server와 replica는 replication 프로세스와 관련된 상태를 정기적으로 보고하여, 사용자가 이를 모니터링할 수 있도록 합니다. 모든 replication 관련 상태에 대한 설명은 Section 10.14, “Examining Server Thread (Process) Information”를 참조하십시오.
Source의 바이너리 로그는 처리되기 전에 replica에서 로컬 릴레이 로그로 기록됩니다. Replica는 또한 source의 바이너리 로그와 로컬 릴레이 로그에서의 현재 위치에 대한 정보도 기록합니다. 자세한 내용은 Section 19.2.4, “Relay Log and Replication Metadata Repositories”를 참조하십시오.
데이터베이스 변경 사항은 이벤트 평가를 제어하는 다양한 구성 옵션과 변수에 따라 적용되는 일련의 규칙에 따라 replica에서 필터링됩니다. 이러한 규칙이 어떻게 적용되는지에 대한 자세한 내용은 Section 19.2.5, “How Servers Evaluate Replication Filtering Rules”를 참조하십시오.
19.1.7 Common Replication Administration Tasks
19.2.1 Replication Formats