마스터-마스터 대 마스터-슬레이브 데이터베이스 아키텍처?

117

두 종류의 데이터베이스 아키텍처에 대해 들었습니다.

마스터 마스터
주인 노예

마스터-마스터가 오늘날의 웹에 더 적합하지 않습니까? Git과 같고 모든 유닛에는 전체 데이터 세트가 있으며 하나가 다운 되더라도 중요하지 않습니다.

마스터-슬레이브는 일을 처리하는 하나의 중앙 장치가있는 SVN (내가 싫어하는)을 상기시킵니다.

질문 :

각각의 장단점은 무엇입니까?
iPhone과 같은 휴대폰에 로컬 데이터베이스를 갖고 싶다면 어느 것이 더 적합합니까?
이 중 하나를 선택하는 것이 철저하게 고려해야 할 중요한 요소입니까?

database

— never_had_a_name
소스

CAP Theorem-> Consistency Availability Partition Tolerance는 세 가지를 모두 함께 가질 수 없다고 말합니다. 응용 프로그램에 따라 둘 중 하나를 선택할 수 있습니다.

— Pritam Banerjee

답변:

우리는 가용성, 일관성 및 복잡성을 절충하고 있습니다. 마지막 질문을 먼저 해결하려면 : 이것이 중요합니까? 예 아주 많이! 데이터 관리 방법에 대한 선택은 절대적으로 기본이며 결정을 피하는 "모범 사례"가 없습니다. 특정 요구 사항을 이해해야합니다.

근본적인 긴장이 있습니다.

하나의 사본 : 일관성은 쉽지만 만약 다운되면 모든 사람들이 물에서 벗어나고 사람들이 멀리 떨어져 있으면 끔찍한 통신 비용을 지불 할 수 있습니다. 연결이 끊어진 상태로 작동해야하는 휴대용 장치를 사진으로 가져 오면 한 장으로도 잘리지 않습니다.

마스터 슬레이브 : 데이터의 각 부분에 정확히 하나의 소유 마스터가 있기 때문에 일관성이 그리 어렵지 않습니다. 하지만 그 주인이 보이지 않으면 어떻게해야하나요? 일종의 연기 된 작업이 필요합니다.

마스터-마스터 : 글쎄, 만약 당신이 그것을 작동시킬 수 있다면 그것은 모든 것을 제공하는 것 같고, 단일 실패 지점이 없으며, 모두가 항상 일할 수 있습니다. 이것의 문제점은 절대적인 일관성을 유지 하기가 매우 어렵다는 것입니다 . 자세한 내용은 wikipedia 기사 를 참조하십시오 .

위키 백과에는 장단점에 대한 멋진 요약이있는 것 같습니다.

장점

한 마스터가 실패하면 다른 마스터가 계속 데이터베이스를 업데이트합니다.

마스터는 여러 물리적 사이트에 위치 할 수 있습니다. 즉, 네트워크를 통해 분산됩니다.

단점

대부분의 다중 마스터 복제 시스템은 느슨하게 일관 적입니다. 즉, 지연 및 비동기 ACID 속성을 위반합니다.

Eager 복제 시스템은 복잡하며 통신 지연이 발생합니다.

충돌 해결과 같은 문제는 관련된 노드 수가 증가하고 필요한 지연 시간이 감소함에 따라 다루기 어려울 수 있습니다.

— djna
소스

CouchDB는 MVCC를 사용합니다. 이런 종류의 마스터가 다시 온라인 상태가되었을 때 여러 마스터가 직면하는 일관성 문제를 처리합니까? 버전 관리 시스템이 일관성을 처리하고이 마스터는 올바른 업데이트 된 데이터를 얻습니다.

— never_had_a_name

하지만 두 명의 사용자가 재고가있는 마지막 품목을 구매하려고하는 것처럼 두 명의 사용자가 모순 된 행동을하면 어떻게 될까요? 두 개의 마스터가 있고 각 사용자가 서로 다른 마스터를 공격하는 시나리오를 상상해보십시오. 그러면 일종의 통신 결함이 발생합니다. 결국 무결성이 손상되거나 가용성이 저하됩니다. 한 사용자가 "죄송합니다. 친구, 다른 스승과 대화 할 때까지 무슨 일이 일어나고 있는지 정말 모르겠습니다. "또는 통신이 복원 될 때 심각한 충돌이 발생합니다.이 문제는 정말 복잡해질 수 있습니다.

— djna

금융 거래 또는 주식 시장은 무엇을 사용합니까? 그들은 항상이 문제에 부딪 힐까요?

— CMCDragonkai

하나의 업데이트 된 "진실"(금융 시스템에서와 같이)이 필요한 경우 마스터 / 슬레이브 또는 실제로 마스터 만 필요합니다. 나중에 진실을 패치 할 수있는 곳 (Git과 같은 개정 제어 시스템의 병합 충돌을 생각해보십시오)에서 Master / Master를 사용할 수 있습니다.

— djna 2014-06-21

djna는 매우 눈에 띄는 관찰을합니다. 이제 데이터베이스에는 일종의 "타이 브레이커"논리가 있어야합니다. 가장 중요한 것은 무엇입니까? 가장 "최근"데이터? 필드를 다시 작성하는 경우 의미가 있지만 "카운터"를 수행하고 결과를 반환하기 전에 모든 프로세스를 증가 (또는 감소)해야하는 경우에는 의미가 없습니다. 특히 재고가없는 품목을 판매하지 않습니다. 네트워크 파티션이있는 경우 다시 합쳐지면 어떻게됩니까? 이 모든 것이 CAP 정리입니다. 여기에서 Paxos와 같은 알고리즘을 사용하여 서로 다른 시스템 간의 합의를 도출 할 수 있습니다.

— Peter Corless 2015-04-27

다양한 데이터베이스 아키텍처를 연구하면서. 나는 미래에 연구하는 다른 누군가와 관련이있을 수있는 좋은 정보를 수집했습니다. 나는 만났다

마스터-슬레이브 복제
마스터-마스터 복제
MySQL 클러스터

내 사용 사례에 MySQL Cluster를 사용하기로 결정했습니다. 그러나 내가 컴파일 한 다양한 장단점은 아래를 참조하십시오.

1. 마스터-슬레이브 복제

장점

분석 애플리케이션은 마스터에 영향을주지 않고 슬레이브에서 읽을 수 있습니다.
마스터에 상대적으로 영향을 미치지 않는 전체 데이터베이스 백업
슬레이브를 오프라인으로 전환하고 다운 타임없이 마스터와 다시 동기화 할 수 있습니다.

단점

장애가 발생한 경우 슬레이브를 마스터로 승격하여 대신해야합니다. 자동 장애 조치 없음
마스터 장애시 다운 타임 및 데이터 손실 가능성
모든 쓰기는 마스터-슬레이브 설계에서 마스터에 작성되어야합니다.
각 추가 슬레이브는 바이너리 로그를 읽고 각 슬레이브에 데이터를 복사해야하기 때문에 마스터에 약간의 부하를 추가합니다.
응용 프로그램을 다시 시작해야 할 수 있습니다.

2. 마스터-마스터 복제

장점

응용 프로그램은 두 마스터 모두에서 읽을 수 있습니다.
두 마스터 노드에 쓰기로드를 분산합니다.
간단하고 자동이며 빠른 장애 조치

단점

느슨하게 일관성
구성 및 배포가 마스터-슬레이브만큼 간단하지 않음

3. MySQL 클러스터

MySQL 클러스터 설계를 기반으로 한 새로운 아이. MySQL 클러스터는 고가용 성과 확장 성을 염두에두고 개발되었으며 가동 중지 시간, 높은 가용성 및 수평 확장 성이 필요한 환경에 사용하기에 이상적인 솔루션입니다.

자세한 내용은 MySQL Cluster 101 을 참조하십시오.

장점

(높은 가용성) 단일 실패 지점 없음
매우 높은 처리량
99.99 % 가동 시간
자동 샤딩
실시간 응답 성
온라인 운영 (스키마 변경 등)
분산 쓰기

단점

알려진 제한 사항 보기

언급 된 3 개의 아키텍처에 대한 추가 세부 사항으로 들어가는 아키텍처 다이어그램을 포함하여 내 블로그 전체 분석을 방문 할 수 있습니다 .

— Skillachie
소스

Galera에 대해서도 글을 쓸 수 있습니까? Percona XtraDB 클러스터?

— Ivanov

단점의 일부로 "응용 프로그램을 다시 시작해야 할 수 있습니다". 무슨 뜻인가요?

— Lily

DB 서버의 IP를 변경해야하는 경우 새로 선택한 마스터에서 읽을 수 있도록 응용 프로그램에서도 구성해야합니다. 따라서 새 구성 설정을 선택하려면 앱을 다시 시작해야 할 수 있습니다. 그것은 모두 현재 설정에 달려 있습니다. 유동 IP를 사용하여이를 우회 할 수도 있습니다. 일반적인 아이디어를 제공하기 위해

— Skillachie 2019