GitHub가 MySQL의 가용성을 높이는 방법에 대해 이야기해 보겠습니다.

Github는 git이 아닌 모든 트랜잭션의 데이터 저장소로 MySQL 데이터베이스를 사용합니다. 데이터베이스 가용성은 Github가 제대로 작동하는 데 매우 중요합니다. Github 웹사이트 자체, Github API, 인증 서비스 등 모두 데이터베이스에 액세스해야 합니다. Github는 다양한 서비스 작업을 지원하기 위해 여러 데이터베이스 클러스터를 실행합니다. 데이터베이스 아키텍처는 전통적인 마스터-슬레이브 구조를 채택합니다. 클러스터의 한 노드(마스터 데이터베이스)는 쓰기 액세스를 지원하고 나머지 노드(슬레이브 데이터베이스)는 변경 사항을 마스터 데이터베이스에 동기화하고 읽기 서비스를 지원합니다. git 事务的数据存储。数据库的可用性对 Github 的正常运行而言至关重要。无论是 Github 网站本身，还是 Github API，身份验证服务等都需要访问数据库。Github 运行了多个数据库集群用于支撑不同的服务于任务。数据库的架构采用的是传统的主从结构，集群中一个节点（主库）支持写访问，其余的节点（从库）同步主库的变更，支持读服务。

主库的可用性至关重要。一旦主库宕机，集群将不能够支持数据写入服务：任何需要保存的数据都无法写入到数据库保存。最终导致 Github 上任何变更，例如代码提交，提问，用户创建，代码 review，创建仓库等操作都无法完成。

为了保证业务的正常运行，我们自然需要在集群中有一个可用的支持写入的数据库节点。同时，我们也必须能够快速的发现可用的可写入服务数据库节点。

就是说，在异常情况下，假如主库宕机的场景，我们必须确保新的主库能够立刻上线支持服务，同时保证集群中其他节点能够快速识别到新的主库。故障检测，主库迁移以及集群其他数据节点识别新主库的总时间构成了服务中断的总时间。

这篇文章说明了 GitHub 的 MySQL 高可用性和主库服务发现解决方案，该解决方案使我们能够可靠地运行跨数据中心的操作，能够容忍数据中心的隔离，并缩短在出现故障时停机时间。

高可用性的实现

本篇文章描述的解决方案是在以前 Github 高可用方案上的改进版本。正如前面说到的一样，MySQL 的高可用策略必须适应业务的变化。我们期望 MySQL 以及 GitHub 上其他的服务都有能够应对变化的高可用解决方案。

当设计高可用以及服务发现系统方案的时候，从下面几个问题出发，也许能够帮助我们快速找到合适的解决方案：

• 最大允许的服务中断的时间是多少？
• 服务中断检测的准确性怎么样？是否能够允许服务中断检测误报（会导致过早故障转移）？
• 故障转移的可靠性怎么样？什么情况会导致故障转移失败？
• 这个方案能否在跨数据中心实现，以及如何实现的？ 在不同的网络状况下会怎么样，延迟高，或延迟低的情况会怎么样？
• 这个解决方案能否承受整个数据中心（DC）的故障 或者网络隔离的情况？
• 有什么机制防止 HA 集群脑裂情况（在一个整体的系统，联系着的两个节点分裂为两个独立节点，这两个节点争抢共享资源写入数据的情况）？
• 能否容忍数据丢失？容忍丢失程度是多少？

为了说明上面的几个问题，我们先来看一下我们之前的高可用方案，以及我们为什么要改进它。

摒弃基于 VIP 和 DNS 的发现机制

在之前的方案中，应用了下面的技术方案：

• 使用 orchestrator 作为故障检测迁移方案。
• 采用 VIP 和 DNS 方式作为主节点发现方案。

客户端通过节点名称，例如 mysql-writer-1.github.net，解析成主节点的虚拟 IP 地址 (VIP)，从而找到主节点。

因此，正常情况下，客户端可以通过对节点名称的解析，连接到对应 IP 的主节点上。

考虑夸三个数据中心的拓扑结构的情况：

一旦主库异常，必须将其中的一个数据副本服务器更新为主库服务器。

orchestrator메인 라이브러리의 가용성이 중요합니다. 기본 데이터베이스가 다운되면 클러스터는 데이터 쓰기 서비스를 지원할 수 없습니다. 저장해야 하는 데이터는 저장을 위해 데이터베이스에 쓸 수 없습니다. 결과적으로 코드 제출, 질문, 사용자 생성, 코드 검토, 웨어하우스 생성 등과 같은 Github의 모든 변경 사항을 완료할 수 없습니다.

비즈니스의 정상적인 운영을 보장하려면 당연히 쓰기를 지원하는 클러스터에 사용 가능한 데이터베이스 노드가 필요합니다. 동시에 사용 가능한 쓰기 가능한 서비스 데이터베이스 노드를 신속하게 검색할 수 있어야 합니다.

즉, 비정상적인 상황에서 메인 데이터베이스가 다운되면 새로운 메인 데이터베이스가 즉시 온라인으로 전환되어 서비스를 지원할 수 있는지 확인하고 클러스터의 다른 노드가 새로운 메인 데이터베이스를 신속하게 식별할 수 있도록 해야 합니다. 결함 감지, 마스터 마이그레이션 및 클러스터의 기타 데이터 노드가 새 마스터를 식별하는 데 소요되는 총 시간이 서비스 중단의 총 시간을 구성합니다. 🎜🎜이 기사에서는 데이터 센터 전체에서 안정적으로 작업을 실행하고, 데이터 센터 격리를 허용하고, 장애 발생 시 가동 중지 시간을 줄일 수 있게 해주는 GitHub의 MySQL 고가용성 및 마스터 서비스 검색 솔루션에 대해 설명합니다. 🎜

고가용성 구현

🎜이 문서에서 설명하는 솔루션은 이전 Github 고가용성 솔루션의 향상된 버전입니다. 앞서 언급했듯이 MySQL의 고가용성 전략은 비즈니스 변화에 적응해야 합니다. 우리는 MySQL과 GitHub의 기타 서비스가 변화에 대처할 수 있는 고가용성 솔루션을 갖출 것으로 기대합니다. 🎜🎜고가용성 및 서비스 검색 시스템 솔루션을 설계할 때 다음 질문에서 시작하면 적합한 솔루션을 빠르게 찾는 데 도움이 될 수 있습니다. 🎜

• 허용되는 서비스 중단 시간은 최대 얼마입니까?
• 서비스 중단 감지는 얼마나 정확합니까? 서비스 중단 감지를 통해 거짓 긍정(조기 장애 조치 발생)을 감지할 수 있나요?
• 장애 조치는 얼마나 안정적인가요? 장애 조치(failover)가 실패할 수 있는 조건은 무엇입니까?
• 이 솔루션을 데이터 센터 전체에 구현할 수 있으며 어떻게 구현됩니까? 다양한 네트워크 조건, 높은 대기 시간 또는 낮은 대기 시간에서는 어떤 일이 발생합니까?
• 이 솔루션은 전체 데이터 센터(DC) 장애 또는 네트워크 격리를 견딜 수 있습니까?
• HA 클러스터 분할 브레인 상황(전체 시스템에서 두 개의 연결된 노드가 두 개의 독립 노드로 분할되고 두 노드가 데이터를 쓰기 위해 공유 리소스를 놓고 경쟁하는 상황)을 방지하는 메커니즘이 있습니까?
• 데이터 손실이 허용됩니까? 어느 수준의 손실이 허용됩니까?

🎜위 문제를 설명하기 위해 먼저 이전 고가용성 솔루션과 이를 개선하려는 이유를 살펴보겠습니다. 🎜

VIP 및 DNS 기반 검색 메커니즘 포기

🎜이전 솔루션에서는 다음 기술 솔루션이 적용되었습니다. 🎜

• 사용 조정자는 오류 감지 마이그레이션 솔루션 역할을 합니다.
• 마스터 노드 검색 솔루션으로 VIP 및 DNS 방법을 사용합니다.

🎜클라이언트는 mysql-writer-1.github.net과 같은 노드 이름을 가상 IP 주소(VIP)로 구문 분석하여 마스터 노드를 찾습니다. 마스터 노드. 🎜🎜따라서 일반적인 상황에서 클라이언트는 노드 이름을 파싱하여 해당 IP의 마스터 노드에 연결할 수 있습니다. 🎜🎜3개 데이터 센터의 토폴로지를 자랑하는 상황을 생각해 보세요: 🎜🎜🎜🎜메인 데이터베이스에 이상이 생기면 데이터 복제 서버 중 하나를 메인 데이터베이스 서버로 업데이트해야 합니다. 🎜🎜조정자는 이상 현상을 감지하고 새 마스터 데이터베이스를 선택한 다음 데이터베이스 이름과 가상 IP(VIP)를 다시 할당합니다. 클라이언트 자체는 메인 라이브러리의 변경 사항을 알지 못합니다. 클라이언트가 가지고 있는 정보는 메인 라이브러리의 🎜이름🎜뿐이므로 이 이름은 새 메인 라이브러리 서버에서 확인할 수 있어야 합니다. 다음을 고려하십시오. 🎜🎜VIP 협상이 필요합니다. 가상 IP는 데이터베이스 자체에서 보유합니다. 서버는 VIP를 점유하거나 해제하기 위해 ARP 요청을 보내야 합니다. 새 데이터베이스가 새 VIP를 할당하려면 먼저 기존 서버가 보유하고 있는 VIP를 해제해야 합니다. 이 프로세스는 몇 가지 특이한 문제를 일으킬 수 있습니다:🎜

• 장애 조치의 순서는 먼저 실패한 시스템에 VIP를 해제하도록 요청한 다음 새 기본 데이터베이스 시스템에 연결하여 VIP를 할당하는 것입니다. 하지만 실패한 시스템 자체에 접근할 수 없거나 VIP 공개를 거부하면 어떻게 될까요? 시스템 오류 시나리오를 고려하면 오류가 발생한 시스템은 VIP 해제 요청에 즉시 응답하지 않거나 전혀 응답하지 않습니다. 전체 프로세스에는 다음 두 가지 문제가 있습니다.
  • 분할 브레인 상황: 동일한 VIP를 보유하는 두 호스트가 있는 경우 상황에서는 서로 다른 클라이언트가 가장 짧은 네트워크 링크를 기반으로 서로 다른 호스트에 연결됩니다.
  • 전체 VIP 재할당 프로세스는 두 개의 독립 서버의 조정에 의존하며 설정 프로세스는 신뢰할 수 없습니다.
• 결함이 있는 기계가 VIP를 정상적으로 해제하더라도 전환 과정에서도 결함이 있는 기계에 연결이 필요하기 때문에 전체 과정에 시간이 많이 걸립니다.
• VIP가 재할당되더라도 클라이언트의 기존 연결은 이전에 실패한 시스템에서 자동으로 연결이 끊어지지 않아 전체 시스템에서 분할 브레인 상황이 발생합니다.

실제로 VIP를 설정할 때 VIP도 실제 물리적 위치에 구속됩니다. 이는 주로 스위치나 라우터의 위치에 따라 다릅니다. 따라서 동일한 로컬 서버에서만 VIP를 재할당할 수 있습니다. 특히, 다른 데이터센터의 서버에 VIP를 할당할 수 없어 DNS를 변경해야 하는 경우도 있습니다.

• DNS 변경사항을 전파하는 데 시간이 더 오래 걸립니다. 클라이언트는 구성된 시간에 따라 먼저 DNS 이름을 캐시합니다. 크로스 플랫폼 장애 조치는 더 많은 중단을 의미합니다. 클라이언트는 새로운 기본 서버를 인식하는 데 더 많은 시간을 소비해야 합니다.

이러한 제한만으로도 새로운 솔루션을 찾을 수 있지만 고려해야 할 사항은 다음과 같습니다.

• 마스터 서버는 pt-heartbeat 서비스를 사용하여 액세스 하트비트를 자체 주입합니다. 지연 시간 측정 및 제한 제어를 목적으로 합니다. 서비스는 새 기본 서버에서 시작되어야 합니다. 가능한 경우, 주 서버가 교체되면 기존 주 서버의 서비스가 종료됩니다. pt-heartbeat 服务去自注入访问心跳，目的是延迟测量和节流控制。该服务必须在新的主服务器开始。如果可以，在更换主服务器的同时会关闭旧的主服务器这项服务。

• 同样地，Pseudo-GTID 是由服务器自行管理的。它需要在新的主服务器开始，最好在旧的主服务器上停止。

• 新的主服务器将设置为可写入。如果可以的话，旧的主服务器将设置为 read_only(只读)。

这些额外的步骤是导致总停机时间的一个因素，并引入了它们自己的故障和摩擦。

解决方案是有效的，GitHub 已经成功地进行了 MySQL 故障转移，但是我们希望 HA 在以下方面有所改进:

• 与数据中心无关。
• 容忍数据中心故障。
• 删除不可靠的协作工作流。
• 减少总停机时间。
• 尽可能的，有无损的故障切换。

GitHub 的高可用解决方案：orchestrator ，Consul ， GLB

新策略可以改进，解决或者优化上面提到的问题。现在高可用的组成如下：

• orchestrator 执行检测和故障转移。如链接中描述的那样采用混合数据中心 orchestrator/raft 。
• Hashicorp 的 Consul 作为服务发现。
• GLB/HAProxy 作为客户端和写入节点之间的代理。 GLB 指导是开源的.
• anycast 作为网络路由。

新的结构移除了 VIP 和 DNS 。在引入更多的组件的同时，我们能够解藕这些组件，并且简化相关的任务，并易于利用可靠稳定的解决方案。详情如下。

正常过程

正常情况，应用通过 GLB/HAProxy 连接到写入节点。

应用感知不到 master 身份。之前，都是使用名称。例如 cluster1 的 master 是 mysql-writer-1.github.net。现在的结构中，这个名称被  anycast IP 取代。

通过 anycast，名称被相同的 IP 取代，但流量由客户端的位置来进行路由。特别的，当数据中心有 GLB 时，高可用负载均衡器部署在不同的盒子内。 通向 mysql-writer-1.github.net

🎜🎜마찬가지로 Pseudo-GTID는 서버 자체에서 관리됩니다. 새 마스터에서 시작해야 하며 이전 마스터에서 중지하는 것이 좋습니다. 🎜🎜🎜🎜새 마스터가 쓰기 가능하도록 설정됩니다. 가능하다면 이전 마스터는 read_only로 설정됩니다. 🎜🎜🎜🎜이러한 추가 단계는 전체 가동 중지 시간의 요인이 되며 자체적인 결함과 마찰을 초래합니다. 🎜🎜솔루션이 작동하고 GitHub는 MySQL 장애 조치를 성공적으로 수행했지만 HA가 다음 영역에서 개선되기를 바랍니다. 🎜🎜🎜데이터 센터에 구애받지 않습니다. 🎜🎜데이터 센터 오류에 대한 내성이 있습니다. 🎜🎜신뢰할 수 없는 공동작업 워크플로우를 제거하세요. 🎜🎜전체 가동 중지 시간을 줄입니다. 🎜🎜가능한 경우 무손실 장애 조치를 수행하세요. 🎜🎜

GitHub의 고가용성 솔루션: Orchestrator, Consul, GLB

🎜새로운 전략을 통해 위에서 언급한 문제를 개선, 해결 또는 최적화할 수 있습니다. 현재 고가용성 구성 요소는 다음과 같습니다. 🎜🎜🎜Orchestrator가 감지 및 장애 조치를 수행합니다. orchestrator/raft 링크에 설명된 대로 하이브리드 데이터 센터를 채택합니다. 에>. 🎜🎜Hashicorp의 Consul을 서비스 검색으로 활용하세요. 🎜🎜GLB/HAProxy를 클라이언트로 사용하고 에이전트 간 노드 쓰기 . GLB 디렉터는 오픈 소스입니다.🎜🎜anycast는 네트워크입니다. 라우터. 🎜🎜🎜🎜🎜 새로운 구조에서는 VIP와 DNS가 제거됩니다. 더 많은 구성 요소를 도입함에 따라 구성 요소를 분리하고 관련 작업을 단순화하며 안정적이고 안정적인 솔루션을 더 쉽게 활용할 수 있습니다. 자세한 내용은 아래를 참조하세요. 🎜

정상 프로세스

🎜정상적인 상황에서 애플리케이션은 GLB/HAProxy를 통해 쓰기 노드에 연결됩니다. 🎜🎜애플리케이션이 마스터 신원을 인식하지 못합니다. 이전에는 이름이 사용되었습니다. 예를 들어 cluster1의 마스터는 mysql-writer-1.github.net입니다. 현재 구조에서는 이 이름이 anycast IP로 대체됩니다. 🎜🎜anycast를 사용하면 이름은 동일한 IP로 대체되지만 트래픽은 클라이언트 위치에 따라 라우팅됩니다. 특히 데이터센터에 GLB가 있는 경우 고가용성 로드밸런서는 다른 박스에 배치된다. mysql-writer-1.github.net에 대한 트래픽은 로컬 데이터 센터의 GLB 클러스터로 전달됩니다. 이렇게 하면 모든 클라이언트가 로컬 프록시에 의해 서비스됩니다. 🎜

HAProxy 위에 GLB를 사용하세요. HAProxy에는 모든 MySQL 클러스터에 하나씩 쓰기 풀 이 있습니다. 각 풀에는 백엔드 서비스인 클러스터 마스터 노드가 있습니다. 데이터 센터의 모든 GLB/HAProxy 상자에는 동일한 풀이 있습니다. 이는 이러한 풀이 동일한 백엔드 서비스에 해당함을 의미합니다. 따라서 애플리케이션이 mysql-writer-1.github.net을 작성할 것으로 예상하는 경우 어떤 GLB 서비스에 연결할지는 상관하지 않습니다. 실제 cluster1 마스터 노드로 연결됩니다. mysql-writer-1.github.net，不同关心连接哪个 GLB 服务。它会导向实际的 cluster1 master 节点。

就应用连接 GLB ，发现服务而言，不需要重新发现。GLB 负责全部流量导向正确的目的地。

GLB 是怎么知道哪些服务是后端，以及如何告知 GLB 变化的呢？

Discovery via Consul

Consul 以服务发现解决方案而闻名，也提供 DNS 服务。 然而，在我们的解决方案中，我们将其用作高度可用的键值 (KV) 存储。

在 Consul 的 KV 存储中，我们写入集群主节点的身份。 对于每个集群，都有一组 KV 条目指示集群的主设备 fqdn、端口、ipv4、ipv6。

每个 GLB/HAProxy 节点都运行 consul-template：一个监听 Consul 数据变化的服务（在我们的例子中：集群主数据的变化）。 consul-template 生成一个有效的配置文件，并且能够在配置更改时重新加载 HAProxy。

因此，每个 GLB/HAProxy 机器都会观察到 Consul 对 master 身份的更改，然后它会重新配置自己，将新的 master 设置为集群后端池中的单个实体，并重新加载以反映这些更改。

在 GitHub，我们在每个数据中心都有一个 Consul 设置，并且每个设置都是高度可用的。 但是，这些设置彼此独立。 它们不会在彼此之间复制，也不会共享任何数据。

Consul 如何获知变化，信息如何跨 DC 分发？

orchestrator/raft#

我们运行一个 orchestrator/raft 设置： orchestrator 节点通过 raft 机制相互通信。 每个数据中心有一个或两个 orchestrator 节点。

orchestrator 负责故障检测和 MySQL 故障切换，以及将 master 的变更传达给 Consul 。 故障切换由单个 orchestrator/raft leader 节点操作，但是集群现在拥有新 master 的消息通过 raft 机制传播到所有 orchestrator 节点。

当 orchestrator 节点收到 master 变更的消息时，它们各自与本地 Consul 设置通信：它们各自调用 KV 写入。 具有多个 orchestrator 代理的 DC 将多次（相同）写入 Consul。

把流程组合起来

在 master 崩溃的情况下:

• orchestrator 节点检测故障.
• orchestrator/raft leader 节点开始恢复，一个数据服务器被更新为 master 。
• orchestrator/raft 公告所有 raft 子集群节点变更了 master 。
• 每个 orchestrator/raft 成员收到一个 leader 节点 变更的通知。它们每个成员都把新的 master 更新到本地 Consul KV 存储中。
• 每个 GLB/HAProxy 都运行了 consul-template，该模版观察 Consul KV 存储中的更改，并重新配置和重新加载 HAProxy。
• 客户端流量被重定向到新的 master 。

每个组件都有明确的责任归属，整个设计既是解耦的，又是简化的。orchestrator 不知道负载平衡器。 Consul 不需要知道消息的来源。代理只关心 Consul

애플리케이션이 GLB에 연결되어 서비스를 검색하는 한 재발견은 필요하지 않습니다. GLB는 모든 트래픽을 올바른 목적지로 보내는 역할을 담당합니다.

GLB는 어떤 서비스가 백엔드인지 어떻게 알 수 있으며 GLB에 변경 사항을 어떻게 알릴 수 있나요?

• Consul을 통한 검색
• Consul은 서비스 검색 솔루션으로 유명하며 DNS 서비스도 제공합니다. 그러나 우리 솔루션에서는 이를 고가용성 키-값(KV) 저장소로 사용합니다.
• Consul의 KV 스토어에서는 클러스터 마스터 노드의 ID를 작성합니다. 각 클러스터에는 클러스터의 마스터 fqdn, 포트, ipv4, ipv6을 나타내는 KV 항목 집합이 있습니다.

각 GLB/HAProxy 노드는 Consul 데이터 변경 사항을 모니터링하는 서비스인 consul-template을 실행합니다( 사례: 클러스터 마스터 데이터의 변경). consul-template은 유효한 구성 파일을 생성하고 구성이 변경되면 HAProxy를 다시 로드하는 기능을 생성합니다.

따라서 각 GLB/HAProxy 머신은 마스터 ID에 대한 Consul 변경 사항을 관찰한 다음 자체적으로 재구성하고 새 마스터를 클러스터 백엔드 풀의 단일 엔터티로 설정하고 해당 변경 사항을 반영하기 위해 다시 로드합니다.

GitHub에서는 각 데이터 센터에 Consul 설정이 있으며 각 설정의 가용성이 높습니다. 그러나 이러한 설정은 서로 독립적입니다. 서로 간에 복사하지 않으며 어떠한 데이터도 공유하지 않습니다. 🎜🎜Consul은 변경 사항을 어떻게 파악하며 DC에 정보가 어떻게 배포되나요? 🎜

🎜orchestrator/raft🎜#🎜🎜🎜저희는 오케스트레이터/raft 설정: <code>orchestrator 노드는 raft🎜 메커니즘을 통해 서로 통신합니다. 각 데이터 센터에는 하나 또는 두 개의 조정자 노드가 있습니다. 🎜🎜조정자는 오류 감지 및 MySQL 장애 조치뿐 아니라 🎜master🎜에서 🎜Consul🎜로 변경 사항을 전달하는 역할도 담당합니다. 장애 조치는 단일 orchestrator/raft 리더 노드에 의해 작동되지만 클러스터에 이제 새로운 🎜master🎜가 있다는 메시지는 를 통해 모든 <code>orchestrator 노드에 전파됩니다. 뗏목 메커니즘 . 🎜🎜 Orchestrator 노드가 🎜master🎜 변경 메시지를 받으면 각각 로컬 🎜Consul🎜 설정과 통신합니다. 각각 KV write를 호출합니다. 여러 조정자 에이전트가 있는 DC는 🎜Consul🎜에 여러 번 (동일한) 쓰기를 수행합니다. 🎜

🎜프로세스 결합🎜🎜🎜마스터 충돌의 경우:🎜🎜🎜orchestrator 노드 감지 실패.🎜🎜orchestrator/raft 리더 노드가 복구되기 시작하고 데이터 서버가 마스터로 업데이트됩니다. 🎜🎜orchestrator/raft는 모든 raft 하위 클러스터 노드가 마스터를 변경했음을 알립니다. 🎜🎜각 오케스트레이터/뗏목 구성원은 리더 노드 변경 알림을 받습니다. 각 구성원은 새 마스터를 로컬 Consul KV 스토어로 업데이트합니다. 🎜🎜각 GLB/HAProxy는 Consul KV 저장소의 변경 사항을 관찰하고 HAProxy를 재구성하고 다시 로드하는 consul-template을 실행합니다. 🎜🎜클라이언트 트래픽이 새 마스터로 리디렉션됩니다. 🎜🎜🎜각 구성 요소에는 명확한 책임이 있으며 전체 디자인은 분리되어 단순화되었습니다. 조정자는 로드 밸런서를 인식하지 못합니다. Consul은 메시지의 출처를 알 필요가 없습니다. 상담원은 Consul에만 관심이 있습니다. 클라이언트는 프록시에만 관심이 있습니다. 🎜🎜또한: 🎜🎜🎜전파할 DNS 변경 사항이 없습니다.🎜🎜TTL이 없습니다. 🎜🎜스트림은 실패한 마스터와 협력하지 않으며 대부분 무시됩니다. 🎜🎜🎜🎜추가 세부정보🎜🎜🎜귀하의 트래픽을 더욱 보호하기 위해 다음과 같은 조치를 취하고 있습니다. 🎜

• HAProxy는 매우 짧은 hard-stop-after로 구성됩니다. 작가 풀에서 새 백엔드 서버를 다시 로드하면 이전 마스터 서버에 대한 기존 연결이 자동으로 종료됩니다. hard-stop-after。当它重新加载写入器池中的新后端服务器时，它会自动终止与旧主服务器的任何现有连接。
  • 使用 hard-stop-after，我们甚至不需要客户的合作，这减轻了脑裂的情况。值得注意的是，这不是封闭的，并且在我们终止旧连接之前一段时间过去了。但是在某个时间点之后，我们会感到很舒服，并且不会期待任何令人讨厌的惊喜。
• 我们并不严格要求 Consul 随时待命。事实上，我们只需要它在故障转移时可用。如果 Consul 发生故障，GLB 将继续使用最后的已知值进行操作，并且不会采取剧烈行动。
• GLB 设置为验证新提升的 master 的身份。与我们的 上下文感知 MySQL 池 类似，会在后端服务器上进行检查，以确认它确实是写入器节点。如果我们碰巧在 Consul 中删除了 master 的身份，没问题；空条目被忽略。如果我们在 Consul 中错误地写了一个非主服务器的名字，没有问题； GLB 将拒绝更新它并继续以最后一个已知状态运行。

我们将在以下部分进一步解决问题并追求 HA 目标。

Orchestrator/RAFT 故障检测#

orchestrator 使用 整体方法 来检测故障，因此非常可靠。我们没有观察到误报：我们没有过早的故障转移，因此不会遭受不必要的停机时间。

orchestrator/raft 进一步解决了完整的 DC 网络隔离（又名 DC 围栏）的情况。 DC 网络隔离可能会导致混乱：该 DC 内的服务器可以相互通信。是它们与其他 DC 网络隔离，还是其他 DC 被网络隔离？

在 orchestrator/raft 设置中，raft 领导节点是运行故障转移的节点。领导者是获得组中大多数人（法定人数）支持的节点。我们的协调器节点部署是这样的，没有一个数据中心占多数，任何 n-1 数据中心都可以。

在 DC 网络完全隔离的情况下，该 DC 中的 orchestrator 节点会与其他 DC 中的对等节点断开连接。因此，孤立 DC 中的 orchestrator 节点不能成为 raft 集群的领导者。如果任何这样的节点恰好是领导者，它就会下台。将从任何其他 DC 中分配新的领导者。该领导者将得到所有其他能够相互通信的 DC 的支持。

因此，发号施令的 orchestrator 节点将是网络隔离数据中心之外的节点。如果一个独立的 DC 中有一个主控，orchestrator 将启动故障转移，用其中一个可用 DC 中的服务器替换它。我们通过将决策委托给非隔离 DC 中的法定人数来缓解 DC 隔离。

更快的广而告之

通过更快地公布主要更改可以进一步减少总停机时间。如何实现这一点？

当 orchestrator 开始故障转移时，它观察可用于提升的服务器队列。理解复制规则并遵守提示和限制，它能够对最佳操作过程做出有根据的决策。

它可能认识到，一个可用于促销的服务器也是一个理想的候选人，例如:

• 没有什么可以阻止服务器的升级 (用户可能已经暗示这样的服务器是首选的升级) ，以及
• 预计服务器能够将其所有兄弟服务器作为副本。

在这种情况下， orchestrator

hard-stop-after를 사용하면 고객의 협조도 필요하지 않아 두뇌 분할 상황이 완화됩니다. 이것이 닫히지 않았으며 이전 연결을 종료하기까지 약간의 시간이 걸린다는 점은 주목할 가치가 있습니다. 그러나 어느 시점이 지나면 우리는 편안함을 느끼고 불쾌한 놀라움을 기대하지 않습니다.

Consul이 항상 대기할 것을 엄격하게 요구하지는 않습니다. 실제로 장애 조치 시에만 사용할 수 있어야 합니다. Consul이 실패하면 GLB는 마지막으로 알려진 값을 사용하여 계속 작동하며 과감한 조치를 취하지 않습니다.

GLB는 새로 승격된 마스터의 신원을 확인하기 위해 설정되었습니다. 컨텍스트 인식 MySQL 풀

과 유사하게 백엔드 서버에 위치합니다. 실제로 작성자 노드인지 확인하세요. Consul에서 마스터의 ID를 삭제해도 문제 없이 빈 항목이 무시됩니다. 실수로 Consul에 마스터가 아닌 이름을 쓰면 GLB는 업데이트를 거부하고 마지막으로 알려진 상태에서 계속 실행됩니다. 다음 섹션에서는 문제를 더 자세히 해결하고 HA 목표를 추구할 것입니다.

오케스트레이터/RAFT 오류 감지

#

오케스트레이터 전체적인 접근 방식 🎜을 사용하여 오류를 감지하므로 매우 안정적입니다. . 우리는 거짓양성(false positive)을 관찰하지 못했습니다. 조기 장애 조치가 없었으므로 불필요한 가동 중지 시간이 발생하지 않았습니다. 🎜🎜orchestrator/raft는 완전한 DC 네트워크 격리(DC 펜싱이라고도 함)의 경우를 추가로 다룹니다. DC 네트워크 격리는 혼란을 초래할 수 있습니다. 해당 DC 내의 서버는 서로 통신할 수 있습니다. 다른 DC는 네트워크가 다른 DC와 격리되어 있나요, 아니면 다른 DC는 네트워크가 격리되어 있나요? 🎜🎜orchestrator/raft 설정에서 raft 리더 노드는 장애 조치를 실행하는 노드입니다. 리더는 그룹의 다수(정족수)의 지원을 받는 노드입니다. 우리의 코디네이터 노드 배포는 어떤 데이터 센터도 과반수를 갖지 않으며 모든 n-1 데이터 센터가 과반수를 차지합니다. 🎜🎜DC 네트워크가 완전히 격리되면 DC의 Orchestrator 노드와 다른 DC의 피어 노드와의 연결이 끊어집니다. 따라서 고아 DC의 조정자 노드는 raft 클러스터의 리더가 될 수 없습니다. 그러한 노드가 리더가 되면 그 노드는 물러납니다. 새로운 리더는 다른 DC에서 할당됩니다. 이 리더는 서로 통신할 수 있는 다른 모든 DC의 지원을 받습니다. 🎜🎜따라서 명령을 내리는 조정자 노드는 네트워크 격리 데이터 센터 외부의 노드가 됩니다. 독립형 DC에 마스터가 있는 경우 조정자는 장애 조치를 시작하고 이를 사용 가능한 DC 중 하나의 서버로 교체합니다. 격리되지 않은 DC의 쿼럼에 결정을 위임하여 DC 격리를 완화합니다. 🎜

🎜더 빠른 광고🎜🎜🎜주요 변경 사항을 더 빠르게 게시하여 전반적인 가동 중지 시간을 더욱 줄일 수 있습니다. 이것을 달성하는 방법은 무엇입니까? 🎜🎜Orchestrator는 장애 조치를 시작할 때 승격할 수 있는 서버의 대기열을 관찰합니다. 복제 규칙을 이해하고 팁과 제한 사항을 준수하면 최선의 조치에 대해 현명한 결정을 내릴 수 있습니다. 🎜🎜프로모션 가능한 서버도 이상적인 후보라고 인식될 수 있습니다. 예: 🎜🎜🎜서버 업그레이드를 막을 수 있는 것은 없습니다(사용자는 이러한 서버가 선호되는 업그레이드라고 암시했을 수 있음). 그리고 🎜서버는 모든 형제 서버를 복제본으로 가질 수 있을 것으로 예상됩니다. 🎜이 경우 Orchestrator는 먼저 서버를 쓰기 가능으로 설정한 다음 즉시 서버 프로모션을 광고합니다(우리의 경우 Consul KV 스토어에 쓰기). 복제 트리 복구는 비동기적으로 시작됩니다. 이 작업은 일반적으로 몇 초 정도 걸립니다. 🎜🎜GLB 서버가 완전히 다시 로드되기 전에 복제 트리가 그대로 유지될 가능성이 높지만 반드시 필요한 것은 아닙니다. 서버는 쓰기를 매우 잘 받아들입니다! 🎜🎜🎜반동기 복제🎜🎜🎜MySQL의 🎜반동기 복제🎜에서 마스터 서버는 변경 사항이 하나 이상의 복제본으로 전송된 것으로 확인될 때까지 트랜잭션 커밋을 승인하지 않습니다. 이는 무손실 장애 조치를 달성하는 방법을 제공합니다. 기본 서버에 적용된 모든 변경 사항은 기본 서버에 적용되거나 복제본 중 하나에 적용될 때까지 기다립니다. 🎜

일관성에는 비용이 발생합니다. 가용성 위험이 있습니다. 복제본이 변경 사항 수신을 확인하지 않으면 마스터는 쓰기를 차단하고 중지합니다. 다행스럽게도 마스터가 비동기 복제 모드로 되돌아가서 쓰기를 다시 사용할 수 있게 해주는 시간 초과 구성이 있습니다.

시간 초과를 합리적으로 낮은 값인 500ms로 설정했습니다. 마스터 DC 복제본의 변경 내용을 로컬 DC 복제본과 원격 DC로 보내는 것으로 충분합니다. 이 시간 제한을 사용하면 완벽한 반동기 동작(비동기 복제로 대체 없음)을 관찰할 수 있으며 승인 실패 시 매우 짧은 차단 기간을 쉽게 사용할 수 있습니다. 500ms。将更改从主 DC 副本发送到本地 DC 副本，通常也发送到远程 DC，这已经足够了。通过这个超时，我们可以观察到完美的半同步行为 (没有退回到异步复制) ，并且在确认失败的情况下可以很轻松地使用非常短的阻塞周期。

我们在本地 DC 副本上启用半同步，在主服务器死亡的情况下，我们期望 (尽管不严格执行) 无损故障转移。完全直流故障的无损故障转移是昂贵的，我们并不期望它。

在尝试半同步超时的同时，我们还观察到了一个对我们有利的行为：在主要失败的情况下，我们能够影响理想候选对象的身份。通过在指定的服务器上启用半同步，并将它们标记为候选服务器，我们能够通过影响故障的结果来减少总停机时间。在我们的实验中，我们观察到我们通常最终会得到理想的候选对象，从而快速地广而告之。

注入心跳

我们没有在升级 / 降级的主机上管理 pt-heart 服务的启动 / 关闭，而是选择在任何时候在任何地方运行它。这需要进行一些修补，以便使 pt-heart 能够适应服务器来回更改 read_only(只读状态) 或完全崩溃的情况。

在我们当前的设置中，pt-heart 服务在主服务器和副本上运行。在主机上，它们生成心跳事件。在副本上，他们识别服务器是 read_only(只读) 的，并定期重新检查它们的状态。一旦服务器被提升为主服务器，该服务器上的 pt-heart 就会将服务器标识为可写的，并开始注入心跳事件。

orchestrator 所有权委托#

我们进一步 orchestrator:

• 注入 Pseudo-GTID ,
• 将提升的 master 设置为可写，清除其复制状态，以及，
• 如果可能，将旧主服务器设置为 read_only。

在所有的新 master 的基础上，这减少了摩擦。一个刚刚被提升的 master 显然应该是有生命力，并且可以被接受的，否则我们不会提升它。因此，让 orchestrator 直接讲更改应用于提升的 msater 是有意义的。

orchestrator 所有权委托#

我们进一步 orchestrator：

• Pseudo-GTID 注入，
• 将提升的 master 设置为可写，清除其复制状态，以及，
• 如果可能，将旧的 master 设置为 read_only。

在所有的新 master 的基础上，这减少了摩擦。一个刚刚被提升的 master 显然应该是有活力，并且可以被接受的，否则我们不会提升它。因此，让 orchestrator

로컬 DC 복제본에서 반동기화를 활성화하고, 마스터가 종료되는 경우 (엄격하게 시행하지는 않지만) 무손실 장애 조치를 기대합니다. 완전한 DC 결함의 무손실 장애 조치는 비용이 많이 들고 우리는 이를 기대하지 않습니다.

반동기식 시간 초과를 실험하는 동안 우리는 우리에게 유리한 동작도 관찰했습니다. 즉, 기본 오류가 발생할 경우 이상적인 후보의 신원에 영향을 미칠 수 있었습니다. 지정된 서버에서 세미 동기화를 활성화하고 이를 후보 서버로 표시함으로써 오류 결과에 영향을 주어 전반적인 가동 중지 시간을 줄일 수 있습니다. 실험 에서 우리는 일반적으로 이상적인 후보자빨리 소식을 전하기 위해.

Inject heartbeat

우리는 업그레이드/다운그레이드된 호스트에서 pt-heart 서비스의 시작/종료를 관리하지 않지만 어디에서나 수행하도록 선택합니다. 언제든지 실행하세요. pt-heart가 상황에 적응할 수 있도록 하려면 일부 패치

가 필요합니다. 서버가 read_only(읽기 전용 상태)로 앞뒤로 변경되거나 완전히 충돌하는 경우. 현재 설정에서는 pt-heart 서비스가 마스터와 복제본에서 실행됩니다. 호스트에서는 하트비트 이벤트를 생성합니다. 복제본에서는 서버를 read_only로 식별하고 주기적으로 상태를 다시 확인합니다. 서버가 마스터로 승격되면 해당 서버의 pt-heart는 서버를 쓰기 가능한 것으로 식별하고 하트비트 이벤트 주입을 시작합니다.

오케스트레이터 소유권 위임

#

오케스트레이터 추가:

• Pseudo-GTID를 삽입하고,
• 승격된 마스터를 쓰기 가능으로 설정하고, 복제 상태를 지우고,
• 가능한 경우 이전 마스터를 read_only로 설정합니다. >.

모든 새로운 마스터 외에도 이는 마찰을 줄여줍니다. 새로 승격된 마스터는 분명히 살아 있고 수용 가능해야 합니다. 그렇지 않으면 승격되지 않습니다. 따라서 조정자가 부스트에 적용되어야 하는 msater 변경에 대해 직접 이야기하도록 하는 것이 합리적입니다.

🎜오케스트레이터 소유권 위임🎜#🎜🎜🎜추가 오케스트레이터: 🎜

• Pseudo-GTID 삽입,
• 승격된 마스터를 쓰기 가능으로 설정하고 복제 상태를 지우고
• 가능한 경우 이전 마스터를 read_only로 설정합니다. >.

🎜모든 새로운 마스터 외에도 이는 마찰을 줄여줍니다. 새로 승격된 마스터는 분명히 활성화되어 있어야 하며, 그렇지 않으면 승격되지 않습니다. 따라서 조정자가 승격된 msater에 변경 사항을 직접 적용하도록 하는 것이 합리적입니다. 🎜🎜🎜제한 사항 및 단점🎜🎜🎜프록시 계층은 애플리케이션이 마스터 서버의 ID를 알 수 없도록 만들지만, 애플리케이션에 대한 마스터 서버의 ID도 마스킹합니다. 주로 보이는 것은 프록시 계층에서 오는 연결뿐이며 연결의 실제 출처에 대한 정보는 손실됩니다. 🎜🎜분산 시스템의 발전과 함께 우리는 여전히 처리되지 않은 시나리오에 직면해 있습니다. 🎜🎜데이터 센터 격리 시나리오에서 기본 서버가 격리된 DC에 있다고 가정하면 해당 DC의 애플리케이션은 여전히 ​​기본 서버에 쓸 수 있다는 점에 주목할 필요가 있습니다. 이로 인해 네트워크가 복원되면 일관성 없는 상태가 발생할 수 있습니다. 우리는 DC 내부와 매우 격리된 안정적인 🎜STONITH🎜를 구현하여 이러한 분할된 두뇌를 완화하기 위해 노력하고 있습니다. 이전과 마찬가지로 원색이 파괴되기까지는 다소 시간이 걸릴 것이며 짧은 기간 동안 두뇌 분할이 있을 수 있습니다. 뇌 분열을 방지하는 데 드는 운영 비용은 매우 높습니다. 🎜🎜장애 조치 시 영사 서비스 중단, 부분 DC 격리 등의 경우가 더 많습니다. 우리는 이러한 성격의 분산 시스템에 모든 취약점을 연결하는 것이 불가능하다는 것을 알고 있으므로 가장 중요한 사례에 중점을 둡니다. 🎜🎜🎜결론🎜🎜🎜저희 코디네이터/GLB/영사는 다음을 제공했습니다.🎜메이 , 총 중단 시간은 10~13초입니다.

• 드문 경우에는 총 가동 중지 시간이 최대 20초까지 표시되고 극단적인 경우 최대 25초의 가동 중지 시간이 표시됩니다.
• 결론
• 오케스트레이션/에이전트/서비스 검색 패러다임은 분리된 아키텍처에서 잘 알려져 있고 신뢰할 수 있는 구성 요소를 사용하므로 배포, 운영 및 관찰이 더 쉽고 각 구성 요소는 위쪽 또는 아래쪽으로 확장할 수 있습니다. 독립적으로. 우리는 지속적으로 설정을 테스트하고 개선점을 찾을 수 있습니다.
• 원본 주소: https://github.blog/2018-06-20-mysql-high-availability-at-github/10 and 13 seconds 之间。
  • 在不常见的情况下，我们最多可以看到 20 seconds 的总停机时间，在极端情况下则可以看到最多 25 seconds
  번역 주소: https://learnku.com/mysql/t/36820

【관련 추천:

mysql 비디오 튜토리얼】

위 내용은 GitHub가 MySQL의 가용성을 높이는 방법에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!