拥有 14.9 亿月活跃用户的 Facebook 是全球最大的 MySQL 用户之一。 Simon Martin 是 Facebook MySQL 基础架构团队的一名生产工程师，在他职业生涯的大部分时间里，他一直在使用 MySQL，从 2 台由备件构建的服务器开始，一直到世界上最大的部署之一。
Simon 将于 9 月 22 日在阿姆斯特丹的 Percona Live 上分享 Facebook 在公司的不同服务中推出半同步复制时所应对的一些挑战。他的演讲标题恰如其分，“ 半同步复制的高潮和低谷” 。 ”前几天我几乎和西蒙坐下来。我们的谈话如下，但首先，作为对我的读者的特别奖励，通过在 注册 时输入促销代码“BlogInterview”，在您的 Percona Live 注册上节省 20 欧元。请随时分享此优惠！
注意：这次采访是由 Percona 的 Tom Diederich 进行的。
汤姆：从 1 到 10 分，MySQL 对 Facebook 有多重要？ Facebook 如何使用 MySQL？
Simon： 10. 我们有一个复杂的内存缓存层，可以满足大多数请求，但 MySQL 是我们图形的持久存储。这意味着您所有的个人资料数据、您所有的朋友、喜欢和评论以及页面、事件、地点和其他内容都永久存储在 MySQL 中。
我们在这个角色中依赖 MySQL 来实现 3 个关键特性。首先，作为最终存储，它需要不丢失数据，InnoDB 在这个领域得到了很好的证明。它需要高可用，MySQL 和 InnoDB 都非常稳定，我们也使用复制来提供冗余。最后，即使有广泛的缓存，它也需要在延迟和吞吐量方面表现出色，MySQL 两者兼而有之，我们可以再次使用复制将读取流量传播到远程区域的从属服务器，以提供帮助。
汤姆：在 Facebook 使用半同步复制有哪些优势？使用它时，这种规模的部署面临哪些挑战？
西蒙： 这是个大问题，我大概可以讲 50 分钟！我们开始将半同步视为一种解决方案，以减少 MySQL 主服务器或它所在的主机崩溃时的停机时间。从历史上看，如果您正在运行一个复制的环境并且主服务器崩溃，您将面临一个选择。您可以立即提升另一个从服务器以减少停机时间，但无法确定您的任何一个从服务器是否从主服务器上获得了所有交易。在 Facebook，我们不能丢失人们的数据，因此如果需要，我们总是选择在推广之前恢复主数据并重新连接从数据。缺点是在繁忙的主机上恢复 InnoDB 可能很慢，如果主机重新启动，它会更慢，给我们带来很多分钟的停机时间。
现在我们运行半同步复制，这意味着主服务器不会提交事务，直到至少一个从服务器确认收到该事务的二进制日志。通过在主服务器崩溃时运行它，我们可以确保我们最新的从服务器拥有所有数据，因此一旦它被 SQL 线程应用，我们就可以安全地提升而无需等待崩溃恢复。
但这方面存在许多挑战。首先是性能，我们现在需要为每个事务进行一次网络往返，所以我们需要确认从站非常接近。不同数据大厅的奴隶，更不用说不同的地区了，太慢了。
我们还需要注意slave的可用性，以前slave短时间不连接master是没有问题的，现在这会导致写入停止和连接堆积，所以我们需要更加小心如何我们管理我们的复制拓扑。服务 99.999% 正常运行时间的目标现在需要在从站上提供相同的 SLA，并在本地连接以确认提交。
在此之上以“webscale”运行增加了一层自己的要求。就像我们环境的其他部分一样，一切都需要自动化，任何需要人工的东西都无法扩展。因此，我们的自动化需要在任何情况下都无需干预地响应任何故障并修复系统。需要自动处理在给定日期发生的可能性很小的边缘案例，以保持我们的 SLA 并阻止我们的工程师不断地修复问题。
汤姆：在今年的会议上，你最期待的是什么（除了你自己的演讲）？
西蒙： 我一直很喜欢主题演讲，它们似乎还没有全部公布，但这是了解社区更新状态的好方法。我肯定会停在“ Booking.com 的 Binlog 服务器 ”，听起来他们可能正在做与我们用于半同步复制相同的事情，所以比较想法会很棒。我还将查看有关 MySQL 5.7 的讨论，以了解即将发布的酷炫新内容！
