MySQL 복제 복원 모범 사례

Question

아주 기본적인 마스터/슬레이브 설정에서 MySQL 복제를 설정하고 있습니다. 우리는 재해 복구가 아닌 서버 장애를 주로보고 있으며, 따라서 대부분 장애 조치에 관심이 있습니다. 우리의 모든 응용 프로그램은 PHP로되어 있기 때문에 MySQL 연결에서 뭔가 간단하게 설정하면 기본 데이터베이스를 연결할 수 없으면 파일을 작성하고 슬레이브로 페일 오버하고 그것을 사용하십시오.

내 문제는 장애 조치 후 데이터를 다시 동기화하는 것이 가장 좋은 방법이며, 더 좋은 해결책이있는 것입니다.

장애 조치 자체는 자동화해야하지만 복원 프로세스는 수동 일 수 있으며 WAN을 통해이를 수행하려고합니다. 난 정말 더 이상 명확하지 않다 마스터/슬레이브 아키텍처 대 마스터/마스터에 대한 책을 읽은 후 도움

편집

에 미리 감사가되는 설정은 내 시나리오에 가장 적합합니다. 데이터베이스 자체는 상당히 크며 (현재 정확한 크기가 아님) 주로 트랜잭션/로그 데이터를 나타냅니다 (사소한 인증 및 중복 검사 포함). 대부분의 행은 변경되지 않고 데이터베이스에만 추가됩니다.

복제 된 서버에 대한 주요 관심사/사용법은 장애 조치이므로 마스터 - 마스터 복제가 이러한 목적에 이상적으로 보이지만 실제로 장애 조치가 실제로 발생하면 해당 내용을 읽는 것이 좋습니다. 데이터베이스 B에 추가되면 마스터 - 슬레이브 관계보다 데이터베이스 A를 복원하는 것이 더 어려워 질 것입니다.

항목은 롤업/보관 중을 제외하고 어느 데이터베이스에서나 삭제되지 않으며이 시간 동안 마스터/슬레이브 설정에 대해 두 서버를 사용할 수 있는지 확인하기위한 기능을 추가 할 수 있습니다. 페일 오버가 발생한 재해 복구 상황에서는 매일 15-20 분의 복구 시간이 소요될 수 있지만 일관된 야간 기준은 아닙니다. 그 도움이 그 상황에 명확성을 가져 오기를 바랍니다.

Answer 1

여기에 많은 요소가 있습니다. 데이터베이스의 크기에 따라 변경된 내용 (IE에서 장애 조치 또는 MAX ID로 이동할 때 날짜/시간 저장)을 생성하는 알고리즘을 생성하고 해당 데이터를 사용하여 새 데이터베이스를 채울 수 있습니다. 삭제 된 항목으로 인해 문제가 발생할 수 있습니다. 항목이 실제로 삭제되고 삭제 된 날짜 만 설정되는 것은 아닙니다.

크기에 따라 유지 관리를 위해 15-30 분 동안 사이트를 종료하고 SQL 덤프를하고 테이블을 자르고 MySQL CLI 인터페이스를 통해 데이터를 다시 가져 오면 시간이 걸릴 수 있습니다 데이터에.

어느 쪽이 더 좋으며, 모두 필요에 따라 다릅니다. 후자의 경우, 유지 보수를 위해 사이트를 끌 수있는 곳으로 스크립트를 작성한 다음 FailOverServer에서 RegServer로 데이터를 가져 와서 일련의 MySQL 명령을 구현하여 RegServer를 자르고 일단 FailServer에서 데이터를 가져 오면 사이트를 다시 가동 할 수 있습니다.

나는 그것을 한 적이 없으므로 갈 길이 멀다. 하지만 FailOverServer에서 수정 된 테이블이 없으면 정상적으로 작동합니다.