MySQL 마스터 - 슬레이브 복제의 신뢰성

Question

나는 애플리케이션의 많은 (100+) 슬레이브 복사본에 복사해야하는 약 30 개의 테이블의 마스터 카탈로그가 필요한 애플리케이션을 보유하고있다. 슬레이브는 자신의 DB 인스턴스에 있거나 단일 DB 인스턴스에 여러 개의 슬레이브가있을 수 있습니다. 마스터 카탈로그를 변경하면 합리적인 시간 (약 5 분) 내에 슬레이브에 복사해야합니다. 우리의 인프라는 모두 AWS EC2이며 MySQL을 사용합니다. 마스터와 슬레이브는 모두 단일 AWS 영역 내에 상주합니다.

마스터 - 슬레이브 복제를 사용할 계획 이었지만 때로는 신뢰할 수없는 MySQL 복제 보고서를보고 이것이 특정 구현이나 실패 자체에 내재 된 오류 때문인지 확실하지 않습니다. 고도로 자동화 된 안정적인 시스템이 필요하며, 슬레이브가 마스터와 관련하여 카탈로그를 지속적으로 모니터링 할 수 있도록 모니터링 스크립트를 개발해야 할 수도 있습니다.

관찰 결과가 있습니까?

Answer 1

결혼식 전에 댄스 레슨을하고있을 때 강사는 "모든 단계를 완벽하게 수행 할 필요가 없으며 실수로 실수했을 때 우아하게 회복하는 법을 배워야합니다. 너의 얼굴에 미소가있다. 아무도 눈치 채지 못할 것이다. "

100 명 이상의 노예가 있다면, 노예를 자주 다시 초기화 할 것입니다. 아마도 적어도 매일 1-2 명 정도는 다시 초기화해야 할 것입니다. 이것은 정상입니다.

모든 소프트웨어에 버그가 있습니다. 다른 무엇이든 기대하는 것은, 솔직히, 순진하다. 소프트웨어가 완벽하고 오류없이 계속 무휴로 운영 될 것이라고 기대하지 마십시오. 실망하게 될 것입니다. 완벽한 해결책을 찾지 말고, 무용가처럼 생각하고 우아하게 회복해야합니다.

MySQL 복제는 비교적 안정적이며 다른 솔루션보다 적습니다. 그러나 MySQL의 잘못이 아닌 다양한 실패가 발생할 수 있습니다.

• Binlog는 네트워크 글리치로 인해 전송되는 동안 손상된 패킷을 개발할 수 있습니다. MySQL 5.6에서는 이것을 탐지하기 위해 binlog 체크섬을 도입했습니다.

• 마스터 인스턴스가 충돌하여 이벤트를 binlog에 쓸 수 없습니다. sync_binlog은 커밋시 모든 트랜잭션이 binlog에 기록되도록 보장합니다 (트랜잭션 오버 헤드가 있음).

• 슬레이브 데이터는 비 결정적 SQL 문 또는 패킷 손상 또는 디스크의 로그 손상으로 인해 동기화되지 않거나 일부 사용자가 슬레이브에서 직접 데이터를 변경할 수 있습니다. Percona의 pt-table-checksum이이를 감지 할 수 있으며 pt-table-sync은 오류를 수정할 수 있습니다. binlog_format=ROW을 사용하면 비 결정적 변경 가능성을 줄일 수 있습니다. 슬레이브를 설정하면 read-only이 도움이 될 수 있으며 사용자가 SUPER 권한을 가질 수 없습니다.

• 리소스가 부족할 수 있습니다. 예를 들어 마스터 또는 슬레이브의 디스크를 채울 수 있습니다.

• 마스터에서 변경 사항을 따라갈 수없는 경우 슬레이브가 뒤 떨어질 수 있습니다. 슬레이브 인스턴스의 전원이 켜지지 않았는지 확인하십시오. binlog_format=ROW을 사용하십시오. 개별 MySQL 마스터에 대한 변경 사항을 적게 작성하십시오. MySQL 5.6은 멀티 쓰레드 슬레이브를 소개하지만, 지금까지는 약간의 버그가있는 경우를 보았으므로 신중하게 테스트 해보십시오.

• 슬레이브는 오랜 시간 동안 오프라인 일 수 있으며, 온라인 상태가되면 마스터의 일부 binlog가 만료되어 슬레이브가 중단 된 지점에서 연속적으로 이벤트 스트림을 재생할 수 없습니다.이 경우 슬레이브를 휴지통에 넣고 다시 초기화해야합니다.

• 버그는 모든 소프트웨어 프로젝트에서 발생하며 MySQL의 복제에는 공유가 있습니다. MySQL의 릴리스 노트를 계속 읽고 버그 수정을 이용하도록 업그레이드 할 준비를해야합니다.

대규모 데이터베이스 서버를 연속적으로 관리하는 것은 사용하는 데이터베이스 브랜드에 관계없이 많은 시간을 사용합니다. 그러나 데이터는 대부분의 비즈니스에서 피가되었습니다. 따라서이 리소스를 관리해야합니다. MySQL은 다른 어떤 브랜드의 데이터베이스보다 좋지도 않으며, 다른 사람이 당신에게 뭔가 다른 것을 말하면, 그들은 뭔가를 팔고 있습니다.

P .: 왜 고 가용성 또는 확장 성의 목표를 달성 할 수 있을지 예상하지 못했기 때문에 단일 AWS 영역에 100 대 이상의 슬레이브가 필요하다고 생각하는 이유가 궁금합니다.