本文介绍了MongoDB在Windows和Mac上的安装方法，详细讲解了MongoDB配置文件的位置和启动命令。接着，文章深入探讨了MongoDB的集群概念，特别是副本集的配置和同步数据过程，包括异步复制、故障转移机制以及如何设置副本集权重和读写策略。最后，提供了初始化副本集和后台启动MongoDB的命令。
MongoDB安装、群集原理
安装
-
Windows
直接在官网下载
配置文件为安装路径下/bin/mongod.cfg
启动：net start mongodb
停止：net stop mongodb -
Mac（解压包安装）
去下载官网TGZ包，在电脑解压，进入/bin目录输入./mongod即可运行，不推荐使用，所有配置必须启动时带命令参数 -
Mac（brew安装）
MongoDB 不再开源 brew install mongodb 命令下载不了
使用brew install mongodb-community@4.2下载
安装完成后各文件路径
配置文件：/usr/local/etc/mongod.conf
日志目录路径：/usr/local/var/log/mongodb
数据目录路径：/usr/local/var/mongodb
3.0版本以前配置文件：
dbpath=/data/mongodb/data/mongod
logpath=/data/mongodb/logs/mongo.log
logappend=true
bind_ip=127.0.0.1
port=27017
fork=true
journal=true
3.0版本以后配置文件：
- 注意：
只能使用空格，不支持tab键
systemLog:
destination: file
path: /usr/local/var/log/mongodb/mongo.log
logAppend: true
storage:
dbPath: /usr/local/var/mongodb
net:
bindIp: 127.0.0.1
安装完成后可以在终端输入
查看版本：./mongod --verison
启动：./mongod --config 配置文件路径
MongoDB默认不是支持远程连接，只能自己电脑连接，修改配置文件：bindIp: 127.0.0.1 -> bindIp: 0.0.0.0
群集
MongoDB群集分为两种：主从和副本集。主从形式已经不使用了（这里简单描述一下），现在都使用副本集（自带主从）。
-
配置主从服务器（老版本）
在主MongoDB配置文件中添加：
master = true
在从MongoDB配置文件中添加：
slave = true
用于从节点，指定从节点的复制来源（主节点的IP+端口），source = 主节点IP:主节点端口 -
配置副本集
主从两台服务配置文件均添加
replication:
#设置oplog的大小(MB)
oplogSizeMB: 20480
#集群名称
replSetName: rs
在任意一台机器执行mongo命令登录数据库，执行：
rs.initiate({_id:"rs",members:[
{_id:0,host:"第一台机器IP:端口"},
{_id:1,host:"第二台机器IP:端口"},
{_id:2,host:" 第三台机器IP:端口"}]})
输入rs.status()可以查看集群状态
{
"set" : "rs",
"date" : ISODate("2020-02-08T06:34:04.161Z"),
"myState" : 1,
"term" : NumberLong(18),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"majorityVoteCount" : 2,
"writeMajorityCount" : 2,
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"lastCommittedWallTime" : ISODate("2020-02-08T06:33:54.866Z"),
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"readConcernMajorityWallTime" : ISODate("2020-02-08T06:33:54.866Z"),
"appliedOpTime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"durableOpTime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"lastAppliedWallTime" : ISODate("2020-02-08T06:33:54.866Z"),
"lastDurableWallTime" : ISODate("2020-02-08T06:33:54.866Z")
},
"lastStableRecoveryTimestamp" : Timestamp(1581143584, 1),
"lastStableCheckpointTimestamp" : Timestamp(1581143584, 1),
"electionCandidateMetrics" : {
"lastElectionReason" : "electionTimeout",
"lastElectionDate" : ISODate("2020-02-08T03:21:07.501Z"),
"electionTerm" : NumberLong(18),
"lastCommittedOpTimeAtElection" : {
"ts" : Timestamp(1581132043, 1),
"t" : NumberLong(16)
},
"lastSeenOpTimeAtElection" : {
"ts" : Timestamp(1581132043, 1),
"t" : NumberLong(16)
},
"numVotesNeeded" : 2,
"priorityAtElection" : 1,
"electionTimeoutMillis" : NumberLong(10000),
"numCatchUpOps" : NumberLong(0),
"newTermStartDate" : ISODate("2020-02-08T03:21:08.120Z"),
"wMajorityWriteAvailabilityDate" : ISODate("2020-02-08T03:21:09.308Z")
},
"members" : [
{
"_id" : 0,
"name" : "192.168.124.8:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 11588,
"optime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"optimeDate" : ISODate("2020-02-08T06:33:54Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1581132067, 1),
"electionDate" : ISODate("2020-02-08T03:21:07Z"),
"configVersion" : 1,
"self" : true,
"lastHeartbeatMessage" : ""
},
{
"_id" : 1,
"name" : "192.168.124.20:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 11562,
"optime" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"optimeDurable" : {
"ts" : Timestamp(1581143634, 1),
"t" : NumberLong(18)
},
"optimeDate" : ISODate("2020-02-08T06:33:54Z"),
"optimeDurableDate" : ISODate("2020-02-08T06:33:54Z"),
"lastHeartbeat" : ISODate("2020-02-08T06:34:03.483Z"),
"lastHeartbeatRecv" : ISODate("2020-02-08T06:34:02.149Z"),
"pingMs" : NumberLong(45),
"lastHeartbeatMessage" : "",
"syncingTo" : "192.168.124.8:27017",
"syncSourceHost" : "192.168.124.8:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 1
}
],
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1581143634, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1581143634, 1)
}
副本集同步数据过程
Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败，则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。简单的说就是：
当Primary节点完成数据操作后，Secondary会做出一系列的动作保证数据的同步：
1：检查自己local库的oplog.rs集合找出最近的时间戳。
2：检查Primary节点local库oplog.rs集合，找出大于此时间戳的记录。
3：将找到的记录插入到自己的oplog.rs集合中，并执行这些操作
副本集的同步和主从同步一样，都是异步同步的过程，不同的是副本集有个自动故障转移的功能。其原理是：slave端从primary端获取日志，然后在自己身上完全顺序的执行日志所记录的各种操作（该日志是不记录查询操作的），这个日志就是local数据 库中的oplog.rs表，默认在64位机器上这个表是比较大的，占磁盘大小的5%，oplog.rs的大小可以在启动参数中设 定：–oplogSize 1000,单位是M。
注意：在副本集的环境中，要是所有的Secondary都宕机了，只剩下Primary。最后Primary会变成Secondary，只能提供读服务。
- 注：
在配置副本集时候可以指定权重，权重高的优先当主节点。
常规节点（standard）：参与投票有可能成为活跃节点
副本节点（passive）：参与投票，不能成为活跃节点
仲裁节点（atbiter）：只参与投票，不复制节点，也不能成为活跃节点
priority：0——1000之间，0代表副本节点，其它代表常规节点
rs.initiate({_id:"rs",members:[
{_id:0,host:"第一台机器IP:端口",priority:2},
{_id:1,host:"第二台机器IP:端口",priority:1},
{_id:2,host:" 第三台机器IP:端口",arbiterOnly:true}]})
- 容忍数：
假设复制集内投票成员（后续介绍）数量为 N，则大多数为 N/2 + 1，当复制集内存活成员数量不足大多数时，整个复制集将无法选举出 Primary，复制集将无法提供写服务，处于只读状态。
| 投票成员数 | 大多数 | 容忍失败数 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
注意：mongodb默认是从主节点读写数据的，副本节点上不允许读，需要设置副本节点可以读：
repset:SECONDARY> db.getMongo().setSlaveOk();
用程序连接或navicat等第三方连接从节点可以读
后台启动：mongod --dbpath 路径 --replSet 集群名 --fork
–fock：守护进程
docker run --name mongo -v ~/data/db/:/data/ -p 27017:27017 -d mongo --replSet rs
rs.initiate({_id:“rs”,members:[
… {_id:0,host:“172.17.0.8:27017”}]})
{ “ok” : 1 }
https://blog.csdn.net/weixin_34409822/article/details/92009878
扫一扫
1115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
