상기 시작 우리는 지금 우리의 데이터베이스에 대한 확장 솔루션을 고려하고있는에 내가 일하고 있어요. MySQL 클러스터 의 비동기 버전 인 MySQL 클러스터 , 복제 및 MySQL 클러스터 복제 (버전 5.1.6부터 )가있는 MySQL과 상황이 (적어도 저에게는) 다소 혼란스러워 집니다. MySQL 매뉴얼은 클러스터 FAQ 의 몇 가지 차이점을 설명 하지만 둘 중 하나를 사용할 때를 확인하기는 어렵습니다.
이러한 솔루션의 차이점과 장단점 및 각 솔루션을 언제 사용하는 것이 좋을지 잘 아는 사람들의 조언을 부탁드립니다.
답변:
사용 가능한 옵션에 대해 많이 읽고 있습니다. 저는 또한 제가 강력히 추천하는 고성능 MySQL 2 판을 손에 넣었습니다.
이것이 내가 함께 모을 수 있었던 것입니다.
일반적인 의미에서 클러스터링은 외부 응용 프로그램에 하나의 서버로 보이는 여러 서버에 부하를 분산하는 것입니다.
MySQL NDB 클러스터는 동기식 복제 및 자동 데이터 분할 기능이있는 분산 형 인 메모리, 비공유 스토리지 엔진입니다 (실례합니다. 저는 고성능 책에서 문자 그대로 빌 렸지만 거기에 아주 멋지게 배치했습니다). 일부 애플리케이션에서는 고성능 솔루션이 될 수 있지만 웹 애플리케이션은 일반적으로 제대로 작동하지 않습니다.
가장 큰 문제는 매우 단순한 쿼리 (하나의 테이블 만 터치)를 넘어 클러스터가 일반적으로 여러 노드에서 데이터를 검색해야하므로 네트워크 대기 시간이 증가하고 쿼리 완료 시간이 상당히 느려진다는 것입니다. 응용 프로그램은 클러스터를 하나의 컴퓨터로 취급하기 때문에 데이터를 가져올 노드를 알 수 없습니다.
또한 많은 대형 데이터베이스에 대해 메모리 내 요구 사항을 실행할 수 없습니다.
이것은 MySQL 서버에서 미들웨어 역할을하는 또 다른 MySQL 용 클러스터링 솔루션입니다. 동기식 복제, 부하 분산 및 장애 조치를 제공합니다. 또한 요청이 항상 최신 사본에서 데이터를 가져 와서 새로운 데이터가있는 노드를 자동으로 선택하도록합니다.
나는 그것에 대해 좋은 것을 읽었고 전반적으로 꽤 유망한 것처럼 들립니다.
페더레이션은 클러스터링과 비슷하므로 여기에서도 사용했습니다. MySQL은 연합 스토리지 엔진을 통해 연합을 제공합니다. NDB 클러스터 솔루션과 유사하게 단순한 쿼리에서만 잘 작동하지만 복잡한 쿼리의 경우에는 더 나쁩니다 (네트워크 지연 시간이 훨씬 더 높기 때문에).
MySQL에는 다른 서버에서 데이터베이스 복제를 생성 할 수있는 기능이 내장되어 있습니다. 이는 서버 간 부하 분할, 핫 백업, 테스트 서버 생성 및 장애 조치와 같은 많은 작업에 사용될 수 있습니다.
복제의 기본 설정에는 대부분 쓰기를 처리하는 하나의 마스터 서버와 읽기 전용을 처리하는 하나 이상의 슬레이브가 포함됩니다. 더 발전된 변형은 마스터-마스터 구성 의 변형으로 , 동시에 여러 서버를 작성함으로써 쓰기를 확장 할 수 있습니다.
각 구성에는 장단점이 있지만 모두가 공유하는 한 가지 문제는 복제 지연입니다. MySQL 복제는 비동기식이므로 모든 노드에 항상 최신 데이터가있는 것은 아닙니다. 이를 위해서는 애플리케이션이 복제를 인식하고 예상대로 작동하도록 복제 인식 쿼리를 통합해야합니다. 일부 응용 프로그램의 경우 이것은 문제가되지 않을 수 있지만 항상 최신 데이터가 필요하면 상황이 다소 복잡해집니다.
복제에는 노드간에로드를 분할하기 위해 일부로드 균형 조정이 필요합니다. 이는 애플리케이션 코드를 일부 수정하거나 전용 소프트웨어 및 하드웨어 솔루션을 사용하는 것처럼 간단 할 수 있습니다.
샤딩은 데이터베이스 솔루션을 확장하기 위해 일반적으로 사용되는 접근 방식입니다. 데이터를 더 작은 샤드로 분할하고 다른 서버 노드에 분산합니다. 이를 위해서는 애플리케이션이 필요한 정보를 찾을 수있는 위치를 알아야하므로 효율적으로 작동하기 위해 데이터 저장소의 수정 사항을 인식해야합니다.
Hibernate ORM의 확장 인 Hibernate Shards (안타깝게도 Java에 있습니다. 저는 PHP를 사용하고 있습니다) 와 같이 데이터 샤딩을 처리하는 데 도움이되는 추상화 프레임 워크가 있습니다 . HiveDB 는 샤드 재조정을 지원하는 또 다른 솔루션입니다.
Sphinx 는 전체 텍스트 검색 엔진으로, 테스트 검색보다 훨씬 더 많이 사용할 수 있습니다. 많은 쿼리의 경우 MySQL (특히 그룹화 및 정렬)보다 훨씬 빠르며 원격 시스템을 병렬로 쿼리하고 결과를 집계 할 수 있으므로 샤딩과 함께 사용할 때 매우 유용합니다.
일반적으로 사용 가능한 하드웨어 및 인프라를 더 많이 확보하려면 다른 확장 솔루션과 함께 스핑크스를 사용해야합니다. 단점은 스핑크스를 현명하게 사용하려면 애플리케이션 코드가 필요하다는 것입니다.
확장 솔루션은이를 필요로하는 애플리케이션의 요구 사항에 따라 다릅니다. 우리와 대부분의 웹 애플리케이션의 경우 복제 (아마 다중 마스터)가로드 밸런서를 사용하여로드를 분산하는 방법이라고 생각합니다. 특정 문제 영역 (거대한 테이블)의 분할도 수평으로 확장 할 수있는 필수 요소입니다.
또한 Continuent Sequoia에 대한 기회를 제공하고 애플리케이션 코드에 최소한의 변경을 포함 할 것이기 때문에 약속 한 것을 실제로 수행 할 수 있는지 살펴볼 것입니다.
면책 조항 : 저는 MySQL 클러스터를 사용하지 않았기 때문에 제가들은 내용에서만 진행하고 있습니다.
MySQL Cluster는 HA (고 가용성) 솔루션입니다. 그것은 모두 메모리에 있기 때문에 빠르지 만 실제 판매 포인트는 가용성입니다. 단일 실패 지점이 없습니다. 반면 복제의 경우 마스터가 다운되면 실제로 복제본으로 전환해야하며 약간의 다운 타임이있을 수 있습니다. (DRBD 솔루션은 고 가용성을 제공하는 또 다른 대안이지만)
클러스터를 사용하려면 전체 데이터베이스가 메모리에 맞아야합니다. 즉, 클러스터의 각 시스템에는 전체 데이터베이스를 저장할 수있는 충분한 메모리가 있어야합니다. 따라서 이것은 매우 큰 데이터베이스에 대해 실행 가능한 솔루션이 아닙니다 (또는 적어도 매우 비싼 솔루션입니다).
HA가 매우 중요하지 않다면 (아마도 그렇지 않을 것입니다), 가치보다 번거롭고 (돈이 많이) 더 많습니다. 복제가 더 나은 방법입니다.
편집 : 클러스터가 외래 키를 허용하지 않으며 범위 검색이 다른 엔진보다 느리다는 것도 언급하는 것을 잊었습니다. 다음은 MySQL 클러스터의 알려진 제한에 대해 설명하는 링크입니다.
drupal.org를 유지 관리하는 사람들이 데이터베이스 서버를 어떻게 구성했는지에 대한 몇 가지 좋은 토론이 있습니다.
둘 다 2007 년의 것이므로 클러스터링 지원이 지금은 더 강력 할 수 있지만 당시에는 복제를 선택했습니다.
복제에 대한 멋진 점은 쉽다는 것입니다. 2 개의 mysql 상자를 설정하고 두 번째 상자에서 serverID를 변경 한 다음 change master to 명령을 사용하여 첫 번째 상자에서 두 번째 상자를 가리 킵니다.
다음은 관련 샘플 슬레이브 my.cnf 구성입니다.
#
# Log names
#
log-bin=binlog
relay-log=relaylog
log-error=errors.log
#
# Log tuning
#
sync_binlog = 1
binlog_cache_size = 1M
#
# Replication rules (what are we interested in listening for...)
#
# In our replicants, we are interested in ANYTHING that isn't a permission table thing
#
replicate-ignore-db = mysql
replicate-wild-ignore-table=mysql.%
#
# Replication server ID
#
server-id = 2
따라서 각 슬레이브가 1 씩 증가하는 serverID를 가져야합니다 (따라서 다음 슬레이브는 서버 3).
슬레이브가 연결할 수있는 사용자 이름과 암호를 설정 한 다음 change master to MASTER_HOST = 'xxxx'를 실행합니다. 마스터를 MASTER_PASSWORD = "xxxxx"로 변경하십시오.
등등.
마지막으로 "start slave"를 실행하십시오.
노예가 나타나 복제를 시작합니다. 달콤한 허!
이것은 2 개의 빈 서버로 시작한다고 가정합니다. 그런 다음 db를 마스터 서버에 덤프 할 수 있으며 여기에서로드 될 때 슬레이브에도로드됩니다.
다음을 실행하여 슬레이브 상태를 확인할 수 있습니다.
슬레이브 상태 표시 \ G
재미있게 즐기세요 .. soooo 쉽게 ...
고 가용성 연구를 수행하는 동안 많은 솔루션을 발견했으며 아마도 쓰기 집약적 인 시스템 인 우리의 경우에는 DRBD 클러스터가 초당 더 많은 수의 트랜잭션을 제공하기 때문에 NDB 클러스터보다 더 나은 것을 발견했습니다.
Mysql Replication은 읽기 슬레이브로 사용되거나 재해 복구시 사용할 수있는 백업 머신을 제공 할 수 있습니다.
DRBD에서 제공하는 트랜잭션 관리에 대한 다양한 모드를 사용하면 네트워크를 통한 데이터의 장치 수준 복제로 인한 성능 저하를 줄일 수 있습니다. 장애 발생시 트랜잭션을 잃지 않는 안정적인 시스템을 위해서는 C 모드를 사용하고 그렇지 않으면 B로 이동하십시오.
http://www.techiegyan.com/?p=132 에서 DRBD 클러스터를 설정하는 동안 학습 한 내용 중 일부를 나열하려고했습니다 .
복제를위한 전용 연결에서 정말 잘 작동합니다. 즉, drbd 복제를 위해 두 시스템에서 별도의 고속 인터페이스를 예약합니다. Heartbeat는 IP 주소, 파티션, drbd 및 mysql과 같은 모든 서비스를 사용하여 클러스터를 멋지게 제어 할 수 있습니다.
DRBD에서 마스터-마스터 구성을 아직 발견하지 못했습니다. 내가 성공하면 업데이트됩니다.
감사.
제 생각에는 여기의 혼란이 저를 다시 Mnesia로 보냅니다. 조각화, 선언적이며 실용적인 인덱스 처리 방법, 데이터베이스 복제본의 위치 투명성 등
설정에서 MySQL 클러스터와 Mnesia를 모두 실행합니다. 우리의 데이터는 계절적입니다. 따라서 언젠가는 더 이상 사용되지 않는 데이터의 기억 상실을 완화하고이를 MYSQL 클러스터에 던집니다. 이것은 우리의 기억 상실증을 효율적으로 유지합니다. 또한 MySQL에서 직접 데이터를 사용하는 메인 스트림 언어 (Python, Clojure 등)로 구현 된 애플리케이션이 있습니다.
간단히 말해서, 우리는 MySQL Cluster 위에서 mnesia를 실행합니다. MySQL 클러스터는 대용량 데이터 세트를 처리 할 수 있으며 데이터베이스는 50GB 이상으로 증가 할 수 있습니다. Erlang / OTP 애플리케이션 을 지원하는 기억력이 있습니다 . Java 및 PHP는 JSON 및 XML을 교환 형식으로 사용 하는 맞춤형 REST (최근 Thrift ) API를 통해 mnesia의 데이터에 액세스합니다 .
데이터 액세스 계층은 Mnesia의 데이터에 대한 액세스를 추상화하고 필요한 경우 MySQL 클러스터의 이전 데이터에 액세스합니다. Mnesia는 본질적으로 Erlang / OTP 애플리케이션에 전력을 공급하기 위해 여기에 있으며, 데이터가 꽉 차면이를 MYSQL 클러스터에 넣습니다. 데이터 액세스 계층은 모든 애플리케이션을 대신하여 추상화 된 API에서 mnesia 및 MySQL의 데이터에 모두 액세스 할 수 있습니다.
제가 여기서 말할 수있는 것은 Mnesia가 우리에게 최고의 선택 이었다는 것입니다. 테이블은 매우 조각화되고 인덱싱되며 쿼리는 매우 잘 수행되며 데이터베이스는 터널을 통해 연결된 두 위치에 복제됩니다.
이전에는 기억 상실증이 테이블 크기 제한으로 인해 가능한 한 많은 레코드를 처리하지 못할 수 있다고 우려했습니다. 그러나 우리는이 진술이 잘못되었음을 발견했습니다. 좋은 튜닝 (조각화)을 통해 기억 상실 데이터베이스는 연간 평균 약 2 억 5 천만 개의 레코드를 보유합니다.
우리는 Erlang의 복잡한 데이터 구조와 Mnesia가 변경없이 그것을 삼킬 수 있다는 사실로부터 이익을 얻었습니다. Erlang / OTP 응용 프로그램은 레거시 언어로 된 다른 모든 응용 프로그램 중에서 가장 효율적이며 시스템을 통해 모든 것을 Erlang / OTP 기술로 마이그레이션 할 계획입니다. Erlang에서 우리는 MySQL Cluster의 데이터에 거의 액세스하지 않고 서버에서 쿼리를 매우 훌륭하게 실행합니다. 사실 우리는 (Erlang) 대규모 동시성으로 인해 MySQL 서버 리소스를 완전히 사용할 수있는 Erlang / OTP를 추론했습니다.
Mnesia는 우리에게 매우 잘 맞았고, 스릴 넘치는 성능으로 인해 데이터베이스를 보는 방식을 완전히 바 꾸었습니다. Solaris 서버 CPU 코어는 사용량이 많은 시간에 평균 약 48 % 사용량으로 바쁘게 유지됩니다.
기억력 상실을 확인하고 누가 알고 있는지 확인하는 것이 좋습니다. 배포 또는 복제 요구 사항에 답할 수 있습니다.
나는 그들을 사용하지 않았지만 문서에서 가장 큰 부하가 데이터베이스에서 읽는 경우 복제가 선호되는 솔루션이라고 말하고 싶습니다.
"메모리 내"제한으로 인해 거의 50Gb의 데이터에 대해 MySQL 클러스터를 사용할 수 없으므로 DRBD와 Linux Heartbeat를 사용하고 있습니다.
데이터베이스 / 로그 / 구성을 동기화 상태로 유지하는 두 개 (또는 그 이상의) 상자 사이의 레이드 배열과 비슷합니다 (하지만 한 번에 하나의 서버 만 "라이브"할 수 있음). 장애 조치는 자동이고 동일한 IP 주소를 사용하며 mysql 재시작만큼 빠르기 때문에 좋은 솔루션이었습니다.
MySQL 클러스터는 이상한 짐승이고 우리가 평가할 때마다 매우 나쁘게 수행되거나 신뢰할 수 없습니다.
설정하는 것은 끔찍하게 복잡합니다 (최소 3 개의 노드가 필요할 수 있습니다). 또한 클라이언트가 장애 조치를 수행하도록하는 조항이 없으므로 직접 수행해야합니다 (또는 다른 것을 사용하여 프록시 역할을하는 등).
쓰기를 확장 할 수있는 기본 키에서 자동 해시 파티셔닝을 수행하고 단일 실패 지점이 없기 때문에 매우 영리합니다.
그러나 나는 그것이 설계된 매우 특별한 목적의 경우에 더 적합하다고 생각합니다. 대부분의 경우 성능이나 기능면에서 다른 데이터베이스 엔진 (예 : InnoDB)을 대체 할 수 없습니다.