Oracle과 MySQL의 고가용성 솔루션 비교 분석-MySQL 튜토리얼-php.cn

Oracle과 MySQL의 고가용성 솔루션에 대해서는 사실 요약하고 싶었기 때문에 여러 시리즈에서 간략하게 이야기하겠습니다. 이 비교를 통해 두 데이터베이스 아키텍처 설계의 세부적인 차이점에 대한 기본적인 이해를 갖게 됩니다. Oracle은 매우 성숙한 솔루션을 보유하고 있습니다. OOW에 대한 내 ppt를 보면 MAA의 계획입니다. 올해가 이 계획의 16주년이 됩니다. 이 기사에서는 Oracle과 MySQL의 고가용성 솔루션에 대한 비교 분석을 주로 소개합니다. 매우 훌륭하고 도움이 필요한 친구들이 참고할 수 있습니다.

MySQL의 오픈 소스 특성으로 인해 커뮤니티에서는 더 많은 솔루션을 출시했습니다. 제 개인적인 의견으로는 InnoDB Cluster가 향후 MySQL의 표준 고가용성 솔루션이 될 것입니다.

현재는 MGR이 좋고, MySQL Cluster 솔루션, PXC, Galera 및 기타 솔루션도 있습니다. 개인적으로 저는 여전히 MHA를 선호합니다.

그래서 이 글은 RAC와 MHA부터 설명하겠습니다. . 기본 비교.

Oracle의 솔루션은 빠른 개발 기간 동안 Alibaba의 핵심 비즈니스 요구 사항을 지원했습니다. 아마도 이런 종류의 건축 시스템이 아닐까 싶습니다. 매우 거대해 보입니다. 내부의 RAC는 고가의 상업용 스토리지, 매우 높은 네트워크 대역폭 요구 사항, 수많은 프런트 엔드 소형 컴퓨터 서비스 및 고가의 라이센스 비용을 사용하는 귀족으로 간주됩니다. 매우 전형적인 IOE 클래식 아키텍처입니다.

원격 재해 복구를 고려하려면 자원 할당도 두 배, 예산도 두 배로 늘려야 합니다.

MySQL의 아키텍처 솔루션은 상대적으로 일반 PC이면 충분하지만 크기가 더 높습니다. 비즈니스 분할을 수행할 때 수평 분할은 많은 대형 인터넷 회사의 MySQL 클러스터 크기를 수평으로 확장할 수 있습니다. 모두 수백 또는 수백 규모이며 수천은 드문 일이 아닙니다. 서비스 리소스가 너무 많기 때문에 비즈니스 서비스에 대한 지속 가능한 액세스를 보장하는 것이 기술 솔루션의 핵심입니다. MHA 아키텍처를 따르면 MHA Manager 노드는 기본적으로 전체 클러스터의 상태를 담당합니다. 마치 주민에 대한 크고 작은 모든 것을 알고 있는 동네 위원회 이모와 같습니다.

물론 위의 설명은 너무 일반적이므로 몇 가지 세부 사항부터 살펴보겠습니다. 예를 들어 먼저 인터넷에 대해 이야기해 보겠습니다.

Oracle은 일반적으로 2개의 물리적 네트워크 카드가 필요합니다. 각 서버에는 최소 3개의 IP, 공용 IP, 개인 IP, VIP가 필요합니다.

사설 IP는 노드 간 상호 신뢰입니다. 공용 IP와 VIP는 동일한 네트워크 세그먼트에 있습니다. 쉽게 말하면 VIP는 공용 IP가 위치한 네트워크의 드리프트 IP입니다. 밸런싱 11g에는 스캔 IP가 포함되기 시작했고 원래 VIP는 여전히 유지되므로 Oracle의 네트워크 구성 요구 사항은 여전히 매우 높습니다. 공유 스토리지와 관계없이 구축의 핵심은 네트워크 구성이며, 네트워크는 일반적입니다.

scan-IP는 아래 그림과 같이 계속해서 확장 가능하며, 최대 3개의 scan-ip를 지원합니다.

물론, 네트워크 수준이 이에 국한되지는 않습니다. 이 점에서 하이라이트는 Oracle입니다. 우리는 TAF를 이해해야 합니다. 제 책 "Oracle DBA Work Notes"에서 저는 다음과 같이 썼습니다.

TAF(Transparent Application Failover)는 Oracle의 애플리케이션 투명 장애 조치로, 특히 RAC 환경에서 널리 사용됩니다. RAC의 로드 밸런스는 10g 버전부터 여러 VIP 주소의 로드 밸런스부터 11g 버전의 SCAN까지 대폭 개선되었습니다.

페일오버 구현에는 여전히 특정 사용 제한이 있습니다. 예를 들어 11g의 기본 SCAN-IP 구현에는 실제로 두 노드 중 하나가 끊어지면 원래 연결이 없습니다. 계속 쿼리하면 세션 연결이 끊어졌으므로 다시 연결해야 한다는 메시지가 표시됩니다. 클라이언트 TAF에서는 주로 Failover Method와 Failover Type에 대한 간단한 내용을 다루겠습니다.

(1)장애 조치 방법

장애 조치 방법의 주요 아이디어는 장애 조치 시간을 교환하거나 이를 달성하기 위해 리소스를 교환하는 것입니다.

이렇게 이해하면 됩니다. 세션이 노드 2에 연결되어 있는데 노드 2가 갑자기 끊길 경우 장애 조치 상황을 더 빠르게 처리하기 위해 장애 조치 방법에는 사전 연결과 기본의 두 가지 유형이 있습니다. .

— 사전 연결의 사전 연결 방법은 여전히 많은 리소스를 차지합니다. 각 노드에서 일부 추가 리소스를 미리 차지하므로 전환이 상대적으로 더 부드럽고 빠릅니다.

—기본 이 방법은 Failover가 발생할 때 해당 리소스를 전환하는 데 약간의 지연이 있지만 리소스 소비는 상대적으로 훨씬 적습니다.

간단히 말하면 기본 방법은 오류가 발생한 경우에만 판단하는 반면, 사전 연결은 실제 애플리케이션에서 비오는 날을 대비하는 것인데, 기본 방법은 더 다양하며 기본 장애 조치 방법이기도 합니다.

(2)장애 조치 유형

장애 조치 유형 구현은 더욱 풍부하고 유연하며 매우 강력합니다. 이때 제어 세분성은 사용자 SQL 실행에 따라 제어될 수 있으며 두 가지 유형이 있습니다. 간단한 예를 들어 보겠습니다.

예를 들어 노드 2에 큰 쿼리가 있는데 갑자기 노드 2가 중단됩니다. 예를 들어 쿼리를 실행하는 경우 10,000개의 데이터가 있는데 오류가 발생했을 때 8,000개가 발견되었습니다. 나머지 2,000개와 관련이 있습니다.

첫 번째 방법은 장애 조치를 완료하고 나머지 2,000개의 레코드를 계속 반환하는 선택을 사용하는 것입니다. 물론 중간에 일부 컨텍스트 전환이 발생하므로 이는 사용자에게 투명합니다.

두 번째 방법은 세션입니다. 즉, 직접 연결을 끊고 다시 쿼리하도록 요청하는 것입니다.

10g 버전에서 VIP 구성을 통해 Load Balance+Failover를 달성하기 위한 구성은 다음과 같습니다.

racdb=
(DESCRIPTION =
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.101)(PORT= 1521))
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.201)(PORT= 1521))
(LOAD_BALANCE = yes)
(FAILOVER = ON)
(CONNECT_DATA =
(SERVER= DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE= SELECT)
(METHOD= BASIC)
(RETRIES = 30)
(DELAY = 5))))
如果11g的SCAN-IP也想进一步扩展Failover，同样也需要设置failover_mode和对应的类型。
RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RACDB)
)
)

로그인 후 복사

이러한 관점에서 Oracle의 솔루션은 정말 정교합니다. MySQL의 솔루션을 살펴보겠습니다.

분산형 솔루션은 MySQL을 마치 스위스 칼처럼 보이게 만듭니다. 네트워크 수준 요구 사항과 관련하여 MySQL에는 마스터 1개와 슬레이브 1개를 신청하는 경우 IP 4개(마스터, 슬레이브)만 필요하다고 할 수 있습니다. VIP, MHA_Manager(매니저 노드로 간주)), 마스터 1개, 슬레이브 2개는 5개입니다.

현재 MySQL은 소위 로드 밸런싱을 기본적으로 지원하지 않습니다. 미들웨어 프록시를 사용하는 등 프런트 엔드 비즈니스를 통해 전환하거나 특정 세분화에 도달한 후 수행할 수 있습니다. 건축 설계를 통해 요구 사항을 충족합니다. 논리 기반 복제는 확장이 쉽기 때문에 하나의 마스터와 여러 개의 슬레이브가 매우 일반적이며 비용이 높지 않습니다. 지연은 0이라고 말할 수는 없지만 매우 낮으며 대부분의 인터넷 비즈니스 요구에 적응할 수 있습니다.

MHA 전환을 유발하는 조건에 대해 말하자면, 네트워크 관점에서 다음과 같은 빨간색 점은 잠재적인 위험입니다. 일부는 네트워크 중단이고 일부는 네트워크 지연입니다. 장애가 발생하면 데이터를 보호하든 안정적인 성능을 보장하든 둘 다입니다. 자신의 필요에 따라 맞춤 설정할 수 있습니다. 이러한 관점에서 보면 데이터가 손실될 가능성이 있습니다. 확실히 강력한 일관성을 지닌 무손실 복사본은 아닙니다.

두 가지 솔루션을 전체적으로 보면 RAC는 중앙 집중식 공유이며, 스토리지 수준의 공유 외에도 네트워크 수준의 멀티캐스트는 실제로 노드 간 통신 비용을 증가시키므로 RAC는 네트워크에 대한 수요가 큽니다. .지연이 있으면 위험하고 분할뇌가 당황스러울 수 있습니다. MySQL MHA의 솔루션이 배포됩니다. 대용량 환경을 지원하므로 노드 간 통신 비용이 상대적으로 낮습니다. 하지만 데이터 아키텍처 관점에서 볼 때 복제된 데이터 분산 방식이기 때문에 스토리지는 공유 스토리지가 아니지만 스토리지 비용은 여전히 RAC(스토리지 가격이 아니라 저장되는 데이터의 양)보다 높습니다.