基于 Docker的MongoDB 主从集群

阅读本文大约需要 9 分钟

如果对 Docker 不太懂，可以看看我之前的文章。 这篇文章主要讲以下三个内容：

前序--聊聊数据库升级方案

一主一从

一主两从

一主一从一仲裁

本来是想用 MongoDB 的 Docker 最新镜像的，但是 最新镜像默认绑定了 localhost （详见官网）才能连接数据库，当然，我们也可以进行修改。那我这边为了方便，就直接使用 mongo 3.4 ，因为 3.4 的版本没有绑定 localhost 省去一部分麻烦。

前序 -- 聊聊数据库升级方案

在学习集群之前，我们来聊聊数据库的升级方案，我个人认为有如下一些阶段，如果我的认知有错误，也烦请读者朋友指出。

一主一从

不用新建相应文件目录，直接运行 yml 文件即可。 在运行 yml 文件之后，执行以下初始化操作： 进入 master 的 mongo 命令行：

插入一条数据：

进入 slaver 的 mongo 命令行：

查看副本集信息：

rs.slaveOk() 的功能

在 slave 中，查询到了 master 中插入的信息 尝试在 slave 中，插入信息：

插入失败，显示报错信息。

优缺点：master-slave 结构，当 master 挂了，slave 不会被选举为 master，所以这种结构只起到了备份数据的作用

一主两从

不用新建相应文件目录，直接运行 yml 文件即可。 在运行 yml 文件之后，执行以下初始化操作：

初始化各个节点：

查看配置与副本级状态

插入信息到主节点：

在副本集中检测信息是否同步：

故障测试：

分别查看其它节点的信息：注意进入 mongo 命令行后的主从标识符

优缺点：

可进行读写分离

具备故障转移能力

一主一从一仲裁

不用新建相应文件目录，直接运行 yml 文件即可。 在运行 yml 文件之后，执行以下初始化操作：

初始化各个节点：

查看配置与副本级状态

插入信息到主节点：

在副本集中检测信息是否同步：

故障测试：

分别查看其它节点的信息：

可以看到最后一行标注为： PRIMARY 故障转移成功

可以看到最后一行标注为： ARBITER

优缺点：

具备故障转移能力

仲裁节点起到选举作用，节省部分资源