Citymobil에서는 MySQL 데이터베이스를 주요 영구 데이터 저장소로 사용합니다. 우리는 다양한 서비스와 목적을 위한 여러 데이터베이스 클러스터를 보유하고 있습니다.

마스터의 지속적인 가용성은 전체 시스템과 개별 부품의 성능을 나타내는 중요한 지표입니다. 마스터 장애 발생 시 자동 클러스터 복구는 사고 대응 시간과 시스템 가동 중지 시간을 크게 줄여줍니다. 이 기사에서는 다음을 기반으로 하는 MySQL 클러스터의 고가용성(HA) 설계를 살펴보겠습니다. MySQL 오케스트레이터 및 가상 IP 주소(VIP).

VIP 기반 HA 솔루션

먼저, 당사의 데이터 저장 시스템이 무엇인지 간략하게 말씀드리겠습니다.

우리는 하나의 쓰기 액세스 가능한 마스터와 여러 개의 읽기 전용 복제본이 있는 클래식 복제 체계를 사용합니다. 클러스터에는 복제본이자 다른 노드의 마스터인 노드인 중간 마스터가 포함될 수 있습니다. 클라이언트는 HAProxy를 통해 복제본에 액세스하므로 로드 분산이 균일하고 확장이 용이합니다. HAProxy를 사용하게 된 것은 역사적인 이유 때문이며, 현재 ProxySQL로 마이그레이션을 진행 중입니다.

복제는 다음을 기반으로 반동기 모드로 수행됩니다. GTID. 이는 성공으로 간주되기 전에 적어도 하나의 복제본이 트랜잭션을 기록해야 함을 의미합니다. 이 복제 모드는 마스터 노드 오류가 발생할 경우 성능과 데이터 안전 간의 최적의 균형을 제공합니다. 기본적으로 모든 변경 사항은 다음을 사용하여 마스터에서 복제본으로 전송됩니다. Row Based Replication (RBR)하지만 일부 노드에는 mixed binlog format.

오케스트레이터는 주기적으로 클러스터 토폴로지 상태를 업데이트하고 수신된 정보를 분석하며 문제가 발생하면 자동 복구 절차를 시작할 수 있습니다. 절차는 VIP, DNS 기반, 서비스 검색 서비스 사용 또는 자체 작성 메커니즘 등 다양한 방식으로 구현될 수 있으므로 개발자는 절차 자체에 대한 책임이 있습니다.

마스터가 실패한 경우 마스터를 복원하는 간단한 방법 중 하나는 유동 VIP 주소를 사용하는 것입니다.

계속 진행하기 전에 이 솔루션에 대해 알아야 할 사항:

• VIP는 특정 물리적 네트워크 인터페이스와 연결되지 않은 IP 주소입니다. 노드에 장애가 발생하거나 예정된 유지 관리 기간 동안 가동 중지 시간을 최소화하면서 VIP를 다른 리소스로 전환할 수 있습니다.
• 가상 IP 주소를 해제하고 발급하는 것은 저렴하고 빠른 작업입니다.
• VIP를 사용하려면 SSH를 통해 서버에 액세스하거나 다음과 같은 특수 유틸리티를 사용해야 합니다. keepalived.

마법사에서 발생할 수 있는 문제를 살펴보고 자동 복구 메커니즘이 어떻게 작동해야 하는지 상상해 보겠습니다.

마스터와의 네트워크 연결이 끊어졌거나, 하드웨어 차원에서 문제가 발생하여 서버를 사용할 수 없는 경우

1. 오케스트레이터는 클러스터 토폴로지를 업데이트하고 각 복제본은 마스터를 사용할 수 없음을 보고합니다. 오케스트레이터는 새로운 마스터의 역할에 적합한 복제본을 선택하는 프로세스를 시작하고 복구를 시작합니다.
2. 우리는 이전 마스터에서 VIP를 제거하려고 시도하고 있지만 성공하지 못했습니다.
3. 복제본이 마스터 역할로 전환됩니다. 토폴로지를 다시 작성하는 중입니다.
4. VIP를 사용하여 새로운 네트워크 인터페이스를 추가합니다. VIP를 제거할 수 없었기 때문에 백그라운드에서 주기적으로 요청을 보내기 시작합니다. 무료 ARP. 이러한 유형의 요청/응답을 통해 연결된 스위치의 IP 및 MAC 주소 매핑 테이블을 업데이트하여 VIP가 이동했음을 알릴 수 있습니다. 이렇게 하면 가능성이 최소화됩니다. split brain 옛 주인을 되돌릴 때.
5. 모든 새로운 연결은 즉시 새로운 마스터로 리디렉션됩니다. 이전 연결이 실패하고 애플리케이션 수준에서 데이터베이스에 대한 반복 호출이 이루어집니다.

서버가 정상 모드로 작동 중인데 DBMS 수준에서 장애가 발생했습니다.

알고리즘은 이전 사례와 유사합니다: 토폴로지 업데이트 및 복구 프로세스 시작. 서버를 사용할 수 있으므로 이전 마스터에서 VIP를 성공적으로 해제하고 새 마스터로 전송한 후 여러 ARP 요청을 보냅니다. 이전 마스터의 반환 가능성은 재구축된 클러스터 및 애플리케이션 작동에 영향을 주어서는 안 됩니다.

기타 문제

복제본 또는 중간 마스터 오류 이끌지 않는다 자동 작업을 수행하고 수동 개입이 필요합니다.

가상 네트워크 인터페이스는 항상 임시로 추가됩니다. 즉, 서버 재부팅 후 VIP가 자동으로 할당되지 않습니다. 각 데이터베이스 인스턴스는 기본적으로 읽기 전용 모드에서 시작되며 오케스트레이터는 자동으로 새 마스터를 쓰기 모드로 전환하고 설치를 시도합니다. read only 옛 주인에게. 이러한 조치는 가능성을 줄이는 것을 목표로 합니다. split brain.

복구 프로세스 중에 문제가 발생할 수 있으며, 이는 표준 모니터링 도구 외에 오케스트레이터 UI를 통해서도 알려야 합니다. 이 기능을 추가하여 REST API를 확장했습니다(PR 현재 검토중).

HA 솔루션의 일반적인 다이어그램은 다음과 같습니다.

새로운 마스터 선택

오케스트레이터는 충분히 똑똑하고 선택을 시도합니다. 가장 적합한 복제품 다음 기준에 따라 새로운 마스터로 지정됩니다.

• 복제본은 마스터보다 뒤쳐집니다.
• 마스터 및 복제본의 MySQL 버전.
• 복제 유형(RBR, SBR 또는 혼합)
• 동일하거나 다른 데이터 센터의 위치
• 가용성 errant GTID — 마스터에는 없고 복제본에서 실행된 트랜잭션
• 사용자 정의 선택 규칙도 고려됩니다.

모든 큐가 마스터에게 이상적인 후보는 아닙니다. 예를 들어 복제본을 사용하여 데이터를 백업할 수 있거나 서버의 하드웨어 구성이 더 취약할 수 있습니다. 오케스트레이터 поддерживает 가장 선호하는 것부터 무시하는 것까지 후보자 선택 기본 설정을 사용자 정의할 수 있는 수동 규칙입니다.

응답 및 복구 시간

사고 발생 시 시스템 가동 중지 시간을 최소화하는 것이 중요하므로 오케스트레이터의 클러스터 토폴로지 생성 및 업데이트에 영향을 미치는 MySQL 매개변수를 고려해 보겠습니다.

• slave_net_timeout — 연결이 끊어진 것으로 인식되고 다시 연결되기 전에 복제본이 마스터에서 도착하는 새 데이터 또는 하트비트 신호를 기다리는 시간(초)입니다. 값이 낮을수록 복제본이 마스터와의 통신이 끊어졌음을 더 빨리 확인할 수 있습니다. 이 값을 5초로 설정했습니다.
• MASTER_CONNECT_RETRY — 재연결 시도 사이의 시간(초)입니다. 네트워크 문제가 발생한 경우 이 매개변수의 값이 낮으면 빠르게 다시 연결할 수 있으며 클러스터 복구 프로세스가 시작되지 않습니다. 권장 값은 1초입니다.
• MASTER_RETRY_COUNT — 최대 재연결 시도 횟수.
• MASTER_HEARTBEAT_PERIOD — 마스터가 하트비트 신호를 보내는 간격(초)입니다. 기본값은 절반 값 slave_net_timeout.

오케스트레이터 매개변수:

• DelayMasterPromotionIfSQLThreadNotUpToDate - 같다면 true, 그러면 복제본의 SQL 스레드가 릴레이 로그에서 적용되지 않은 모든 트랜잭션을 완료할 때까지 마스터 역할이 후보 복제본에 적용되지 않습니다. 모든 후보 복제본이 뒤쳐질 때 트랜잭션 손실을 방지하기 위해 이 옵션을 사용합니다.
• InstancePollSeconds — 토폴로지를 구축하고 업데이트하는 빈도.
• RecoveryPollSeconds - 토폴로지 분석 빈도. 문제가 감지되면 토폴로지 복구가 시작됩니다. 이것 일정한, 1초와 같습니다.

각 클러스터 노드는 오케스트레이터에 의해 한 번씩 폴링됩니다. InstancePollSeconds 초 문제가 감지되면 클러스터 상태가 강제됩니다. 업데이트, 복구를 수행하기로 최종 결정이 내려집니다. 다양한 데이터베이스 및 오케스트레이터 매개변수를 실험하여 응답 및 복구 시간을 30초로 줄일 수 있었습니다.

테스트 벤치

우리는 로컬 개발로 HA 체계를 테스트하기 시작했습니다. 테스트 벤치 테스트 및 생산 환경에서의 추가 구현. 로컬 스탠드는 Docker 기반으로 완전 자동화되어 있어 오케스트레이터 및 네트워크 구성을 실험하고, 클러스터를 2~3개 서버에서 수십 개로 확장하고, 안전한 환경에서 연습을 수행할 수 있습니다.

연습 중에 문제가 있는 에뮬레이션 방법 중 하나를 선택합니다. kill -9, 프로세스를 부드럽게 종료하고 서버를 중지합니다(docker-compose stop), 다음을 사용하여 네트워크 문제를 시뮬레이션합니다. iptables -j REJECT 또는 iptables -j DROP. 우리는 다음과 같은 결과를 기대합니다:

• 오케스트레이터는 마스터의 문제를 감지하고 10초 이내에 토폴로지를 업데이트합니다.
• 복구 절차가 자동으로 시작됩니다. 네트워크 구성이 변경되고 마스터의 역할이 복제본으로 전달되며 토폴로지가 다시 구축됩니다.
• 새 마스터는 쓰기 가능해지며 재구축 프로세스 중에 라이브 복제본이 손실되지 않습니다.
• 데이터가 새 마스터에 기록되고 복제되기 시작합니다.
• 총 복구 시간은 30초를 넘지 않습니다.

아시다시피 시스템은 하드웨어 및 네트워크 구성의 차이, 합성 로드와 실제 로드의 차이 등으로 인해 테스트 및 프로덕션 환경에서 다르게 작동할 수 있습니다. 따라서 우리는 실제 상황에서 정기적으로 훈련을 실시하여 네트워크 연결이 끊어지거나 개별 부품의 성능이 저하될 때 시스템이 어떻게 작동하는지 확인합니다. 앞으로 우리는 두 환경 모두에 대해 완전히 동일한 인프라를 구축하고 테스트를 자동화하려고 합니다.

조사 결과

기본 스토리지 시스템 노드의 상태는 SRE 및 운영팀의 주요 목표 중 하나입니다. VIP 기반의 오케스트레이터와 HA 솔루션을 구현하여 다음과 같은 결과를 얻을 수 있었습니다.

• 데이터베이스 클러스터의 토폴로지 문제를 안정적으로 감지합니다.
• 마스터 관련 사고에 자동으로 신속하게 대응하여 시스템 가동 중지 시간을 줄입니다.

그러나 이 솔루션에는 다음과 같은 한계와 단점이 있습니다.

• HA 체계를 여러 데이터 센터로 확장하려면 이들 사이에 단일 L2 네트워크가 필요합니다.
• 새 마스터에 VIP를 할당하기 전에 이전 마스터에서 이를 해제해야 합니다. 프로세스는 순차적이므로 복구 시간이 늘어납니다.
• VIP를 해제하려면 서버에 대한 SSH 액세스 또는 원격 절차를 호출하는 다른 방법이 필요합니다. 서버 또는 데이터베이스에 복구 프로세스를 유발하는 문제가 발생했기 때문에 VIP 제거가 성공적으로 완료될지 확신할 수 없습니다. 그리고 이로 인해 동일한 가상 IP 주소를 가진 두 개의 서버가 나타나 문제가 발생할 수 있습니다. split brain.

피하기 위해 split brain, 당신은 방법을 사용할 수 있습니다 스토니스 (“Shoot The Other Node In The Head”), 문제 노드를 완전히 격리하거나 비활성화합니다. 클러스터 고가용성을 구현하는 다른 방법으로는 VIP와 DNS의 조합, 서비스 검색과 프록시 서비스, 동기식 복제 및 고유한 단점과 장점이 있는 기타 방법이 있습니다.

저는 MySQL 장애 조치 클러스터를 생성하는 접근 방식에 대해 이야기했습니다. 구현하기 쉽고 현재 조건에서 허용 가능한 수준의 신뢰성을 제공합니다. 일반적으로 전체 시스템과 특히 인프라가 발전함에 따라 이 접근 방식은 의심할 여지 없이 발전할 것입니다.

출처 : habr.com