在 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
我们在游戏时代对这些主故障转移进行了战斗测试, 但尚未 发现任何关键问题 。如果你觉得好的架构很贵,那就试试差的架构吧?