우리 조직은 백업을 최신 상태로 유지하고로드를 이상적으로 분산시키면서 서버를 지리적으로 분산시키는 방법을 모색하고 있습니다.
내가 생각한 첫 번째 것은 Rails on MySQL입니다. 쓰기 속도가 너무 높지 않습니다 (일부 매체는 큰 미디어 첨부 파일이 있지만 분당 1 개 미만으로 남음).
그래서,
답변:
우리는 여러 유럽 국가의 데이터 센터에서 복제를 사용하므로 (전세계에 걸쳐 있지는 않지만 확실히 지역이 아님) 아무런 문제없이 작동합니다.
가능하면 복제가 자동으로 다시 시작됩니다. 쿼리에 문제가있는 경우 (예 : 데이터베이스가 마스터에 존재하고 슬레이브가 아닌 쿼리에 사용) 기본적으로 수동 수정이 필요하지만 이러한 오류를 무시하도록 설정할 수 있습니다. 데이터베이스가 정확한 미러 인 경우 수동으로 복제를 다시 시작할 필요가 없습니다.
두 개의 서버가 있고 마스터가 사라지면 슬레이브를 '마스터'로 바꾸려면 복제를 중지하고 코드를 변경하여 새 '마스터'에 쓰십시오. 서버가 3 대 이상이고 마스터가 사라지면 슬레이브에서 복제를 중지하고 새 마스터를 사용하도록 변경 한 후 다시 시작하십시오. 정확하게 동기화되지 않은 경우 (전송되는 데이터 양, 서버 사용량, 네트워크 연결 상태 등에 따라 다름) 그보다 더 많은 작업을 수행해야 할 수도 있습니다. MySQL 문서의 복제 섹션에서이를 자세히 설명 합니다.
SSL을 통해 복제하고 있는지 확인하는 것이 좋습니다 (즉, 복제 사용자가 SSL 연결을 요구하도록 설정).
MySQL 5.1에서는 복제가 크게 변경되었습니다. 5.0에서는 명령문 기반 복제 만 사용되었습니다. 이제 행 기반 복제 또는 혼합 기반 복제를 수행 할 수 있습니다. 이는 WAN을 통한 복제 방법에 큰 영향을줍니다.
다음 중 하나를 수행 할 수있는 경우 : A) IP 인계 (서버가 지리적으로 분리 된 경우에는 가능성이 없습니다) B) 민첩한 DNS 변경 마스터를 변경하기 위해 앱 코드 / 구성을 수정하지 않아도됩니다. 우리는 짧은 캐싱과 가짜 .internal 도메인과 함께 내부 DNS를 사용합니다. masterdb.internal을 다른 서버로 변경해야하는 경우 5 초 안에 변경 사항이 적용됩니다.
단일 데이터 센터 내에서 IP 인수를 사용합니다. 모든 DB 서버에는 부팅시 가상 인터페이스 (eth0 : 1, eth0 : 2, eth0 : 3)가 없습니다. 슬레이브 중 하나를 인계해야하는 경우 eth0 : 2 만 있으면 마스터입니다. 이 시나리오에서 eth0은 우리가 쉘 등에 사용하는 'if'입니다. 응용 프로그램은 eth0 : 1에 연결되며, 스크립트에서 IP가 감지 된 경우 부팅시 활성화되지 않습니다. (wikipedia STONITH) 다른 경우는 장애 조치가 필요할 수있는 마스터의 IP를 인수하기위한 것입니다.