MongoDB复制集

MongoDB目前的高可用架构主要有主从、复制集、以及分片，单纯的主从技术几乎被淘汰，整个稳定性以及可靠性方面复制集要比主从好，所以现在更多的会去使用复制集。在接下来的实践过程中，我们将通过多实例的方法实现复制集。以及会解析搭建过程中遇到的困难问题。

一、基础环境与规划

操作系统：CentOS 6.7

MongoDB版本：3.4.5

实例部署情况：

主机IP 数据目录 日志文件 端口
127.0.0.1 /data/mongoDB/data/m17 /data/mongoDB/logs/mongo17.txt 28017
127.0.0.1 /data/mongoDB/data/m18 /data/mongoDB/logs/mongo18.txt 28018
127.0.0.1 /data/mongoDB/data/m19 data/mongoDB/logs/mongo19.txt 28019

由于在同一台主机上面部署，所以就不需要考虑防火墙的配置与管理。大多数生产环境都有专业的硬件防火墙（思科、华为）等厂商的硬件防火墙设备，部分的公有云也是有一些防火墙的产品，所以Iptables在生产环境中应该能起到锦上添花的作用，在整个过程中不考虑这一块。

二、副本集原理与优化

2.1 副本集原理

复制集（Replica Set），就是有自动故障恢复功能的主从集群。主从结构和复制集最明显的区别是副本集没有固定的主节点，当节点故障时，能选举新的主节点，大大的提升了整个系统中数据存储的稳定性；整个集群选举出一个主节点，当主节点不能正常工作时，会选举出另一个节点为主节点，

复制集总会有一个活跃节点（Primary）和一个或者多个备份节点（Secondary）,副本集中还可以有一个角色是仲裁者（Arbiter），它并不保存数据。仲裁节点使用最小的资源并且不要求硬件设备，不能将Arbiter部署在同一个数据集节点中，可以部署在其他应用服务器或者监视服务器中，也可部署在单独的虚拟机中。为了确保复制集中有奇数的投票成员（包括primary），需要添加仲裁节点做为投票，否则primary不能运行时不会自动切换primary。

在比较早的版本例如MongoDB2.6中，复制集中参与选举的数据节点（包括primary）只能有7个 可以通过更改数据节点属性的方法将复制集的数据节点增加到12个，但是其余的5个为非投票成员（Non-Voting Members），非投票成员是副本集中数据的备份副本，不参与投票，但可以被投票或成为主节点。当我们的复制集超过11个时，可以使用传统的主从方法 数量不限制。

2.2 复制集的特点

复制集的特点

  • 数据一致性 使得多个进程/服务器在某个方面保持相同   异步同步（受磁盘、网络、数据大小影响）
  • 主是唯一 只有1台主能进行读写,其余的只能读，同时主不是固定的 ，不像MySQL具有双主架构，
  • 大多数原则  集群存活节点小于或等于二分之一时集群不可写 只可读
  • Secondary节点不支持写入   MySQL从库的readonly对具有super权限的账户无效
  • 相比传统的主从结构  复制集可以自动容灾
  • 不支持类似MYSQL只从中只同步部分库的功能
  • 副本集之间的复制是通过oplog日志现实的.备份节点通过查询这个集合就可以知道需要进行复制的操作
  • oplog是节点中local库中的一个固定的集合,在默认情况下oplog初始化大小为空闲磁盘的5%.oplog是capped collection,所以当oplog的空间被占满时,会覆盖最初写入的日志.
  • 通过改变oplog文档的大小直接改变local所占磁盘空间的大小.可以在配置文件中设置oplogSize参数来指定oplog文档的大小,例如oplogSize=1024单位默认为M  每个local文档在磁盘空间的空间都为2G,设置不足2G的,初始化依然为2G大小,例如上面oplogSize=1024,但创建的local.01大小依然为2G.
  • 如果备份节点不幸挂掉,由于复制过程中是先写数据,再写oplog,这样重新启动时,可能会重复复制操作.但mongodb在设计过程中已经考虑过这个问题.当 oplog中同一个操作执行多次的时候,只执行一次.
  • 如果备节点的同步速度远远跟不上主节点的oplog写入的数据,并且主节点的oplog被覆盖.这样,可能就无法同步那些被覆盖的数据(出现这种情况,暂时还无法解决,只能通过备份主节点的数据,然后再重新同步).
  • 每个成员通过心跳去查看其他节点的状态,每隔2秒钟就有一次心跳检测.
  • 当主节点宕机之后,各个节点通过选举的方式来选择下一个主节点

2.3 复制集的实现步骤

  1. 规划端口、数据目录、日志目录等可以将其定制成配置文件；
  2. 为了安全需要准备其验证 （auth 验证和keyFile验证）

    auth验证与keyFile验证的区别：auth更多的是实现单机版或者单实例的验证，这是MongoDB常见的安全加固方式之一，开启验证，对不同的库和用户做授权管理，而keyFile主要是用来集群之间不同示例之间的验证，主要有以下特点

    keyFile特点：

基于base 64编码集 仅能识别[a-z A-Z + /]等内容，（传说中的    没具体的测试 ）

长度最好小于 1000byte

权限问题 允许的最大的权限是600 所以在安装、配置、启动等环节需要注意所有者和所属组。

报错解决：
mongod   -f  conf/29017.cnf  #启动
about to fork child process, waiting until server is ready for connections.
forked process: 2681
ERROR: child process failed, exited with error number 1
查看日志：
2017-06-01T00:10:39.307+0800 I CONTROL  [main] ***** SERVER RESTARTED *****
2017-06-01T00:10:39.490+0800 I ACCESS   [main] permissions on /datamongo/key/.keyFile are too open

发现权限太大，导致不能正常启动，将keyFile的权限更改为600解决。

keyFile文件中时忽略空格、制表符、换行符的  以下内容可以等同

This name  docker     thisnamedocker

生成keyFile的方法推荐

openssl  rand   -base 64     N(字节数)

[[email protected] log]# openssl   rand  -base64   7
8ZNRiPFguw==
[[email protected] log]# openssl   rand  -base64   10
IAcXv1pLK67/qw==
[[email protected] log]# openssl   rand  -base64   12
LhhGR4GPk0dlTsLz
[[email protected] log]# openssl   rand  -base64    512
VgC2wexhxefk3F1P1fnSNJcsp/wwnG3bugoccgLLupvLSSZGRa73PMl4ju+35uWf
45WAMiTZ2emIp2Wg6qdQLD3n2OdhZ6zF49VtpOal8Pok6hfVvq+Kr6FuEwI6Vrcu
fa/XnnUCr69WIjILRkqIgfJZE3N+J3QExZBWFX28zoBlEoyjusEIQfP3Fod+XiIF
EWENFlvAKNUFLts13ad9g3PornXvFsyqf1AH8rf1y+I9VbiHDHYNMpNBXtfk+Sh+
E8mG4IH2/FfSvLsn4fdYSZ3ZnD2Tfogk9Jhk6zdqO+drm0Yf6WL4cxMAHhKWdbps
FAyjmis3sltWloshwqt4q+xtAo4JSYnT4Bo9MF8tyIb4ZZ2S6xIEjUV+FBELYGJO
AVz6F39bHU0qeuWNL8wMHb8YCXaNzrY/a9OFP3ZaaeGz6fUH6ZZJe3T5OE2IB+eF
3vQZrSF/0bBG3hM5E6ziTIp9+HF4c1+Ltq5bMdLaKioEvc3kAFq0q34JlFxjC4/m
aXasERqcvznLWb+3zXYbJiPpqxlOevEToXOGgmdkzAUrz5+g8IihPeOizO5iugt4
wwgki2ktnmU1l+wPqHPDUdW2/Hpvgdd5aHweDyu7Mc1OFAcvg53abxca2qi5g3Iu
1lVI12FDvSjRFO7bmM34rKxIgFuaiH4kQUmP+unLLSo=
[[email protected] log]# openssl   rand  -base64    512 >.keyFile
[[email protected] log]#

根据上面内容识别方法生成的文件中的“=”号是不能被识别的，要对其特殊处理，

3、启动副本集

在启动时，我们可以给mongd带好多的参数，但是这样比较麻烦，每次启动都要制定很多的参数，建议我们写配置文件；

#MOngoDB config 
port=27017                         #启动监听端口
dbpath=/data/mongoDB/data/m17     #数据存储目录
logpath=/data/mongoDB/logs/mongo17.txt   #日志文件目录
logappend=true                #日志以追加的方式写入
pidfilepath=/datamongo/data/m17/27017.pid  
fork=true                       #以后台运行开启
oplogSize=1024                #初始化oplog的大小为1024M 
replSet=BOOL                    #副本集名称为BOOL  很重要的参数 必须统一
keyFile=/datamongo/key/.keyFile    #keyFile验证文件的位置
setParameter=enableLocalhostAuthBypass=1  #避免在没有创建用户之前的 开启验证的权限问题

setParameter=enableLocalhostAuthBypass=1  该参数设置的特点

  • MongoDB实例中，没有任何用户时，才能生效
  • 仅允许本机(localhost)登录,不能使用IP登录（包括127.0.0.1）
  • 在实例创建用创建的第一个用户后失效
  • 实例创建的第一个用户 必须属于admin库  并且该用户必须具有创建其他用户的权限

4、初始化副本集

随意进入其中的一个服务，进入admin库对其初始化，

use  admin
var   conf=({_id:"BOOL",
members:[
{"_id":0,host:"127.0.0.1:27017",priority:1},
{"_id":0,host:"127.0.0.1:27018",priority:2},
{"_id":0,host:"127.0.0.1:27019",priority:3}
]
})
rs.initiate(conf)
执行OK

注意：

priority是个可选的参数，该参数可以决定该副本集中的节点成为primary节点的优先级，数字越大，优先级越高，在我们不同的主机之间存在性能差异时，我们可以合理的使用该参数，当不想让某一个节点永远不能成为primary节点时，就可以将priority参数设置成0 

附件：

初始化脚本

#/bin/bash
################################describtion########################
#date 2017-07-08
#author  peng
#mail:[email protected]

HOST_IP=127.0.0.1
DATA_DIR=/data/mongoDB/data/
LOGS_DIR=/data/mongoDB/logs/
MONGOD_PATH= /home/mongodb/mongodb/mongodb-3.4.5/bin/
NA=DB2

mkdir  -p  ${DATA_DIR}m17     ${DATA_DIR}m18   ${DATA_DIR}m19  ${LOGS_DIR}

${MONGOD_PATH}mongod   --dbpath ${DATA_DIR}m17 --logpath  ${LOGS_DIR}logs1   --port  28017 --smallfiles  --replSet ${NA} --fork
${MONGOD_PATH}mongod   --dbpath ${DATA_DIR}m18 --logpath  ${LOGS_DIR}logs2   --port  28018 --smallfiles  --replSet ${NA} --fork
${MONGOD_PATH}mongod   --dbpath ${DATA_DIR}m19 --logpath  ${LOGS_DIR}logs3   --port  28019 --smallfiles  --replSet ${NA} --fork

${MONGOD_PATH}mongo --port 28017  <<EOF
use admin
var db2config={
_id:"DB2",
members:[
{_id:0,host:"${HOST_IP}:28017"},
{_id:1,host:"${HOST_IP}:28018"},
{_id:2,host:"${HOST_IP}:28019"}
]

}
rs.initiate(db2config);

注意事项：

在我们复制集设置了keyFile验证后，我们初始化之后，在priamary节点想查看一下都有那些库，发现权限不够，这时我们就考虑创建用户

 mongo   127.0.0.1:29017/admin
MongoDB shell version v3.4.5
connecting to: mongodb://127.0.0.1:29017/admin
MongoDB server version: 3.4.5
BOOL:PRIMARY> show  dbs
2017-06-01T01:27:04.487+0800 E QUERY    [thread1] Error: listDatabases failed:{
        "ok" : 0,
        "errmsg" : "not authorized on admin to execute command { listDatabases: 1.0 }",
        "code" : 13,
        "codeName" : "Unauthorized"
} :
[email protected]/mongo/shell/utils.js:25:13
[email protected]/mongo/shell/mongo.js:62:1
[email protected]/mongo/shell/utils.js:769:19
[email protected]/mongo/shell/utils.js:659:15
@(shellhelp2):1:1

这时我们可以创建一个用户，多次测试 复制集在未创建用户时，将setParameter=enableLocalhostAuthBypass=1
参数注释后重启，直接可以到admin库创建用户
db.createUser(
...  {user:"root",
...  pwd:"123123",
... roles:[
... {role:"root",db:"admin"}
...  ]
...   }
... )
Successfully added user: {
        "user" : "root",
        "roles" : [
                {
                        "role" : "root",
                        "db" : "admin"
                }
        ]
}

参考文档

http://blog.csdn.net/leftfist/article/details/39583585

http://blog.csdn.net/kk185800961/article/details/45791903

时间： 2024-08-01 10:44:20

MongoDB复制集的相关文章

MongoDB复制集及数据分片详解

前言 MongoDB是一个由C++语言编写的基于分布式文件存储的数据库,是当前NoSQL数据库中比较热门的一种,旨在为Web应用提供可扩展的高性能数据存储解决方案.本文介绍MongoDB复制集及数据分片. MongoDB 简介 MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的.支持的数据结构非常松散,因此可以存储比较复杂的数据类型.最大的特点是其支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询

mongodb复制集的实现

复制集(Replica Sets),是一个基于主/从复制机制的复制功能,进行同一数据的异步同步,从而使多台机器拥有同一数据的都多个副本,由于有自动故障转移和恢复特性,当主库宕机时不需要用户干预的情况下自动切换到其他备份服务器上做主库,一个集群最多可以支持7个服务器,并且任意节点都可以是主节点.所有的写操作都被分发到主节点,而读操作可以在任何节点上进行,实现读写分离,提高负载. 资源有限测试一个VM开3个实例: 环境:centos7.0 192.168.1.21:20011 P 192.168.1

MongoDB复制集原理

版权声明:本文由孔德雨原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/136 来源:腾云阁 https://www.qcloud.com/community MongoDB的单实例模式下,一个mongod进程为一个实例,一个实例中包含若干db,每个db包含若干张表.MongoDB通过一张特殊的表local.oplog.rs存储oplog,该表的特点是:固定大小,满了会删除最旧记录插入新记录,而且只支持append操作,因

mongodb复制集配置步骤

mongodb复制集配置步骤 2012-11-09 14:10:24|  分类: mongodb|举报|字号 订阅 复制升级版的主从复制,它实现了故障自动转移功能,同时从节点支持读 一,节点类型: a)    主节点:支持读写 b)    从节点:支持读(需设置) c)    仲裁节点:参与投票同时也支持读(需设置) 二,实验 主节点:192.168.129.47 从节点:192.168.129.48 仲裁节点:192.168.129.49 1.主节点配置如下: vi  /etc/rc.loca

一步一步教你搭建基于docker的MongoDB复制集群环境

一步一步教你搭建基于docker的MongoDB复制集群环境 1.安装docker 2.创建MongoDB的Image 3.搭建MongoDB的集群 Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中. 1.ubuntu14.04安装docker 参考文档 http://docs.docker.com/installation/ubuntulinux/ 参考文档 http://docs.docker.com/mac/started/ pc@pc-Th

MongoDB复制集数据库拆分和版本升级实战

MongoDB复制集数据库拆分和版本升级实战 问题描述 复制集rs_1上承载了所有的数据库业务,而加内存已经无法满足应用程序压力. 解决方案 考虑拆分复制集rs_1的部分数据库到rs_2,并同时升级数据库版本到2.6. 架构图 准备 评估升级可能性 1. 连接2.6 mongo shell到2.4 复制集辅助成员,在admin库执行db.upgradeCheckAllDBs().   2. 评估升级到2.6的应用程序兼容性问题,参考:http://docs.mongodb.org/manual/

MongoDB 复制集

关于读写分离 由于写入主之后,同步到从有一个时间,所以读写分离会引发数据一致性问题. MongoDB 通过复制集(Replica Set)来实现读写分离. MongoDB复制集(Replica Set) 通过存储多份数据副本来保证数据的高可靠,通过自动的主备切换机制来保证服务的高可用. 当遇到复制集轮转升级.Primary宕机.网络分区等场景时,复制集可能会选举出一个新的Primary,而原来的Primary则会降级为Secondary,即发生主备切换.所以,MongoDB复制集里Primary

MongoDB复制集架构

MongoDB复制集架构 由数据结点,投票结点组成,需要配置集群信息,可自动检测集群中的结点健康状态,当有结点出故障时,自动下线和切换主从结点.适用于数据量较大,高可用服务 通常,为了防止单点故障应用程序需要做集群.然而在数据库中除了防止单点故障,还需要做到数据库备份,读写分离,故障转移等.而 MongoDB 的 Replica Set 恰恰都能满足这些要求. Replica Set角色 Replica Set 的成员是一堆有着同样的数据内容 mongod 的实例集合,包含以下三类角色: 主节点

MongoDB复制集技术

第1章 MongoDB复制集简介: 一组MongoDB复制集,就是一组MongoDB进程,这些进程维护同一个数据集合,复制集提供了数据冗余和高等级的可靠性,这是生产部署的基础 1.1 复制集的目的: 保证数据在生产部署是的冗余和可靠性,通过在不同的机器上保存副本来保证数据的不会因为单间损坏而丢失,能够随时应对数据丢失或者机器损坏带来的风险 还可以提高用户读写数据的性能,提高整个系统的负载 1.2 简单介绍: 1.      一组复制集就是一组MongoDB实例掌管同一个数据集,实例可以在不同的机

配置MongoDB复制集

什么是复制集? 复制集是额外的数据副本,是跨多个服务器同步数据的过程,复制集提供了冗余并增加了数据可用性,通过复制集可以对硬件故障和中断的服务进行恢复.复制集的优势如下: 让数据更安全 高数据可用性(24*7) 灾难恢复 无停机维护(如备份.索引重建.故障转移) 读缩放(额外的副本读取) 副本集对应用程序是透明的 复制集工作原理 MongoDB的复制集至少需要两个节点.其中一个是主节点(Primary),负责处理客户端的请求,其余的都是从节点(Secondary),负责复制主节点上的数据.Mon