在 Hostinger， 我们有各种 MySQL 设置，从独立的无副本实例到 Percona XtraDB Cluster （后来只是 PXC）、 基于ProxySQL路由甚至绝对自定义和独特的解决方案，我将在这篇博文中描述。
我们没有用于 API、计费和客户端等内部服务的大象大小的数据库。因此，几乎每个决定都以高可用性而不是可扩展性作为重中之重。
尽管如此，垂直扩展对于我们的案例来说已经足够了，因为数据库大小不超过 500GB。一个也是最重要的要求是能够访问主节点，因为我们有相当等距的读取和写入工作负载。我们当前用于存储有关客户端、服务器等的所有数据的设置是使用由三个节点组成的 PXC，没有任何异地复制。所有节点都在同一个数据中心运行。我们计划将此集群迁移到跨三个位置的地理复制集群：美国、荷兰和新加坡。如果其中一个位置无法访问，这将使我们能够保证高可用性。由于 PXC 使用完全同步复制，写入的延迟会更高。但是由于每个位置都有本地副本，读取速度会快得多。更多阅读：网络星期一网络托管优惠活动:Hostinger主机获得 80% 的折扣
我们对MySQL Group Replication做了一些研究 ，但它要求实例之间的距离更近，并且对延迟更敏感。Group Replication 旨在部署在服务器实例彼此非常接近的集群环境中，并受网络延迟和网络带宽的影响。PXC 以前用过，所以我们知道如何在危急情况下处理它，让它的可用性更高。
在 000webhost.com 项目和 hAPI（Hostinger API）中，我们使用我们前面提到的独特解决方案，该解决方案使用 Layer3 协议选择主节点。我们最好的朋友之一是 BGP 和 BGP 协议，它的年龄足以购买自己的啤酒，因此我们经常使用它。此实现还使用 BGP 作为底层协议，并有助于指向真正的主节点。为了运行 BGP 协议，我们使用 ExaBGP 服务并从两个主节点宣布 VIP 地址作为任播。
您应该问：但是您如何确定 MySQL 查询会访问同一个实例而不是同时访问两个实例？我们使用 Zookeeper 的临时节点 来获取互斥锁。Zookeeper 就像 BGP 扬声器和 MySQL 客户端之间的断路器。如果获得了锁，我们会从主节点宣布 VIP，应用程序将向此路径发送查询。如果锁定被释放，另一个节点可以接管它并宣布 VIP，因此应用程序将毫不费力地发送查询。
第二个问题来了：需要满足什么条件才能停止发布VIP？这可以根据用例以不同的方式实现，但是如果 MySQL 进程关闭，我们会使用Requires ExaBGP 的单元文件中的systemd 来释放锁 ：此外，无论是否指定 After=，如果其他单元之一被明确停止，该单元将被停止。使用 systemd， 我们可以创建一个很好的依赖树，以确保满足所有这些。停止、杀死甚至重启 MySQL 都会使 systemd 停止 ExaBGP 进程并撤回 VIP 公告。最终结果是选择了一个新的母版。更多阅读：hostinger主机安装WordPress
我们在游戏时代对这些主故障转移进行了战斗测试， 但尚未 发现任何关键问题 。如果你觉得好的架构很贵，那就试试差的架构吧?