언제 마스터 - 슬레이브를 선호하고 클러스터링 할 때?

Question

데이터베이스 복제에 관한 많은 기사가 있습니다. 저를 믿으십시오, 나는 복제의 찬부 양론을 설명하는 this 이렇게 하나를 포함하여 그 기사를 읽는 언젠가를 보냈다. This는 SO 기사는 개별적으로 복제 및 클러스터링에 대해 깊이 간다,하지만 난이 간단한 질문에 대답하지 않습니다

이

1. 당신이 당신의 데이터베이스를 복제 할 때, 그리고 당신이 클러스터 않는 경우를?
2. 동시에 둘 다 수행 할 수 있습니까? 그렇다면 각각에 대한 영감은 무엇입니까?

미리 감사드립니다.

Answer 1

MySQL은 현재 고 가용성 환경을 만들고 다중 서버 확장 성을 구현하는 두 가지 솔루션을 지원합니다.

MySQL의 복제

첫 번째 형태는 MySQL은 MySQL 버전 3.23부터 지원하고 복제입니다. MySQL의 복제는 현재 논리 로그 전달 백엔드를 사용하는 비동기 마스터 - 슬레이브 설정으로 구현됩니다.

마스터 - 슬레이브 설정은 하나의 서버가 마스터로 작동하도록 지정되었음을 의미합니다. 그런 다음 모든 쓰기 조회를 수신해야합니다. 그런 다음 마스터는 쿼리를 실행 및 기록한 다음 쿼리를 실행하여 슬레이브로 보내 실행하고 모든 복제 멤버에서 동일한 데이터를 유지합니다.

복제가 비동기 적이므로 마스터가 변경을 수행 할 때 슬레이브 서버가 데이터를 가질 수 없음을 의미합니다. 일반적으로 복제는 가능한 한 실시간으로 수행됩니다. 그러나 변경이 슬레이브로 전파되는 데 필요한 시간은 보장 할 수 없습니다.

복제는 여러 가지 이유로 사용될 수 있습니다. 보다 일반적인 이유 중 하나는 확장 성, 서버 장애 조치 및 백업 솔루션에 대한 것입니다.

이제는 모든 슬레이브에서 SELECT 쿼리를 수행 할 수 있으므로 확장 성을 달성 할 수 있습니다. 그러나 쓰기 문은 각 복제 구성원에서 쓰기가 발생해야하므로 일반적으로 향상되지 않습니다.

장애 조치는 하트 비트 또는 유사한 메커니즘을 사용하여 마스터 서버의 장애를 감지하는 외부 모니터링 유틸리티를 사용하여 쉽게 구현할 수 있습니다. MySQL은 일반적으로 논리가 대개 응용 프로그램에 따라 다르기 때문에 현재 자동 장애 조치를 수행하지 않습니다. 복제가 비동기 적이기 때문에 마스터에서 수행 된 모든 변경 사항이 슬레이브로 전파되지 않을 가능성이 있습니다.

MySQL 복제는 느린 연결에서나 연속적이지 않은 연결에서도 매우 잘 작동합니다. 또한 다양한 하드웨어 및 소프트웨어 플랫폼에서 사용할 수 있습니다. MyISAM 및 InnoDB를 포함한 대부분의 스토리지 엔진에서 복제를 사용할 수 있습니다.

MySQL 클러스터

MySQL 클러스터는 공유 아무것도, 분산, 고 가용성 및 성능을 유지하기 위해 동기식 복제를 사용하여 파티션 시스템입니다.

MySQL 클러스터는 NDB Cluster라는 별도의 스토리지 엔진을 통해 구현됩니다. 이 스토리지 엔진은 여러 데이터 노드에 걸쳐 자동으로 데이터를 분할합니다. 데이터의 자동 파티셔닝은 실행되는 쿼리의 병렬화를 허용합니다. 쓰기가 여러 노드에 분산 될 수 있기 때문에 읽기와 쓰기 모두이 방식으로 확장 할 수 있습니다.

내부적으로 MySQL 클러스터는 시스템에서 단일 장애 지점 (single point of failure)을 제거하기 위해 동기식 복제를 사용합니다. 두 개 이상의 노드가 항상 데이터 조각을 가질 수 있으므로 적어도 하나의 노드는 실행중인 트랜잭션에 영향을주지 않고 실패 할 수 있습니다. 데드 노드가 애플리케이션에 투명하게 제거되면서 장애 탐지가 자동으로 처리됩니다. 노드를 다시 시작하면 클러스터에 자동으로 다시 통합되어 가능한 한 빨리 요청을 처리하기 시작합니다.

MySQL Cluster가 현재 상황에 적합한 솔루션인지를 결정할 때 현재 많은 제한 사항이 있습니다.

현재 MySQL 클러스터에 저장된 모든 데이터와 인덱스는 클러스터의 메인 메모리에 저장됩니다. 이렇게하면 클러스터에서 사용되는 시스템을 기반으로 데이터베이스의 크기가 제한됩니다.

MySQL 클러스터는 응답 시간에 대기 시간이 중요하기 때문에 내부 네트워크에서 사용하도록 설계되었습니다. 따라서 광범위한 지리적 거리에서 단일 클러스터를 실행할 수 없습니다. 또한 MySQL 클러스터는 일반 네트워크 설정을 통해 작동하지만 가능한 한 최고의 성능을 얻기 위해 특별한 클러스터링 상호 연결을 사용할 수 있습니다.

Answer 2

1. 마스터 - 솔브 구성에서 마스터는 쓰기 작업을 수행하고 슬레이브는 읽기 작업을 수행합니다. 따라서 모든 SQL 요청은 먼저 마스터에 도달하고 요청 큐가 유지되고 쓰기 작업이 완료된 후에 만 ​​읽기 작업이 실행됩니다. Master-Salve 구성에 공통적 인 문제가 있습니다. 마스터가 너무 커지면 마스터가 maintatined 할 수 없을 때이 아키텍처가 축소되고 슬레이브가 마스터처럼 작동하기 시작합니다. 클러스터의 경우 Cassandra에서 요청이 노드 (테이블)에 도달하고 커밋 해시가 유지되어 노드에 대한 차이점을 확인하고 해당 커밋 해시를 기반으로 다른 노드를 업데이트했습니다. 따라서 모든 작업은 단일 노드에 종속되지 않습니다.

쓰기 데이터의 크기가 크지 않은 경우 Master-Salve를 사용하고 그렇지 않은 경우 클러스터를 사용합니다. 클러스터는 공간이 비싸고 마스터 - 샐브 (Master-Salve) 시간이 너무 길기 때문에 선택할 대상에 대한 욕구는 저장하려는 대상에 따라 다릅니다.

2. 동시에 둘 다 사용할 수도 있습니다. 현재 회사에서이 작업을 수행했습니다. 대부분의 쓰기 작업이있는 테이블을 Cassandra로 옮겼으며 Cassandra의 테이블에 CRUD 작업을 수행하기 위해 4 개의 API를 작성했습니다. HTTP 요청이 올 때마다 우리 웹 서버에 처음 방문 할 때마다 우리 웹 서버에서 실행되는 코드에서 (CRUD 중) 수행해야 할 작업을 결정한 다음 해당 API를 호출하여 cassandra 데이터베이스를 변경합니다.