GitHub 的两次故障分析
2012-09-15 18:38:14   来源：互联网   评论：0 点击：

GitHub 在本周遭受了两次服务故障，其中一次是1小时46分钟的无法访问，另外一次是接近一小时的性能故障。这比我们标准要差很多，我们对此表示抱歉。我想要解释究竟发生了什么事情，以及我们采取了什么措施以防止这些问题再次发生。

背景介绍

在八月中旬的一次维护中，我们的维护团队用一组三个节点的集群替代了老旧的 DRBD-backed MySQL 服务器。这些服务器有两个虚拟的 IP，其中一个可以用来读写，另外一个只读。这些虚拟 IP 是通过Pacemaker 和 Heartbeat 管理的，这两个软件在我们的架构中用的很多。MySQL 的复制（active/standby）是通过 Percona Replication Manager 完成的。我们的应用基本上只使用 active 的节点，不论读写操作。

这样的配置提供了有效的冗余。在之前的架构中，假如一个 MySQL down 了，我们需要冷启动另外一个 MySQL 。而新的架构中，MySQL 始终是在运行的，MySQL 之间的切换是通过虚拟 IP 的切换来完成的。

9月10日，星期一

这个事情的起因是因为一次无伤大雅的数据库迁移。我们使用 two-pass 迁移系统，以达到无停机 MySQL schema 迁移。这个是最近才加上的操作，不过我们已经做过好几次了。

周一的迁移导致了比往常迁移更高的数据库压力。由于压力太高导致 master 节点没有通过 Percona Replication Manager 的健康检查。所以 Percona Replication Manager 将“active”和 master 数据库移到另外一台服务器上，并且停止了出问题的 MySQL。

与此同时，新的 active 数据库的 InnoDB 缓存是空的，所以性能比较差。系统的压力一下子又起来了，于是 Percona Replication Manager 的健康检查又报错，所有 active 服务器又被切换到了原来那台服务器上。

这个时候，我决定禁用所有健康检查，通过 Pacemaker 的 maintenance-mode 来完成。随着缓冲的渐渐形成，网站的性能渐渐的起来了。

9月11日，星期二

第二天上午，开发人员通知运维组，standby 的 MySQL 返回的结果不正确。我研究了一下，发现当昨天集群设置为 maintenance-mode 的时候，导致了 standby 服务器的 replication master 错误。所以我决定禁用 maintenance-mode ，让 Pacemaker 和 Persona Replication Manager 恢复正常。

译者注：翻译不下去了，十分细节，强烈建议看原文！

In ops I trust

两次故障的根本原因都是数据库的故障切换功能。每次发生故障切换的时候，假如由人来判断的话，都是不应该做切换操作的。自动的故障切换在很多时候是好的。在经过仔细的考虑过后，我们认为我们的主要数据库并不需要这个功能。所以我们修改了 Pacemaker 的配置，只有人为操作才会对 active 数据库进行故障切换。

我们也在研究如何解决故障切换时候的性能问题，不论是紧急情况还是例行维护。有不少工具可以用来初始化 InnoDB 的缓存池，我们正在研究中。

最后，我们的运营团队正在对周二发生的 Pacemaker 和 Heartbeat segfault 错误进行调查。

故障状态网站

我们网站状态信息部署在 Heroke 上面，以保证在网站故障的时候，状态信息是可以被访问的。但是，在周二的故障中，我们的网站状态也遇到了一些问题。

由于访问状态网站的流量突然增加，我们把节点数从8增加到64最后增加到90。但增加节点起了反作用，因为我们的数据库（共享的）是非常陈旧的。新增的节点把数据库连接都站了，导致其他进程的崩溃。

通过和 Heroku 支持的沟通，我们把 production database 启动了，状态网站的表现有了明显的提升。自从这次事故以后，我们为状态网站也加了第二台数据库，以保证在突发状况下的可用性。

展望未来

我们最近对数据库的改动是为了提高可用性而做的，但是我很抱歉它起了反作用。我们的运维团队始终专注于提供快速，稳定的 GitHub 体验，我们将继续优化我们架构，软件和方法来提高用户的体验。