MySQL용 확장 솔루션(복제, 클러스터링)

Question

에서 시작 저는 현재 데이터베이스에 대한 확장 솔루션을 고려하고 있습니다.(적어도 나에게는) MySQL을 사용하면 상황이 다소 혼란스러워집니다. MySQL 클러스터, 복제 그리고 MySQL 클러스터 복제 (ver.에서5.1.6) 이는 MySQL 클러스터의 비동기 버전입니다.MySQL 매뉴얼에서는 MySQL의 차이점 중 일부를 설명합니다. 클러스터 FAQ, 그러나 언제 둘 중 하나를 사용해야 하는지 확인하기는 어렵습니다.

이러한 솔루션 간의 차이점, 장단점이 무엇인지, 각 솔루션을 언제 사용하도록 권장하는지 잘 알고 있는 사람들의 조언을 주시면 감사하겠습니다.

Answer 1

사용 가능한 옵션에 대해 많은 읽기를 해왔습니다. 또한 고성능 MySQL 2nd Edition에 대한 손을 잡았습니다.

이것이 제가 함께 모은 것입니다.

클러스터링

일반적인 의미에서 클러스터링은 하나의 서버로 외부 응용 프로그램에 나타나는 많은 서버에 부하를 배포하는 것입니다.

MySQL NDB 클러스터

MySQL NDB 클러스터는 동기식 복제 및 자동 데이터 파티 닝을 갖춘 분산 된 메모리, 공유되지 않은 스토리지 엔진입니다 (고성능 책에서 문자 그대로 빌리는 실례하지만 매우 훌륭하게 넣었습니다). 일부 응용 프로그램의 고성능 솔루션이 될 수 있지만 웹 응용 프로그램은 일반적으로 잘 작동하지 않습니다.

주요 문제는 매우 간단한 쿼리를 넘어서 (하나의 테이블 만 터치하는) 클러스터는 일반적으로 여러 노드에서 데이터를 검색해야하므로 네트워크 대기 시간이 쿼리의 완료 시간을 크게 느리게 할 수 있다는 것입니다. 응용 프로그램은 클러스터를 하나의 컴퓨터로 취급하므로 데이터를 가져 오는 노드를 알 수 없습니다.

또한, 메모리 내 요구 사항은 많은 대형 데이터베이스에서는 작동하지 않습니다.

연속 세쿼이아

이것은 MySQL 서버 위에 미들웨어 역할을하는 MySQL의 또 다른 클러스터링 솔루션입니다. 동기식 복제,로드 밸런싱 및 장애 조치를 제공합니다. 또한 요청이 항상 최신 사본에서 데이터를 가져와 신선한 데이터가있는 노드를 자동으로 선택할 수 있습니다.

나는 몇 가지를 읽었다 좋은 일 그것에, 그리고 전반적으로 그것은 매우 유망하게 들립니다.

연합

연합은 클러스터링과 비슷하므로 여기에서도 잡아 당겼습니다. MySQL은 연합 스토리지 엔진을 통해 연맹을 제공합니다. NDB 클러스터 솔루션과 마찬가지로 간단한 쿼리만으로 잘 작동하지만 복잡한 클러스터의 클러스터는 더 나쁩니다 (네트워크 대기 시간이 훨씬 높기 때문에).

복제 및로드 밸런싱

MySQL은 다른 서버에서 데이터베이스의 복제를 생성 할 수있는 내장 용량을 가지고 있습니다. 이는 서버, 핫 백업간에로드를 분할, 테스트 서버 생성 및 장애 조치에 대해 여러 가지에 사용할 수 있습니다.

복제의 기본 설정에는 하나의 마스터 서버 처리가 대부분 쓰여지고 하나 이상의 노예 처리는 읽기 만 포함됩니다. 보다 진보 된 변형은 마스터 마스터 여러 서버를 동시에 쓰면서 쓰기를 확장 할 수있는 구성.

각 구성에는 장단점이 있지만 모두 공유하는 한 가지 문제는 복제 지연입니다. MySQL 복제는 비동기식이므로 모든 노드가 항상 가장 신선한 데이터를 가지고있는 것은 아닙니다. 이를 위해서는 응용 프로그램이 복제를 인식하고 예상대로 작동하기 위해 복제 인식 쿼리를 통합해야합니다. 일부 응용 프로그램의 경우 이것은 문제가되지 않을 수 있지만 항상 가장 신선한 데이터가 필요한 경우 다소 복잡해집니다.

복제는 노드 사이에로드를 분할하기 위해 약간의 부하 밸런싱이 필요합니다. 이는 응용 프로그램 코드를 일부 수정하거나 전용 소프트웨어 및 하드웨어 솔루션을 사용하는 것만 큼 간단 할 수 있습니다.

샤딩 및 파티 닝

샤딩은 일반적으로 데이터베이스 솔루션을 확장하는 데 사용되는 접근 방식입니다. 데이터를 작은 파편으로 분할하여 다른 서버 노드 주위에 퍼뜨립니다. 이를 위해서는 응용 프로그램이 필요한 정보를 어디서 찾을 수 있는지 알아야하므로 효율적으로 작업하기 위해 데이터 저장소의 수정을 인식해야합니다.

다음과 같은 데이터 샤딩을 처리하는 데 도움이되는 추상화 프레임 워크가 있습니다. 최대 절전 모드 파편, 최대 절전 모드 ORM의 확장 (불행히도 Java에 있습니다. PHP를 사용하고 있습니다). hivedb 샤드 재조정을 지원하는 또 다른 솔루션입니다.

기타

스핑크스

스핑크스 전체 텍스트 검색 엔진으로 테스트 검색보다 훨씬 더 많이 사용할 수 있습니다. 많은 쿼리의 경우 MySQL보다 훨씬 빠르며 (특히 그룹화 및 정렬의 경우) 원격 시스템을 병렬로 쿼리하고 결과를 집계 할 수있어 샤딩과 함께 사용하는 데 매우 유용합니다.

일반적으로 스핑크스는 다른 스케일링 솔루션과 함께 사용하여 사용 가능한 하드웨어 및 인프라를 더 많이 얻을 수 있어야합니다. 단점은 다시 스핑크스를 인식하려면 애플리케이션 코드가 현명하게 사용해야한다는 것입니다.

요약

스케일링 솔루션은 필요한 응용 프로그램의 요구에 따라 다릅니다. 우리와 대부분의 웹 응용 프로그램의 경우, 복제 (아마도 멀티 마스터)는로드 밸런서를 배포하는 방법이라고 생각합니다. 특정 문제 영역 (거대한 테이블)의 샤드는 또한 수평으로 확장 할 수 있어야합니다.

나는 또한 연속 세쿼이아에게 총을 맞고 응용 프로그램 코드에 대한 변경 사항이 가장 적기 때문에 실제로 약속하는 일을 할 수 있는지 확인할 것입니다.

Answer 2

면책 조항 : MySQL 클러스터를 사용하지 않았으므로 내가 들었던 것만으로 만갑니다.

MySQL 클러스터는 HA (고 가용성) 솔루션입니다. 그것은 모두 메모리에 있기 때문에 빠르지 만 실제 판매 지점은 가용성입니다. 단일 실패 지점은 없습니다. 반면에 복제를 사용하면 마스터가 내려 가면 실제로 복제본으로 전환해야하며 적은 양의 다운 타임이있을 수 있습니다. (DRBD 솔루션은 고 가용성이있는 또 다른 대안이지만)

클러스터는 전체 데이터베이스가 메모리에 맞아야합니다. 즉, 클러스터의 각 컴퓨터는 전체 데이터베이스를 저장하기에 충분한 메모리가 있어야합니다. 따라서 이것은 매우 큰 데이터베이스에 대한 실행 가능한 솔루션이 아닙니다 (또는 적어도 매우 비싼 솔루션).

HA가 매우 중요하지 않으면 (읽기 : 아마도), 그것은 가치보다 더 번거롭고 돈이라고 생각합니다. 복제는 더 종종 더 좋은 방법입니다.

편집하다: 또한 클러스터는 외래 키를 허용하지 않으며 범위 스캔은 다른 엔진보다 느립니다. 다음은 이야기하는 링크입니다 MySQL 클러스터의 알려진 한계

Answer 3

drupal.org를 유지하는 사람들이 데이터베이스 서버를 어떻게 구성했는지에 대한 좋은 토론이 있습니다.

• Buytaert의 블로그 건조
• Workhabits 블로그

둘 다 2007 년이므로 클러스터링 지원이 더 강해질 수 있지만 당시에는 복제를 선택했습니다.

Answer 4

복제를 수행하는 데있어 멋진 점은 쉽다는 것입니다. 2 개의 MySQL 상자를 설정하고 두 번째 상자에서 ServerID를 변경 한 다음 Change Master에서 명령을 사용하여 첫 번째 상자를 가리 킵니다.

다음은 관련 샘플 슬레이브 my.cnf config입니다

#
#       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만큼 득점을 받도록하십시오 (따라서 다음 슬레이브는 서버 3).

슬레이브가 연결할 수있는 사용자 이름과 비밀번호를 설정 한 다음 Change Master를 Master_host = 'xxxx'로 실행하십시오. 마스터를 Master_Password = "XXXXX"로 변경합니다.

등등.

마지막으로 "START SLAVE"를 실행하십시오.

Up은 당신의 노예와 복제를 시작합니다. 달콤한 응!

이는 빈 서버 2 개로 시작한다고 가정합니다. 그런 다음 DB를 마스터 서버에 버릴 수 있으며, 그곳에서로드되면 슬레이브에도로드됩니다.

실행하여 슬레이브 상태를 확인할 수 있습니다.

노예 상태 표시 g

재미있게 보내세요 .. soooo easy ...

Answer 5

고 가용성 연구를 수행하는 동안 나는 많은 솔루션을 발견했으며 아마도 우리의 경우 더 많은 쓰기 집중 시스템 인 아마도 DRBD 클러스터가 NDB 클러스터보다 더 많은 트랜잭션을 제공하기 때문에 더 나은 것을 발견했습니다.

MySQL Replication은 읽기 슬레이브로 사용할 수 있거나 재해 복구시 사용할 수있는 백업 머신을 제공 할 수 있습니다.

DRBD가 제공하는 트랜잭션 관리에 대한 다른 모드를 사용하면 네트워크를 통한 데이터 수준 복제로 인한 성능을 줄일 수 있습니다. 실패시 트랜잭션을 잃지 않아야하는 신뢰할 수있는 시스템의 경우 C 모드를 사용하면 B로갑니다.

DRBD 클러스터를 설정하는 동안 수행 한 학습 중 일부를 나열하려고했습니다. http://www.techiegyan.com/?p=132

복제를위한 전용 연결에서 실제로 잘 작동합니다. 즉, DRBD 복제를 위해 두 기계의 별도의 고속 인터페이스를 예약합니다. 하트 비트는 하나의 IP 주소, 파티션, DRBD 및 MySQL로 모든 서비스로 클러스터를 멋지게 제어 할 수 있습니다.

DRBD에서 마스터 마스터 구성을 아직 발견하지 못했습니다. 내가 성공할 때 업데이트 될 것입니다.

감사.

Answer 6

내 생각에는 혼란이 나를 다시 Mnesia로 보내는 것 같다.조각화, 인덱스 처리의 선언적이고 실용적인 방법, 데이터베이스 복제본 등의 위치 투명성

우리 설정에서는 MySQL Cluster와 Mnesia를 모두 실행합니다.우리의 데이터는 다소 계절적입니다.따라서 시간이 지나면 더 이상 사용되지 않는 데이터의 기억 상실증을 완화하여 MYSQL 클러스터에 넣습니다.이것은 우리의 기억 상실증을 효율적으로 유지합니다.또한 MySQL에서 직접 데이터를 사용하는 주요 스트림 언어(Python, Clojure 등)로 구현된 애플리케이션도 있습니다.

간단히 말해서 우리는 MySQL Cluster 위에서 mnesia를 실행합니다.MySQL 클러스터는 대규모 데이터 세트를 처리할 수 있으며 데이터베이스는 50GB 이상까지 확장될 수 있습니다.우리는 기억상실증에 힘입어 얼랭/OTP 응용 프로그램. 자바 그리고 PHP 맞춤형을 통해 기억 상실증의 데이터에 액세스 나머지 (최근에 절약) JSON 및 XML을 교환 형식으로 사용하는 API입니다.

데이터 액세스 계층은 필요한 경우 Mnesia의 데이터와 MySQL Cluster의 이전 제공 데이터에 대한 액세스를 추상화했습니다.Mnesia는 본질적으로 Erlang/OTP 애플리케이션을 강화하기 위해 여기에 있습니다. 데이터가 너무 많아지면 MYSQL 클러스터에 넣습니다.데이터 액세스 계층은 모든 애플리케이션을 대신하여 추상화된 API에서 Mnesia와 MySQL의 데이터에 모두 액세스할 수 있습니다.

여기서 제가 말할 수 있는 것은 Mnesia가 우리에게 최선의 선택이었다는 것입니다.테이블은 고도로 조각화되고 인덱싱되어 있으며 쿼리는 매우 잘 수행되며 데이터베이스는 터널을 통해 연결된 2개 위치에 복제됩니다.

이전에는 기억 상실증이 테이블 크기 제한으로 인해 가능한 많은 레코드를 처리하지 못할 수도 있다는 점을 우려했습니다.그러나 우리는 이 말이 틀렸다는 것을 알았습니다.좋은 조정(조각화)을 통해 우리의 기억력 상실 데이터베이스는 연간 평균 약 2억 5천만 개의 레코드를 보유합니다.

우리는 Erlang의 복잡한 데이터 구조와 Mnesia가 이를 그대로 받아들일 수 있다는 사실로부터 이익을 얻었습니다.Erlang/OTP 애플리케이션은 레거시 언어의 다른 모든 앱 중에서 가장 효율적이며 우리 시스템을 통해 모든 애플리케이션을 Erlang/OTP 기술로 마이그레이션할 계획입니다.Erlang에서 우리는 MySQL 클러스터의 데이터에 겉보기에 액세스하고 서버에 대한 쿼리를 매우 훌륭하게 실행합니다. 실제로 우리는 (Erlang) 대규모 동시성으로 인해 MySQL 서버 리소스를 완전히 사용할 수 있는 Erlang/OTP를 추론했습니다.

Mnesia는 우리에게 매우 효과적이었습니다. Mnesia는 놀라운 성능으로 인해 데이터베이스를 보는 방식을 완전히 바꿔 놓았습니다.우리의 Solaris 서버 CPU 코어는 피크 시간에 평균 약 48%의 사용량으로 바쁜 상태를 유지합니다.

Mnesia를 확인해 보시기 바랍니다. 이 프로그램이 여러분의 배포 또는 복제 요구 사항에 대한 답을 제공할 수 있다는 것을 누가 알겠습니까?

Answer 7

나는 그것들을 사용하지 않았지만 문서에서 가장 큰 부하가 데이터베이스에서 읽는 경우 복제가 선호되는 솔루션이라고 말합니다.

Answer 8

"메모리"제한은 거의 50GB의 데이터에 MySQL 클러스터를 사용하지 못하도록합니다. DRBD 플러스 리눅스 하트 비트.

데이터베이스 / 로그 / 구성을 동기화로 유지하는 두 개의 (또는 그 이상) 상자 사이의 RAID 배열과 비슷합니다 (그러나 한 번에 하나의 서버 만 가능할 수 있음). Failover는 자동이며 동일한 IP 주소를 사용하며 MySQL 재시작과 같은 빠르므로 우리에게 좋은 솔루션이었습니다.

Answer 9

MySQL 클러스터는 이상한 Beastie이며 우리가 평가할 때마다 매우 나쁘게 수행되거나 신뢰할 수 없습니다.

설정하는 것은 끔찍하게 복잡합니다 (최소한 3 개의 노드가 필요합니다). 또한 고객이 실패하는 조항은 없으므로 직접 수행해야합니다 (또는 프록시 등으로 행동하기 위해 다른 것을 사용해야합니다).

기본 키에서 자동 해시 파티셔닝을 수행하여 쓰기를 확장 할 수 있으며 단일 고장 지점이 없기 때문에 매우 영리합니다.

그러나 나는 그것이 그것이 설계된 매우 특별한 목적 사례에 더 적합하다고 생각합니다. 대부분의 경우 성능이나 기능에서 다른 데이터베이스 엔진 (예 : InnoDB)을 대체 할 수는 없습니다.