18.1.3 MySQL Cluster 하드웨어, 소프트웨어 및 네트워크 요구 사항
MySQL Cluster의 장점 중 하나는 범용 하드웨어에서 실행할 수 있으므로 모든 라이브 데이터를 메모리에 저장하기 위해 많은 양의 RAM을 필요로하는 이외는 하드웨어에 대한 특별한 요구 사항이없는 것입니다. (디스크 데이터 테이블을 사용하여이 요구 사항을 줄일 수 있습니다. 자세한 내용은 섹션 18.5.12 "MySQL Cluster 디스크 데이터 테이블" 을 참조하십시오.) 당연히 여러 빠른 CPU를 사용하여 하면 성능이 향상됩니다. 다른 MySQL Cluster 프로세스의 메모리 요구 사항은 상대적으로 적은 양입니다.
MySQL Cluster 소프트웨어 요구 사항도 적습니다. 호스트 운영 체제에 MySQL Cluster를 지원하기 위해 특별한 모듈, 서비스, 응용 프로그램 또는 구성은 필요하지 않습니다. 지원되는 운영 시스템은 표준 설치 충분히 있어야합니다. MySQL 소프트웨어 요구 사항은 간단합니다. 필요한 것은 MySQL Cluster의 실전 출시뿐입니다. MySQL Cluster를 사용할 수 있도록하기 만한다면 반드시 MySQL를 직접 컴파일 할 필요는 없습니다. 여기에서는 사용자가 MySQL Cluster 소프트웨어 다운로드 페이지 ( http://dev.mysql.com/downloads/cluster/ )에서 제공하는 각자의 플랫폼에 적합한 바이너리를 사용하고 있다고 가정합니다.
노드 간 통신 내용은 MySQL Cluster는 표준 토폴로지의 TCP / IP 네트워크를 지원합니다. 각 호스트는 표준 100M 비트 / 초 Ethernet 카드가 있어야합니다. 또한 전체 클러스터의 네트워크 연결을 제공하기 위해 스위치, 허브 또는 라우터가 필요합니다. 다음과 같은 이유로 클러스터의 구성 요소가 아닌 컴퓨터와 공유하지 않는 별도의 서브넷에서 MySQL Cluster를 실행하는 것이 좋습니다.
보안 MySQL Cluster 노드 간의 통신은 암호화 및 보호가 전혀되지 않습니다. MySQL Cluster의 전송을 보호하는 유일한 방법은 MySQL Cluster를 보호 된 네트워크에서 실행하는 것입니다. MySQL Cluster를 Web 응용 프로그램을 위해 사용하는 경우 클러스터 네트워크의 비무장 지대 ( DMZ ) 등에 배치하지 않고 방화벽 뒤에 확실히 배치하도록하십시오.
자세한 내용은 섹션 18.5.11.1 "MySQL Cluster의 보안 및 네트워크 문제" 를 참조하십시오.
효율 MySQL Cluster를 개인 네트워크와 보호 된 네트워크에 설치하면 클러스터는 클러스터 호스트 사이의 대역폭을 독점적으로 사용할 수 있습니다. MySQL Cluster를위한 별도의 스위치를 사용하면 MySQL Cluster 데이터에 대한 무단 액세스로부터 보호 할뿐만 아니라 네트워크상의 다른 컴퓨터 간의 전송에 의해 발생하는 장애 MySQL Cluster 노드를 보호 할 수 있습니다. 신뢰성을 높이기 위해 듀얼 스위치와 듀얼 카드를 사용하여 단일 장애 지점이 네트워크를 제거 할 수 있습니다. 많은 장치 드라이버가 이러한 통신 링크 페일 오버를 지원합니다.
네트워크 통신 대기 시간 MySQL Cluster는 데이터 노드와 API 노드 (SQL 노드 포함) 사이 및 데이터 노드와 다른 데이터 노드간에 쿼리 나 업데이트를 실행하기 위해 통신을해야합니다. 이러한 프로세스 간 통신의 대기 시간은 사용자 쿼리의 관측 된 성능과 대기 시간에 직접적인 영향을 미칠 수 있습니다. 또한 노드의 자동 장애가 발생한 경우에도 일관성과 서비스를 유지하기 위해 MySQL Cluster는 장시간 노드에서의 통신의 상실을 노드 장애로 처리 하트 비트 및 타임 아웃 기능이 사용됩니다. 이것은 중복 저하로 이어질 수 있습니다. 노드 그룹의 마지막 노드에 장애가 발생하면 MySQL Cluster는 데이터의 일관성을 유지하기 위해 종료하는 것을 기억하십시오. 따라서 강제 종료의 위험을 증가시키지 말아야하기 위해 노드 간 통신 단절은 가능한 한 피해야한다.
데이터 노드 또는 API 노드에 장애가 발생하면 장애가 발생한 노드에 관련된 커밋되지 않은 모든 트랜잭션이 중단됩니다. 데이터 노드를 복구하려면 데이터 노드의 서비스를 재개하기 전에 장애가 발생한 노드의 데이터를 잔존하는 데이터 노드의 데이터와 동기화 디스크 기반 redo 로그와 검사 점 로그를 재 구축 할 필요 수 있습니다. 이 복구에 시간이 걸릴 수 있으며 그동안 클러스터는 중복이 저하 된 상태에서 작동합니다.
하트 비트는 모든 노드에서 하트 비트 신호가 지연없이 생성되는지 여부에 의존하고 있습니다. 노드에 과부하가 걸리거나 컴퓨터의 CPU가 다른 프로그램과 공유하는 데 불충분하거나 스와핑 지연이 발생하거나하면 이것은 불가능합니다. 하트 비트 생성 지연이 충분히 커지면 다른 노드는 응답이 느린 노드를 장애 노드로 취급합니다.
이러한 느린 노드를 장애 노드로 취급 할 노드의 느린 동작이 클러스터의 나머지 부분에 영향을 미치는 정도에 따라 원하는 경우와 그렇지 않은 경우가 있습니다. MySQL Cluster의 HeartbeatIntervalDbDb 과 HeartbeatIntervalDbApi 등의 제한 시간 값을 설정할 때 높은 비용 수있는 오판을 피하면서 신속한 감지, 페일 오버 및 서비스 재개가 실현되도록 배려해야합니다 .
데이터 노드 간의 통신 대기 시간이 LAN 환경에서의 예상치 (약 100 마이크로 초)보다 클 것으로 예상되는 경우에는 시간 제한 매개 변수를 늘려 허용하는 대기 시간이 구성한 시간의 범위에 충분히 맞는 있도록해야합니다. 이렇게 시간을 늘리면 가장 큰 장애물 감지 시간 및 (그 결과로) 서비스 복구 시간에도 유사한 효과가 있습니다.
LAN 환경은 일반적으로 안정된 작은 대기 시간으로 구성 할 수 있기 때문에 빠른 페일 오버 리던던시를 제공 할 수 있습니다. 개별 링크 장애는 TCP 수준에서 인식 할 수있는 최소한의 제어 된 (MySQL Cluster가 제대로 작동하려면) 대기 시간으로 복구 할 수 있습니다. WAN 환경에서는 대기 시간에 폭이 중복 대해서도 장애 조치 시간이 걸릴 수 있습니다. 개별 링크 오류는 엔드 투 엔드 연결을 복원하기 전에 루트 변경을 전파해야합니다. 이것은 TCP 수준에서 개별 채널의 큰 대기 시간으로 나타납니다. 이 시나리오에서는 최악의 경우에 관측되는 TCP 대기 시간은 IP 계층에서 오류를 방지하기 위해 실시되는 재 라우팅 최대 시간과 관련되어 있습니다.
SCI 지원 MySQL Cluster에 빠른 확장 코히 런트 인터페이스 (SCI)를 사용할 수도 있습니다 만, 이것은 필요 조건은 아닙니다. 이 프로토콜 및 MySQL Cluster에서의 사용에 대한 자세한 내용은 섹션 18.3.5 "MySQL Cluster에서의 고속 인터커넥트 사용" 을 참조하십시오.