MySQL 마스터-슬레이브 복제가 있습니다. 최근에 mysql 마스터가 호스팅되는 서버가 mysql과 관련이없는 문제로 인해 재부팅되었습니다. 서버가 작동 한 후 슬레이브와의 동기화가 끊어 졌다는 사실을 전혀 알지 못했습니다 (마스터 로그 파일 이름이 변경됨). 마스터 데이터베이스 구조를 업데이트하고 많은 데이터를 변경했습니다. ~ 24 시간 후에 우리는 슬레이브에 새로운 데이터 구조와 새로운 데이터가 없다는 것을 깨달았습니다. 동기화가 끊어졌습니다.
나는 지금 그것을 고치려고 노력하고 있지만 궁금합니다. 마스터 서버가 중지되었을 때 슬레이브 인스턴스가 자동으로 남아있는 곳을 선택하지 못하는 이유가 무엇입니까? 슬레이브 인스턴스가 마스터 서버가 다시 시작될 때 일어나는 일을 완전히 추적하지 않는 방식으로 구현 된 이유는 무엇입니까?
복제본이나 마스터가 다시 시작되면 복제본이 복구되어야합니다.
복제본에는 relay-log.info복제본이 처리 한 마지막 이벤트를 기록하는 라는 파일이 데이터 디렉토리에 있습니다. 대부분의 경우 이것은 잘 작동하며 복제본은 중단 된 지점에서 다시 시작할 수 있습니다.
그러나 여러 가지 문제가 발생할 수 있습니다.
복제본이 충돌하면 relay-log.info가 손상 될 수 있습니다. 이러한 이유로 MySQL 5.6에서는 이제 파일 대신 충돌 방지 InnoDB 테이블에 동일한 정보를 저장하는 옵션을 제공합니다.
복제본은 오랫동안 오프라인 상태 일 수 있습니다. 마스터가 복제본이 중지되었을 때 읽던 바이너리 로그 파일을 제거하면 복제본을 계속할 수 없습니다. 복제본은 연속 된 일련의 이벤트를 읽어야합니다. 그렇지 않으면 전체 데이터 복제를 보장 할 수 없습니다.
마스터가 충돌하면 마스터가 바이너리 로그 파일을 손상시킬 수 있습니다. sync-binlog마스터 에서 구성 변수를 사용하면 마스터에서 성능이 저하된다는 점을 이해 하고이 위험을 줄일 수 있습니다 .
"왜 그런 방식으로 구현 되는가"에 관해서는, 크래시로부터 복구 할 수있는 복제 시스템을 구현하는 것이 어떻습니까? 그리고 그것이 얼마나 쉬운 지 확인하십시오. :-)
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다