MySQL 클러스터 아키텍처 고려 사항

Question

우리는 소프트웨어 담당자로서 일하고있는 프로젝트에서 다음 주에 새로 생성 된 WebApplication을 배포 할 예정입니다. 우리는 처음 6 개월 동안 높은 부하를 기대하지는 않지만, 확장 가능한 방식으로 시스템 아키텍처를 구축하고자합니다. 이 일반적이다 또는 잘 수행하는 경우 I는 생각을 가지고 있지만 확실하지 :

1. 내가 2 이상의 MySQL의 - NDB 클러스터 노드를 만들 것
2. 난에 MySQL의 프런트 엔드 서버와 2 개 이상의 웹 응용 노드를 만들 것 그것, ndb 저장 장치에 연결.
3. 만약 내가 새로운 webapplication 노드를 배포한다면, 항상 mysql 프론트 엔드 서버가 설치된 상태로 출하 될 것입니다. 따라서 모든 웹 응용 프로그램은 MySQL 연결을 위해 localhost에 연결됩니다.

나는 보안 고려 사항이 시나리오에서이 알고있다. 웹 응용 프로그램은 역방향 프록시 뒤에 있으며 외부에서 직접 액세스 할 수 없습니다.

이 시나리오에서 단점이 있습니까? 단지 이론적 인 질문입니다. 스토리지 계층에 NDB 노드보다 더 많은 프론트 엔드 MySQL 서버가 있다면 어떨까요?

Answer 1

큰 단점이 있다고 생각하지 마십시오. 프록시를 통과하기 위해 추가되는 대기 시간을 고려하십시오.

원하는만큼 많은 MySQL 서버를 추가 할 수 있지만 저장소/데이터 노드 수에 영향을 미치지 않습니다. 단순히 더 많은 클라이언트가 동시에 데이터/스토리지 노드에 쿼리를 푸시 할 수 있습니다. 데이터를 빠르게 쿼리하고 반환하려면 multi-thread storage node(ndbmtd)을 사용하는 것이 좋습니다.

은 또한 다음을 추천 :

• 가 추가 관리 노드 (ndb_mgmd)
• 는 데이터베이스 인프라에서 더 추상적 인 응용 프로그램에 전면에 SQL 노드/MySQL의 서버를 부하 분산 장치 추가를 추가합니다. 이것은 2 개의 이점을 가질 것이고, 하나의 SQL 노드가 다운 될 경우 애플리케이션을 재시작 할 필요가 없습니다. 애플리케이션에 미치는 영향을 최소화하면서 개별 SQL 노드를 업그레이드 할 수 있습니다.

당신이 블로그 게시물 읽어 시간을 절약 할 수 more.After 자신을 연구를하고 읽을 것인지 또한

:

MySQL CLuster 101 MySQL High Availability Architectures

을