MySQL为什么不介绍经常使用Docker部署

docker可以从远程仓库拉取镜像而后经过镜像极速的部署运行，十分的繁难快捷，然而当天来聊聊为什么Mysql不介绍经常使用Docker部署这个疑问。

1、数据库扩容费事

Mysql是用来存储的数据，docker部署Mysql之后数据不会存储在容器上，由于容器封锁之后数据就失落了，所以容器是须要挂载到宿服务器器上，如下图所示：

随着业务的继续一直的开展，Mysql不免会产生须要扩容的状况，然而扩容的时刻就会产生一些艰巨，如下所示：

此时Mysql2是不可挂载到文件1上的，由于宿服务器的数据文件是容器独占的，不可成功两个容器实例共享一份数据文件。

每个Mysql的容器都挂载了各自的文件上，如何成功文件1和文件2的数据共享呢？此时有如下的处置打算：

打算一：binlog同步

打算二：先全量dump，而后再经常使用binlog增量同步

打算一是不介绍经常使用，Mysql扩容是由于业务数据量到达瓶颈了，那么大数据量下经常使用binlog同步是不适合的。

打算二中全量dump数据的时刻须要停机，目的是先让数据同步到另一份文件上，由于数据须要同步进而让业务在一段期间内不可经常使用，在某种状况下也是不适合的。

2、内存资源疑问

咱们都知道docker是经过运行来做隔离的，而不是经过资源做隔离的，如下图所示：

假定Mysql运行、MQ运行以及Redis运行都是docker部署的，此时上图区域的内存是三个运行共享的。这里就存在一个疑问，假设MQ运行占用了80%的内存，那么Mysql和Redis就只能共用残余20%的内存，假定这个残余的内存不够Mysql经常使用，这个时刻就会产生Mysql不可提供反常的服务造成整个下层的运行解体。

总结：

（1）从数据库扩容角度来看，由于宿服务器的数据文件是容器独占的，所以多个容器就会挂载在多个宿服务器文件上，虽然咱们可以有打算处置宿服务器文件数据共享的疑问，然而数据同步打算中存在必定弊病。

（2）内存资源过去思考，由于docker部署的运行是共享内存的，所以一旦某个运行占用内存过大就会造成其余运行由于内存无余而不可对外提供服务的疑问。

（3）不是说不能经常使用docker部署Mysql，在某些状况下docker部署的Mysql还是比拟适合的，如能够应用两边件和容器化系统能够智能伸缩、容灾、切换、自带多个节点等场景下是适合启动容器化。