MySQL 아키텍처에 대한 간략한 분석

소개	데이터베이스는 모든 응용 시스템의 핵심이므로 데이터베이스의 안정적이고 효율적이며 안전한 운영을 보장하는 것은 모든 기업의 일상 업무에서 최우선 순위입니다. 데이터베이스 시스템에 문제가 발생하여 서비스를 제공할 수 없게 되면 전체 시스템이 계속 작동하지 못하게 될 수 있습니다. 따라서 성공적인 데이터베이스 아키텍처는 고가용성 설계도 충분히 고려해야 합니다. 아래에서는 가용성이 높은 MySQL 데이터베이스 시스템을 구축하는 방법을 소개하겠습니다.

데이터베이스는 모든 응용 시스템의 핵심이므로 데이터베이스의 안정적이고 효율적이며 안전한 운영을 보장하는 것은 모든 기업의 일상 업무에서 최우선 순위입니다. 데이터베이스 시스템에 문제가 발생하여 서비스를 제공할 수 없게 되면 전체 시스템이 계속 작동하지 못하게 될 수 있습니다. 따라서 성공적인 데이터베이스 아키텍처는 고가용성 설계도 충분히 고려해야 합니다. 아래에서는 가용성이 높은 MySQL 데이터베이스 시스템을 구축하는 방법을 소개하겠습니다.

DBA 또는 운영 및 유지 관리를 수행한 학생은 모든 장치 또는 서비스에 대한 단일 지점이 존재하면 엄청난 위험이 따른다는 것을 알아야 합니다. 왜냐하면 물리적 기계가 다운되거나 서비스 모듈이 충돌하면 짧은 시간 안에 교체품을 찾을 수 없기 때문입니다. 장비는 필연적으로 전체 애플리케이션 시스템에 영향을 미칠 것입니다. 따라서 단일 지점이 없도록 하는 방법이 우리의 중요한 작업입니다. MySQL 고가용성 솔루션을 사용하면 이 문제를 잘 해결할 수 있습니다.

1. MySQL의 자체 복제를 사용하여 고가용성을 달성하세요

MySQL과 함께 제공되는 복제는 우리가 흔히 마스터-슬레이브 복제(AB 복제)라고 부르는 것입니다. 마스터 서버용 슬레이브 머신을 만들어서 마스터 서버가 다운되었을 때 신속하게 슬레이브 머신으로 전환하여 업무를 보장할 수 있습니다. 응용 프로그램의 정상적인 사용. AB 복제를 사용하는 고가용성 솔루션도 여러 가지 아키텍처로 나뉩니다.

1. 기존 MASTER---SLAVE 솔루션

Ordinary MASTER---SLAVE는 현재 국내외 대부분의 중소기업에서 가장 일반적으로 사용되는 건축 솔루션입니다. 주요 장점은 단순성, 적은 장비(저비용) 및 손쉬운 유지 관리입니다. 이 아키텍처는 단일 지점 문제를 해결하고 시스템 성능 문제를 광범위하게 해결할 수 있습니다. MASTER 뒤에는 하나 이상의 SLAVE(마스터-슬레이브 계단식 복제)가 올 수 있습니다. 그러나 이 아키텍처에서는 MASTER가 시스템의 모든 쓰기 요청을 충족할 수 있어야 합니다. 그렇지 않으면 읽기 압력을 공유하기 위해 수평 분할이 필요합니다.

사진 1

사진 2
그림 1~2는 단일 지점 문제를 해결하고 읽기 및 쓰기 분리를 사용하여 성능을 향상시키는 프로세스를 보여줍니다.

2. DUAL MASTER와 캐스케이드 복제의 결합
이중 마스터와 다중 슬레이브는 위의 솔루션에서 파생된 보다 합리적인 솔루션입니다. 이 솔루션의 장점은 두 개의 메인 서버 중 하나에 장애가 발생하더라도 전체 아키텍처를 크게 조정할 필요가 없다는 것입니다.

사진 3

사진 4

사진 5

이 과정은 위 사진에 나와 있습니다. 하지만 그림 5의 상황은 매우 특별합니다. 즉, MASTER-B가 다운되면 어떻게 해야 할까요? 가장 먼저 결정할 수 있는 것은 모든 쓰기 요청이 어떤 식으로든 영향을 받지 않고 모든 읽기 요청에 정상적으로 액세스할 수 있지만 모든 슬레이브 복제가 중단되고 슬레이브의 데이터가 지연되기 시작한다는 것입니다. 이때 우리가 해야 할 일은 모든 슬레이브에 대해 CHANGE MASTER TO 작업을 수행하고 대신 마스터 A에서 복사하는 것입니다. 모든 슬레이브 복제는 원본 데이터 소스보다 앞서갈 수 없으므로 슬레이브의 릴레이 로그에 있는 타임스탬프 정보와 마스터 A의 타임스탬프 정보를 비교하여 정확한 복제 시작점을 찾아 데이터 손실을 방지할 수 있습니다.

2. MYSQL CLUSTER를 사용하여 전반적인 고가용성을 달성하세요

현재 MYSQL CLUSTER를 사용하여 전반적인 고가용성을 달성하는 솔루션(예: NDB CLUSTER)은 국내 기업에서는 그다지 인기가 없습니다. NDB CLUSTER 노드는 실제로 다중 노드 MySQL 서버이지만 데이터를 포함하지 않으므로 설치만 하면 어떤 머신에서나 사용할 수 있습니다. 클러스터의 SQL 노드가 충돌하더라도 해당 노드는 특정 데이터를 저장하지 않으므로 데이터가 손실되지 않습니다. 그림 6과 같이:

사진 6

3. MySQL 파생 상품을 통해 고가용성을 달성하세요

고가용성을 달성한 현재 MySQL 파생물 중에서 가장 잘 알려지고 인기 있는 것은 GALERA CLUSTER 및 PERCONA XTRDB CLUSTER(PXC)입니다. 관련 내용은 당분간 본 글에서 설명하지 않습니다. 관심 있는 학생은 관련 정보를 확인하여 자세히 알아볼 수 있습니다. 그림 7과 그림 8에 표시된 것처럼 이 두 클러스터의 구현 방법은 유사합니다.

사진 7

사진 8

4. 다양한 고가용성 솔루션의 장단점 비교

다양한 고가용성 설계 솔루션에 대한 이전 소개에서 독자들은 어떤 솔루션을 사용하든 고유한 장점이 있지만 어느 정도 한계도 있다는 것을 발견했을 것입니다. 이 섹션에서는 선택 과정에서 참고할 수 있도록 위의 주요 옵션의 장단점을 분석합니다.

1. MySQL 복제

장점: 간단한 배포, 손쉬운 구현 및 복잡하지 않은 유지 관리는 MySQL이 기본적으로 지원하는 기능입니다. 또한 활성 및 대기 시스템 간 전환이 쉽습니다. 활성 및 대기 전환은 타사 소프트웨어 또는 자체 작성 스크립트를 통해 자동으로 완료될 수 있습니다.

단점: 마스터 호스트 하드웨어에 장애가 발생하여 복원할 수 없는 경우 슬레이브로 전송되지 않은 일부 데이터가 손실될 수 있습니다.

2. MySQL 클러스터(NDB)

장점: 가용성이 매우 높고 성능이 매우 좋습니다. 각 데이터 조각은 서로 다른 호스트에 하나 이상의 복사본을 갖고 있으며 중복된 데이터 복사본은 실시간으로 동기화됩니다.

단점: 유지 관리가 더 복잡하고 제품이 최신이며 일부 버그가 있으며 현재 핵심 온라인 시스템에 적합하지 않을 수 있습니다.

3. GALERA 클러스터 및 PERCONA XTRDB 클러스터(PXC)

장점: 안정성이 매우 높습니다. 모든 노드는 동시에 모든 데이터를 읽고 쓸 수 있습니다. 서로 다른 호스트에 최소한 하나의 복사본이 있으며 중복된 데이터 복사본이 실시간으로 동기화됩니다.

단점: 클러스터 규모가 커질수록 성능은 점점 더 나빠집니다.

4. 꼭 언급해야 할 DRBD 디스크 네트워크 미러링 솔루션

아키텍처적으로 말하면 타사 소프트웨어를 통해 데이터 동기화 프로세스를 구현한다는 점을 제외하면 복제와 다소 유사하지만 복제보다 안정성이 높지만 성능도 희생됩니다.
장점: 소프트웨어는 강력하고 데이터는 기본 블록 장치 수준에서 물리적 호스트 전체에 미러링되며 성능 및 안정성 요구 사항에 따라 다양한 수준의 동기화를 구성할 수 있습니다. IO 작업은 데이터 일관성을 위한 데이터베이스의 엄격한 요구 사항을 충족할 수 있는 순서를 유지합니다.

단점: 비분산 파일 시스템 환경은 동시에 표시되는 미러 데이터를 지원할 수 없습니다. 즉, 성능과 안정성이 상충되며, 둘 다에 대해 엄격한 요구 사항이 있는 환경에는 적용할 수 없습니다. 유지 관리 비용은 MySQL 복제보다 높습니다.

일반적으로 사용되는 다양한 아키텍처의 장단점에 대해 이야기한 후 남은 질문은 실제 프로덕션 환경에서 사용할 적절한 아키텍처를 선택하는 방법입니다. 모든 사람은 이와 관련하여 자신만의 생각과 경험을 가지고 있으며 어떤 솔루션이 가장 좋은지는 의견의 문제입니다. 일상 업무에서 아키텍처 개선은 하룻밤 사이에 달성되는 것이 아니라 지속적인 진화, 최적화 및 개선의 과정을 통해 이루어집니다.

Gitui도 데이터베이스 측면에서 싱글 포인트부터 마스터-슬레이브, 마스터-슬레이브+고가용성까지의 과정을 경험했습니다. 또한 단일 MySQL+redis에서 MySQL+redis+es를 거쳐 현재의 MySQL+까지 경험했습니다. redis+es +코디스의 진화 등등. 모든 진화는 생산 환경의 실질적인 문제와 문제점을 해결하는 것입니다. MySQL만으로는 모든 문제(Pain Point)를 해결할 수 있는 아키텍처는 없으며, 실제 상황에 따라 적합한 아키텍처를 선택해야 합니다. MySQL 클러스터가 구현하는 솔루션은 매우 유연하고 변경 가능합니다. 이는 MySQL 작업자에게 적합한 아키텍처를 선택하는 것도 우리가 MySQL을 계속 연구하고 배우는 동기이기도 합니다.

위 내용은 MySQL 아키텍처에 대한 간략한 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!