架构师·2018 年 8 月刊
15
15
1.0x
00:00/00:00
登录|注册

GitHub的MySQL高可用性实践

GitHub 使用 MySQL 作为所有非 git 项目的主要数据存储,因此 MySQL 的可用性对于 GitHub 的运维来说至关重要。站点本身、GitHub 的 API、身份验证等都需要数据库访问。我们运行多个 MySQL 集群来服务我们的不同服务和任务。我们的集群使用经典的主 - 副设置,其中集群的单个节点(主节点)能够接受写操作。其它集群节点(副节点)异步更新主节点的变更并服务我们的读流量。
主节点的可用性特别地重要。主节点不可用时,集群就不能接受写操作:任何需要持久化的写操作都不能被持久化。任何传入的变更,例如提交代码、提问题、用户创建、代码审查、新建代码库等等,都会失败。
为了支持写操作,我们显然需要有一个可用的写节点,即集群的主节点。但同样重要的是,我们需要能够识别,或者发现,那个节点。
遇到一个故障时,比如主节点崩溃的场景,我们必须确保存在一个新的主节点,并且能够快速通告其身份。检测故障、运行故障恢复以及通告新主节点身份所花费的时间组成了总宕机时间。
本文阐述了 GitHub 的 MySQL 高可用性和主服务发现解决方案,这个方案使得我们能够可靠地进行跨数据中心运维、克服数据中心隔离的影响并实现故障时的短宕机时间。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
登录 后留言

精选留言

由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论
显示
设置
留言
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部