版权声明：此文章转载自麦穗技术
如需转载请联系听云College团队成员阮小乙，邮箱：ruanqy#tingyun.com
自动化模式（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上都能找到。
责编：钱曙光
原文：MySQL on Autopilot
作者：Tim Gross
翻译：孙薇
分享到微信
分享到微博
