MySQL용 Orchestrator: 이것이 없으면 내결함성 프로젝트를 구축할 수 없는 이유

모든 대규모 프로젝트는 두 대의 서버로 시작되었습니다. 처음에는 하나의 DB 서버가 있었고, 이후 읽기 규모를 확장하기 위해 슬레이브가 추가되었습니다. 그리고 그만하세요! 주인은 하나이지만 노예는 많습니다. 슬레이브 중 하나가 떠나면 모든 것이 괜찮을 것이지만 마스터가 떠나면 상황이 나빠질 것입니다. 가동 중지 시간, 관리자가 서버를 올리려고합니다. 무엇을 해야 할까요? 마스터를 예약하세요. 내 동료 Pavel이 이미 이에 대해 썼습니다. статью, 반복하지 않겠습니다. 대신 Orchestrator for MySQL이 꼭 필요한 이유를 알려드리겠습니다!

"마스터가 떠날 때 코드를 새 머신으로 어떻게 전환할 것인가?"라는 주요 질문부터 시작해 보겠습니다.

• 저는 VIP(가상 IP) 방식을 가장 좋아합니다. 아래에서 이에 대해 설명하겠습니다. 이는 가장 간단하고 명백하지만 분명한 제한이 있습니다. 우리가 예약할 마스터는 새 시스템이 있는 L2 세그먼트에 있어야 합니다. 즉, 두 번째 DC를 잊어버릴 수 있습니다. 그리고 우호적으로 큰 L2는 나쁘다는 규칙을 따르면 L2는 랙에만 있고 L3은 랙 사이에 있으므로 이러한 구성에는 훨씬 더 많은 제한이 있습니다.
• 코드에 DNS 이름을 쓰고 /etc/hosts를 통해 확인할 수 있습니다. 실제로는 해결책이 없을 것입니다. 이 방식의 장점은 첫 번째 방식의 특징인 제한이 없다는 점, 즉 교차 DC 구성이 가능하다는 점이다. 그러나 다음과 같은 분명한 질문이 제기됩니다. Puppet-Ansible을 통해 /etc/hosts에 변경 사항을 얼마나 빨리 전달할 수 있습니까?
• 두 번째 방법을 약간 변경할 수 있습니다. 모든 웹 서버에 캐싱 DNS를 설치하면 코드가 마스터 데이터베이스로 이동합니다. DNS에서 이 항목에 대해 TTL 60을 설정할 수 있습니다. 올바르게 구현하면 방법이 좋은 것 같습니다.
• Consul 및 etcd의 사용을 암시하는 서비스 검색 방식입니다.
• 흥미로운 옵션 프록시SQL. ProxySQL을 통해 모든 트래픽을 MySQL로 라우팅해야 하며 ProxySQL 자체에서 누가 마스터인지 결정할 수 있습니다. 그건 그렇고, 내에서 이 제품을 사용하는 옵션 중 하나에 대해 읽을 수 있습니다. 기사.

Github에서 작업하고 있는 Orchestrator의 저자는 먼저 VIP를 사용하여 첫 번째 체계를 구현한 다음 이를 consul을 사용하여 체계로 변환했습니다.

일반적인 인프라 레이아웃:

고려해야 할 명백한 상황을 즉시 설명하겠습니다.

• VIP 주소는 어떤 서버의 구성에도 등록되어서는 안 됩니다. 상황을 상상해 봅시다. 마스터가 재부팅되고 로드되는 동안 Orchestrator는 장애 조치 모드로 들어가 슬레이브 중 하나를 마스터로 만들었습니다. 그런 다음 옛 주인이 일어 났고 이제 VIP는 두 대의 자동차에 있습니다. 이것은 나쁘다.
• 오케스트레이터의 경우 기존 마스터와 새 마스터를 호출하기 위한 스크립트를 작성해야 합니다. 이전 마스터에서는 ifdown을 실행해야 하고 새 마스터에서는 ifup vip를 실행해야 합니다. 장애 조치가 발생하는 경우 분할 브레인을 방지하기 위해 이전 마스터 스위치의 포트가 꺼지는 것을 이 스크립트에 포함하는 것도 좋을 것입니다.
• Orchestrator가 스크립트를 호출하여 먼저 VIP를 제거하거나 스위치의 포트를 끄고 새 마스터에서 VIP 올리기 스크립트를 호출한 후에는 arping 명령을 사용하여 모든 사람에게 새 VIP가 이제 있음을 알리는 것을 잊지 마세요. 여기.
• 모든 슬레이브는 read_only=1이어야 하며, 슬레이브를 마스터로 승격시키는 즉시 read_only=0이어야 합니다.
• 이를 위해 우리가 선택한 슬레이브는 마스터가 될 수 있다는 점을 잊지 마십시오. (Orchestrator에는 슬레이브가 처음에 새 마스터의 후보로 간주되는 전체 선호 메커니즘이 있으며, 두 번째로 어떤 슬레이브가 마스터가 되어야 하는지에 대한 전체 선호 메커니즘이 있습니다. 어떤 상황에서도 전혀 선택되지 않습니다. 마스터). 슬레이브가 마스터가 되면 슬레이브의 부하는 그대로 유지되고 마스터의 부하는 추가되므로 이를 고려해야 합니다.

Orchestrator가 없는데 왜 필요한가요?

• Orchestrator에는 전체 토폴로지를 표시하는 매우 사용자 친화적인 그래픽 인터페이스가 있습니다(아래 스크린샷 참조).
• Orchestrator는 어느 슬레이브가 뒤처져 있는지, 복제가 일반적으로 중단된 위치를 추적할 수 있습니다(SMS 전송을 위해 Orchestrator에 첨부된 스크립트가 있습니다).
• Orchestrator는 GTID 오류가 있는 슬레이브를 알려줍니다.

오케스트레이터 인터페이스:

GTID 오류란 무엇입니까?

Orchestrator가 작동하려면 두 가지 주요 요구 사항이 있습니다.

• MySQL 클러스터의 모든 머신에서 의사 GTID를 활성화해야 합니다. 우리는 GTID를 활성화했습니다.
• 모든 곳에 한 가지 유형의 binlog가 있어야 하며 명령문을 사용할 수 있습니다. 우리는 마스터와 대부분의 슬레이브에 행이 있고 역사적으로 두 개가 혼합 모드에 남아 있는 구성을 가지고 있었습니다. 결과적으로 Orchestrator는 이러한 슬레이브를 새 마스터에 연결하는 것을 원하지 않았습니다.

생산 슬레이브에서 가장 중요한 것은 마스터와의 일관성이라는 점을 기억하십시오! 마스터와 슬레이브 모두에서 GTID(Global Transaction ID)를 활성화한 경우 gtid_subset 함수를 사용하여 동일한 데이터 변경 요청이 실제로 이러한 머신에서 실행되었는지 확인할 수 있습니다. 이에 대해 더 자세히 읽을 수 있습니다. 여기에.

따라서 Orchestrator는 GTID 오류를 통해 마스터에 없는 트랜잭션이 슬레이브에 있음을 보여줍니다. 왜 이런 일이 발생합니까?

• Read_only=1이 슬레이브에서 활성화되지 않았으며 누군가 연결하여 데이터 변경 요청을 완료했습니다.
• Super_read_only=1이 슬레이브에서 활성화되지 않은 경우 서버를 혼란스럽게 한 관리자가 들어가서 요청을 실행했습니다.
• 이전 사항을 모두 고려하면 한 가지 트릭이 더 있습니다. MySQL에서는 binlog를 플러시하라는 요청도 binlog로 이동하므로 첫 번째 플러시에서 GTID 오류가 마스터와 모든 슬레이브에 나타납니다. 이것을 피하는 방법? Perona-5.7.25-28에는 binlog에 플러시 쓰기를 금지하는 binlog_skip_flush_commands=1 설정이 도입되었습니다. mysql.com 웹사이트에 확립된 것이 있습니다. 버그.

위의 내용을 모두 요약하겠습니다. 아직 장애 조치 모드에서 Orchestrator를 사용하지 않으려면 관찰 모드로 전환하세요. 그러면 MySQL 시스템의 상호 작용에 대한 맵과 각 시스템에 어떤 유형의 복제가 있는지, 슬레이브가 뒤처져 있는지, 그리고 가장 중요하게는 마스터와 얼마나 일관성이 있는지에 대한 시각적 정보가 항상 눈앞에 표시됩니다!

분명한 질문은 "Orchestrator는 어떻게 작동해야 합니까?"입니다. 그는 현재 슬레이브에서 새 마스터를 선택한 다음 모든 슬레이브를 여기에 다시 연결해야 합니다(이것이 GTID에 필요한 것입니다. binlog_name 및 binlog_pos와 함께 이전 메커니즘을 사용하는 경우 슬레이브를 현재 마스터에서 새 마스터로 전환합니다 단순히 불가능합니다!). Orchestrator를 사용하기 전에는 이 모든 작업을 수동으로 수행해야 했던 적이 있었습니다. 이전 마스터는 버그가 있는 Adaptec 컨트롤러로 인해 중단되었으며 약 10개의 슬레이브가 있었습니다. 마스터에서 슬레이브 중 하나로 VIP를 전송하고 다른 모든 슬레이브를 다시 연결해야 했습니다. 얼마나 많은 콘솔을 열어야 했는지, 몇 개의 동시 명령을 입력했는지... 새벽 3시까지 기다려야 했고, 두 개를 제외한 모든 슬레이브에서 로드를 제거하고, 두 개의 마스터 중 첫 번째 머신을 만들고, 두 번째 머신을 즉시 연결해야 했습니다. 따라서 다른 모든 슬레이브를 새 마스터에 연결하고 로드를 반환합니다. 전반적으로 끔찍해요...

Orchestrator가 장애 조치 모드로 전환되면 어떻게 작동하나요? 이는 마스터를 지금보다 더 강력하고 현대적인 기계로 만들고자 하는 상황의 예에서 가장 쉽게 설명됩니다.

그림은 프로세스의 중간을 보여줍니다. 지금까지 이미 어떤 일이 이루어졌나요? 우리는 일부 슬레이브를 새로운 마스터로 만들고 싶다고 말했고, Orchestrator는 새로운 마스터가 전송 시스템 역할을 하여 다른 모든 슬레이브를 여기에 다시 연결하기 시작했습니다. 이 구성표를 사용하면 오류가 발생하지 않고 모든 슬레이브가 작동하며 Orchestrator는 이전 마스터에서 VIP를 제거하고 이를 새 마스터로 전송하고 read_only=0으로 설정하고 이전 마스터를 잊어버립니다. 모두! 당사 서비스의 다운타임은 VIP 환승 시간으로, 2~3초입니다.

오늘은 여기까지입니다. 모두들 감사합니다. 곧 Orchestrator에 대한 두 번째 기사가 나올 예정입니다. 소련의 유명한 영화 '개러지'에서 한 등장인물은 "나는 그 사람과 함께 정찰에 나서지 않겠다!"라고 말했다. 그러니 오케스트레이터님, 정찰에 함께 가겠습니다!

출처 : habr.com