持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第7天，点击查看活动详情
你好，我是悟空。
业界流传一句话：没有做过运维的程序员不是好架构师。不知是真是假。
本篇内容如下：
前言
对于 MySQL 数据库作为各个业务系统的存储介质，在系统中承担着非常重要的职责，如果数据库崩了，那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复，对业务的影响是非常大的。之前 B 站不是出过一次事故么，2 小时才恢复过来，详细可以看之前写的文章。B 站崩了，总结下「高可用」和「异地多活」
上次折腾完 ELK 日志检索平台后，开发环境可以正常查询日志了。最近在做系统高可用相关的工作，这次我来分享下 MySQL 双主 + Keepalived 的高可用落地和踩坑之路。
一、方案选择
对于 MySQL 的高可用，主要分为两步，配置 MySQL 主主模式和 keepalived 软件。拓扑图如下所示：
1.1 MySQL 数据库的主主模式
两个数据库分别部署在两台服务器上，相互同步数据，但是只有一个提供给外部访问，当一个宕机后，另外一个可以继续提供服务，在没有 keepalived 软件的帮助下，只能手动切换
1.2 keepalived 监测、自动重启、流量切换
- 检测和重启：两台服务器上都部署 keepalived 软件，定时检测 MySQL 服务是否正常，如果一个数据库服务崩了，keepalived 会用脚本尝试重启 mysql 服务。
- 备份：两个 keepalived 服务都提供了虚拟 IP 供客户端使用，但是流量只会转到一台 MySQL 服务上。
- 虚拟 IP：keepalived 配置好了后，会有一个 虚拟 IP，对于客户端来说，不关心连接的是哪台 MySQL，访问虚拟 IP 就可以了。
- 流量切换：如果客户端正在访问的 MySQL 服务崩了后，keepalived 会用我们写的脚本自动重启 MySQL，如果重启失败，脚本主动停掉 keepalived，客户端的流量就不会访问到这台服务器上的 MySQL 服务，后续访问的流量都会切到另外一台 MySQL 服务。
检测和重启的原理如下所示：
需要配置的内容如下：
- 两台 Ubuntu 服务器上启动 MySQL 容器。
- 配置 MySQL 主从复制架构。
- 将 MySQL 主从改为主主复制架构。
- 两台服务器搭建 keepalived 环境监控 MySQL 和自动重启 MySQL。
