SideProject：DatabaseonDockerSwarm的集群建设

Side Project：Database on Docker Swarm的集群建设

这个项目是由三个需求联合催生的：

1.  我们的Database到14年底都一直只有同机房HA replication failover机器和跨机房的基于sata+大磁盘机器的一机N个机器的延迟八小时备份；这个备份由于机器性能和端口问题，无法提供可能的生产failover接管服务；连hadoop抽取都干不了；长期白天delay晚上慢慢catch up；鉴于成本要求，我们急需一个又可以解决灾备问题，又可以在适当的成本控制之内的解决方案；

2.  Docker的稳定性经过测试环境的应用服务器测试，如果可以经历生产数据库的考验，那么对于大规模应用服务器上Docker production，我们也会非常有信心；而且我也直接管理Data Infra团队，可以直接决定上生产计划；

3. 另外，由于众所周知的原因，MySQL单机(截止当时的5.5版本）基本上无法利用我们现在的10g网络+128g/256g+Flash卡的capacity，就算在大促高峰阶段，绝大多数 MySQL 的资源利用率是极低的；但是由于资源隔离，和端口冲突的原因，我们还是选择master基本上是一机一个实例；slave也是；本来也在考虑用cgroup但是考虑到端口的不一致性和生产支持的复杂，我们一直没有启动；

我们按照几个阶段来推进这个项目；

阶段1：应用在备份/ 恢复中心 ；没有经过恢复考验的备份是没用的；我们一直在每个机房有一个基于 Glusterfs的备份中心；每天晚上轮流备份IDC里面的所有Database/Redis； 但是我们之前基本上不做主动的恢复验证；基于 Docker 的灵活性我们搞了自动恢复中心；在每个IDC的备份中心下，我们单独配置了几个Server，7x24小时的对每个数据库，按照Database Docker Instance的要求，自动创建Docker Instance，把MySQL的备份restore到Docker Instance，然后apply binlog直到最近，完成一遍full table scan check；这是一个极端IO，CPU，内存和网络压力密集的压力测试，7x24小时对宿主机和Docker的网络，cpu，磁盘等进行压力测试和隔离，和稳定性测试；如果我们的配置可以经历这个考验，我们可以非常有信心，生产运行会非常稳定了；系统设计方面，采用标准的宿主机配置，Docker配置，swarm集群驱动整体docker的provision，只是Docker的宿主机的选择逻辑，在我们inhouse的data tool里面进行筛选；

阶段2 ：应用于跨机房灾备 ；就是这个 side project本身；经过了阶段1的测试，其实后面就比较简单了；我们采用了阶段1的swarm配置，项目推进基本上是非常顺利；我们采购了大几十台基于Flash卡的物理机，完成了全网大几百台MySQL Master的跨机房灾备；而且把大部分的hadoop ETL都迁移到了这个MySQL slave集群上面；一方面降低了原先slave的压力，更主要是验证了这个slave集群的数据的准确定和及时性；

阶段3 ： 在 LVS后面的MySQL read instance，接受生产流量的考验；

阶段4 ： 从 non-critical的production instance;  到mission critical的数据库，都逐步迁移大部分到这个解决方案上面来；

整个方案，回过头来看，我们采用了最简单的稳定的方案，没有用Kubernetes这么复杂的工具（它最近才开始在试图支持stateful的应用），也没有用到分布式存储(本地Flash卡+DeviceMapper)，但是极好的解决了业务的本质需求：建立跨机房可以服务的灾备，实现instance之间的资源隔离，Failover也不用应用修改端口（修改DNS即可）；也证明了Docker用于生产流量的稳定性和可管理性；也极大的降低了成本（采购服务器，和机房空间）；

唯一的遗憾是我们做到阶段3一半的时候，由于非技术原因，项目被暂停了；阶段1和阶段2完美运行了2年多，中间只出现过一次由于etcd的原因swarm无法创建新实例的小故障；

技术上的一些细节，可以参考： http://www.dockerinfo.net/2527.html