12月2日，云计算高级工程师王佩老师，在【DBA+社群】中间件用户组进行了一次主题为“基于Docker的mysql mha 的集群环境构建实践”的线上分享。小编特别整理出其中精华内容，供大家学习交流。同时，也非常感谢王佩老师对DBA+社群给予的大力支持。

 

 

嘉宾简介  

• 云计算高级工程师

• 目前主要研究docker 相关的云计算技术

 

演讲实录 

关于docker 想必前面的各位大牛分享的演讲讲的非常多了,今天主要跟大家分享基于docker快速构建 mysql mha 的一个实战案例分享,在分享的过程中主要讲解一下我的思路和如何利用docker本身的一些特性进行一些自动化的工作,整个过程如果有错误或者不足之处还请大家指正。

1  为什么想到基于docker 构建 mysql 

这是我们dba给我列出来的,传统mysql mha 安装方式粗略流程 

整个安装过程,会受到网络不可控影响,正常情况下dba一般在2~3个小时左右部署完成,从这个安装过程我们可以看到其实很多工作需要在最少3个服务器节点上重复操作。

在我们接触docker过程中,应该对他最熟悉的就是一次编译生成镜像,push到仓库后,可以在任意docker节点上运行,所以我们在构建mysql mha 时候就利用docker的一些特性来快速构建我们的mysql mha 集群。

我将构建MHA 的过程,拆分为2个版本,在2个不同版本我们将看到docker与mysql MHA集群的构建结合过程中 ,带来了哪些优势, 同时产生了哪些不同的问题。

2  第一版 mysql 容器 

在第一版中我们只使用docker 快速构建mysql能力,构建mysql容器,与宿主机配合组成mysql mha,在这种方式下最容易让dba理解,同时让整个集群的环境具备docker的一些优秀特性。

2.1  容器MYSQL构建步骤简述: 

1. pull mysql 容器

可以使用私有仓库(如果有)或公有仓库进行pull,这里我直接从私有仓库中下载percona。

2. 定义目录与my.cnf 文件

在宿主机创建my.cnf 配置文件存放目录,创建mysql 数据存放目录,由于容器本身的存储系统不太适合mysql 数据存放使用,所以我们后面将使用-v 来挂载容器卷,使用宿主机的文件系统目录提供使用。

 

mkdir -p /home/docker/mount/mysql/mhadb

mkdir -p /home/docker/conf/mysql/master.cnf

 

在定义my.cnf 文件时候,需要注意几个参数的定义

>端口最好不要使用默认3306,避免可能的端口冲突

>相关目录定义需要与前面创建目录一致,主要涉及如下参数定义路径

3. run 容器

然后我们使用 docker run 命令启动容器,注意网络我们必须以 --net=host方式,docker网络有4种方式,详细的大家可以官方doc 了解,同时我们将宿主机的/etc/localtime 挂载到容器,避免宿主机时间和容器时间不对问题。

这里 启动容器我们还有几个可选配置项,大家可以根据实际情况进行配置,建议将自动oom进行关闭。

> --oom-kill-disable=false  --考虑是否禁用oom kill

> --memory-swap=""   ---是否禁用swap

>相关资源限制指令,是否进行内存/cpu/io资源限制

4. 其他节点重复以下配置

• 创建目录

• 复制my.cnf文件到其他节点,注意修改一些与主从相关的配置参

• 使用同样的命令 run mysql容器

5. 配置数据库主从同步

这里我们选举一个为主服务器,配置其他其他两个节点与主数据库进行主从同步,这里的主从配置与传统db安装后配置无异,所以我们这里省略。

6. mha配置工作

mysql mha 安装配置安装工作在第一版中都是在宿主机上完成由于时间关系就不在这里展开,很简单,相信大家都知道配置,如果大家有兴趣,我可以再后面讲解整个完整配置过程,至此我们3个节点的主从数据库通过容器构建完成了。

7. 第一版中基于docker 构建mysql mha 集群的优缺点分析

1) 优点

• 提升5%~10 效率,并且在db从节点增加的情况下,基本不增加部署时间开销。

• 利用docker image分层特性,与mysql mha 高可用 实现了mysql 分钟级甚至更短时间内 滚动平滑版本升级与回退(请先确保你在新的MySQL版本中彻底测试了所有的应用功能。这对重要版本之间的升级尤为重要，对重要版本之间的跨越升级也很重要)。

• 基于容器构建的db, 只要宿主机资源充足,我们可以快速重复构建N个db数据库,传统安装方式下,多个db实例安装在同一个宿主机上,会很麻烦。

2) 缺点

• 如果在单一实例部署情况下,整个mysql mha 部署安装的效率并没有带来大的提升。

• 由于mha 相关安装包还是需要在宿主机上安装,所以我们整个mysql mha 集群的构建还是依赖于宿主机操作系统类型与版本。

• 相对于传统数据库安装,使用容器技术会占用更多目录空间。

我们来看一下使用docker进行mysql升级步骤,整个版本升级过程基本在秒级完成。

(请先确保你在新的MySQL版本中彻底测试了所有的应用功能。这对重要版本之间的升级尤为重要，对重要版本之间的跨越升级也很重要)

3  第二版 容器即一切 

接下来,我们再构建我们基于 docker 化的mysql mha 集群第二版,我们第二版的目的是尽量提供部署效率,并具备一定通用性,在第二版将使用更多docker命令与特性,同时我们在后面也会分析使用第二版构建存在哪些问题。

我们在第二版本中使用完整的os层上附加mysql,mha 编译成image,但与虚拟机克隆不同的是我们包含容器镜像分层,同时我们分离出2个镜像分别是,node,manager节点。

我们来把第二版中Dockerfile build一层层解析,看我们在第二版做了哪些工作(基于manager 节点)。

1、引用了centos 作为base image*

     FROM centos:6.7

2、将安装mha之前需要安装的依赖包安装,并安装mysql 数据库

3、将下载的mha 添加到os中,并编译安装

4、将配置文件copy 到容器中

配置文件设置有2种方式,一种是编写好的配置文件放入容器,另外一种是在容器run时候替换参数值,这我们使用run 时候参数传递。

5、COPY容器RUN时执行shell*

6、我们编译打包完image,使用docker run 启动(manager节点)

7、我们继续构建mha node节点

在dockerfile 中,我们只需要剔除与manager 相关的内容,同时我们在mysql-entrypoint.sh 脚本中剔除一些无用的参数替换sh,node 启动配置:

8、配置主从

• 获取主节点信息

  docker exec -it 容器id mysql -uroot -pxxx -e 'show master status'

• 配置从库

  我们可以使用 docker exec -it 容器id  命令进行配置,也可以使用传统方式登录数据库中进行配置  

9、配置节点互信

这里我们必须是在容器当中进行节点互信配置,而不是在宿主机上进行配置,我们需要登录到容器当中进行节点互信配置,相关的命令与在宿主机上配置互信相同,这里就不在重复。

10、mha 监控启动

11、第二版中基于docker 构建mysql mha 集群的优缺点分析*

1) 优点:

• 整个mha install & config 过程大部分自动化完成,这让我们在分钟级搭建mysql mha平台成为可能。

• 做到了整个mha 构建与平台无关性,基于docker,使我们mha集群可以运行在任意宿主系统上。

• 直接在构建 image 层级时候进行一些os配置优化工作。

• 监控部署直接在使用Dockerfile 构建image层部署(可选)。

2) 缺点

• 基于的是完整os层构建,镜像占用的空间相对更大。

• mha 也附加到os image层后, 容器启动必须以--net=host  --privileged=true 启动,但这会降低安全性,同时可能会存在端口冲突。

• 需要安装完整的ssh server,容器间需要配置ssh互信而不是在宿主机层。

• 整个构建过程相对复杂,需要自己编写配置dockerfile文件构建,以及编写脚本进行配置,但好在只需要构建一次,后面可以重复运行在其他服务器上。

• 整个的过程有点类似于虚拟机克隆功能,但不同的是它包含很多docker特性,如运行是执行脚本,镜像分层。

12、mysql-entrypoint.sh 解析

由于mysql-entrypoint.sh 包含太多重复内容,就不全部展开了,里面的脚本也很简单,对传递的变量执行一些操作,这些操作包含:删除test用户,参数值替换,用户创建,不太了解的朋友可以看一下官方doc中ENTRYPOINT 解释部分,自己编写一下。

这是其中一段参数值替换与复制用户创建

4  总结 

在第一版中我们只使用docker 构建 mysql ,我们利用的是docker 快速构建容器, 镜像分层技术使mysql搭建与升级能够快速平滑,但我们需要在宿主机上面做大量工作,并需要系统依赖。

在第二版中我们用docker 构建一个完整的os,并包含已经安装好的mysql数据库和mha,同时我们还能利用docker 本身的一些特性,实现一些自动化工作,但由于docker天生隔离性,安全性相对较低,这会导致一些额外的问题。