自动化模式中的MySQL 自动化数据

原文：MySQL on Autopilot

作者：Tim Gross

翻译：孙薇

自动化模式（Autopilot Pattern）是一种设计应用与基础架构的方式，旨在推动应用系统中的各个组件自动化。组成应用的每个容器都有自己的生命周期，我们将这些生命周期的行为封装到了应用的容器中，而没有依赖外部架构。

下文将讲述我们是如何借助这种模式，部署和运行其中一种常被认为难以在Docker容器中运行的复杂、有状态的应用：MySQL。

运行MySQL

我们从常见的MySQL部署开始：从主节点到副本节点执行异步复制。客户端查询副本节点，或对主节点执行写入操作。这个架构会引发一些关于服务发现和拓扑结构的问题：

• 副本节点如何知道在哪儿能找到主节点？
• 主节点如何告知副本节点从哪儿开始执行复制？
• 客户端如何知道在哪儿找到节点，哪些节点接受写入操作？

在执行部署后，我们还有一系列疑问：

• 我们怎样进行备份？
• 如何主节点出现故障，如何对副本节点进行升级来进行替换？
• 在故障转移期间，其他的副本节点怎样知道在哪儿能找到新的主节点？
• 客户端如何知道我们执行了故障转移？

当然，其中一些问题已经有了现成的答案。配置管理工具经常会负责应用中架构的配置工作，但如果运行时应用拓扑出现变更，配置管理工具是无法回应的。数据库即服务（DBaaS）负责执行管理工作，不过如今大多的配置已不再控制范围内，成本也更为高昂。

对应用来说，还有一个选择就是执行自动化运行。在这种模式下，要对应用模式执行优化，代表着要让应用知道如何适应整个系统：启动、关闭、缩放、发现和恢复。最大限度地减少人为干涉，意味着错误更少，有更多的时间花在更重要的业务上。

很明显我们没打算重写MySQL，因此需要找出办法为现有的应用提供这个功能，而我们选择了Containerbuddy。

架构

我们需要利用这些组件部署MySQL：

MySQL：我们使用了MySQL5.6（Percona Server），使用XtraBackup运行热快照备份；

Consul：用来协调复制与故障转移工作；

Manta：Joyent的对象存储系统，为存储MySQL快照备份提供安全经久的服务；

Containerbuddy：包含在我们的MySQL容器中，负责编配bootstrap behavior，通过onStart、health、onChange处理器，调用Consul中存储的key和checks协调复制的工作。

triton-mysql.py：Containerbuddy在执行MySQL编配的繁重任务时会调用到的小型Python应用。

所有代码与配置都能在GitHub中找到。

架构图

当开始新的MySQL节点时，Containerbuddy的onStart处理器会调用triton-mysql.py。Containerbuddy会fork Percona Server并等待，同时运行onStart、health、onChange处理器。结果就是类似这样在MySQL容器中的进程树：

root@993acf351cd9:/# ps axo uid,pid,ppid,stime,cmd

UID    PID  PPID  STIME  CMD
root     1     0  19:02  /bin/containerbuddy
mysql   94     1  19:02  |_ mysqld --console --gtid-mode=ON...
root   107     1  19:04  |_ python /bin/triton-mysql.py health
root   109     1  19:04  |  |_ /usr/bin/innobackupex --no-timestamp...
root   120     1  19:06  |_ python /bin/triton-mysql.py health
root   121     1  19:06     |_ mysql -u repl -p...

自组装

由于我们只用了几个Docker镜像，无需使用单独的调度器来管理发现与引导服务，简单地使用下面的命令就可以运行堆栈：

docker-compose up -d

出现的第一个节点会登录Consul发现服务，尝试并查找主节点。如果第一个节点发现主节点还不存在，则将自身作为主节点，并初始化数据库。使用Consul会话通过atomic锁写入密码，这样就会有一个且仅有一个节点成为主节点。

主节点也会通过Percona XtraBackup来建立自己的快照备份节点，并将这个快照备份与最近的binlog发送到Manta对象存储系统中。（这个操作会周期性或在binlog变化时重复执行。）这些路径被记录在Consul中，我们会使用这些路径来执行下一步的复制。

一旦主节点建立完毕并且运行正常，我们就能很简单地扩展副本节点：

docker-compose scale mysql=3

在onStart处理器中，每个副本节点都会向Consul请求主节点的位置，然后从主节点建立备份节点。然后再向Consul请求最近快照备份的位置，从Manta下载该备份，然后使用GTIDs与主节点执行同步。一旦操作完成，这些副本节点就会在Consul注册为正常运行的节点。

自监控

在MySQL进程的运行过程中，Containerbuddy会通过容器中捆绑的mysql客户端执行定期检查。在这种情况下使用简单的SELECT 1便能很容易地检查副本节点的状态，或者运行中的查询数。如果检查通过，Containerbuddy将会在一个TTL内对Consul写入一个区域数据。

自修复

如果从服务中移除主节点（假设运行docker），容器中的Containerbuddy会立即从Colcul中移除它的注册信息，而副本节点会收到这个onChange事件。

尽管副本节点在几秒钟内发现了这个变化，也必须等待Concul的锁定结束。一旦锁定结束，所有副本节点会尝试获取锁定，无论哪个节点获胜，都会将自己升级为主节点。剩下的节点会自动根据新的主节点执行重新配置。

亲手尝试一下吧！

自动模式下的Percona Server可以满足你对高性能、高可用性的MySQL兼容数据库的需求。可以用它来支持大量依赖于MySQL兼容服务器的开源应用，包括WordPress、Drupal、Joomla、TYPO3、MODx、phpBB、MyBB等等。

所有代码在GitHub上都能找到。

（责编/钱曙光，关注架构和算法领域，寻求报道或者投稿请发邮件qianshg@csdn.net，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）

「CSDN 高级架构师群」，内有诸多知名互联网公司的大牛架构师，欢迎架构师加微信qshuguang2008入群，备注姓名+公司+职位。