LAMP를 실행하는 웹 앱이 있습니다. 최근에 우리는 부하가 증가했으며 이제는 확장 솔루션을 찾고 있습니다. Scaling apache는 꽤 간단합니다. 우리는 여러 개의 다중 머신을 호스팅하고 들어오는 트래픽을 라운드 로빈 할 것입니다.여러 머신으로 MySQL을 확장하는 방법은 무엇입니까?
그러나 아파치의 각 인스턴스는 MySQL과 대화하고 결국 MySQL에 과부하가 걸립니다. 이 설정에서 여러 머신으로 MySQL을 확장하는 방법은 무엇입니까? 나는 이미 this을 보았습니다. 그러나 특별히 우리는 복제본이 좋은 전략이라고 여기지 않는 DB로부터의 업데이트가 즉시 필요합니다. 또한 최소한의 코드 변경으로이 작업을 수행 할 수 있기를 바랍니다.
추신. 우리는 약 1 : 1의 읽기 - 쓰기 비율을 가지고 있습니다.
복제 및 샤딩이라는 두 가지 전략 만 있습니다. 쓰기가 적고 트래픽이 많을 때 복제가 자주 이루어지기 때문에 많은 복제 트래픽의 함정과 불일치 가능성이있는 읽기를 많은 슬레이브로 리디렉션 할 수 있습니다.
샤딩을 사용하면 여러 대의 컴퓨터에서 데이터베이스 테이블을 분할 할 수 있습니다 (기능 샤딩이라고 함). 특히 조인을 훨씬 더 어렵게 만듭니다. 이 작업이 더 이상 적합하지 않으면 여러 시스템에서 행을 분할해야하지만 재미가 없으며 응용 프로그램과 데이터베이스간에 구현되는 샤딩 계층에 따라 달라집니다.
문서 지향 데이터베이스 또는 열 저장소는이 작업을 수행하지만 현재 OLTP가 아닌 OLAP 용으로 최적화되어 있습니다.
복제가 최적의 전략은 아니라고 생각할 수도 있지만,이 도구를 사용하면 복제를 사용하여 여러 컴퓨터의 부하를 분산하는 데 도움이되는 매우 간단하고 간단한 팁을 제공하는 link을 살펴보십시오.
MySQL Performance Blog을 살펴 봐야합니다. 어쩌면 당신은 유용한 것을 발견 할 것입니다.
응용 프로그램 백엔드 (즉, PK, 트랜잭션 및 삽입 ID 처리 방법)에 따라 다른 auto_increment 설정으로 MASTER-MASTER 복제를 고려할 수 있습니다. 이것은 까다로울 수 있으며 철저한 테스트가 필요하지만 작동 할 수 있습니다.
또한 새로운 MySQL 5.6에는 일반적으로이 시나리오에서 특히 복제에서 동기화를 유지하는 데 많은 도움이되는 GTID (전역 트랜잭션 식별자)가 있습니다.
글쎄 ... 행운을 빕니다 모든 사람들이 진짜 큰 규모로 씁니다. 데이터베이스 엔진이 병목 현상을 일으키고 너무 많은 잠금 장치와 버퍼 관리 및 물건이됩니다. ...
실제로 작동하는 유일한 방법은 스케일 아웃, 샤딩입니다. 불행히도 샤딩은 MySQL에 "제공되지 않습니다." Mongo와 같은 일부 NoSQL에서와 같이). ScaleBase (면책 조항 : 내가 거기서 일함)은 원할 경우 "자동 샤딩 기계"라는 완벽한 스케일 아웃 솔루션을 제조하는 업체입니다. ScaleBae는 데이터와 SQL 스트림을 분석하고, DB 노드에서 데이터를 분할하고, 명령을 라우트하고, 결과를 런타임에 집계합니다. 그렇게하지 않아도됩니다!
링크가 끊어졌습니다. – sunnyrjuneja
링크를 업데이트 –
깨진 링크 bro .. – tesmojones