mongoDB服务器的安装配置

时间：2022-09-19 17:35:53

转至元数据结尾


1. 配置副本集
echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
echo "never" > /sys/kernel/mm/transparent_hugepage/defrag
cat >> /etc/profile.d/mongod.sh << EOF
ulimit -f unlimited
ulimit -t unlimited
ulimit -v unlimited
ulimit -n 64000
ulimit -m unlimited
ulimit -u 64000
EOF
source /etc/profile
###解决mongodb启动之后的报错

echo "mongokey" > /etc/mongo.key
chmod 600 /etc/mongo.key

cat > /etc/mongod.conf <<EOF 
port=27017
dbpath=/data/mongo/
logpath=/data/logs/mongodb.log
fork=true
logappend=true
#shardsvr=true
directoryperdb=true
httpinterface=true
#auth=true
#maxConns=2000
keyFile=/etc/mongo.key
replSet=replset
EOF
/opt/mongo/bin/mongod --config /etc/mongod.conf
/*配置文件方式启动副本集*/
/*auth=true绝对不能启用，auth=true，单机可启用*/

config = { _i
d:"replset", me
mbers:[
{_id:0,host:"10.0.18.10:27017"},
{_id:1,host:"10.0.18.11:27017"},
{_id:2,host:"10.0.18.12:27017"},
{_id:3,host:"10.0.18.13:27017"},
{_id:4,host:"10.0.18.14:27017"}]
}
rs.initiate(config);

/*然后在任意一台虚拟机登陆mongo,输入如上设置
可以看到副本集已经生效,在那台机器上面执行上述语句，哪台机器就是PRIMARY*/
 /*可以使用rs.status() 查看集群状态,或者rs.isMaster() */

2. 更改节点优先级
/*修改节点的优先级可以触发重新选举,这样可以人工指定主节点。 priority数值越大，优先级越高，大的会被选成新的primary
使用如下命令，在主节点登录，将10.0.18.3提升为Master 
需要注意的是，修改节点优先级需要登录Master节点运行 。否则报错 * /

rs.conf();
cfg=rs.conf();
cfg.members[0].priority=1
cfg.members[1].priority=1
cfg.members[2].priority=10
cfg.members[3].priority=3
rs.reconfig(cfg);

/*再次查看集群状态,可以看到10.0.18.12 已经作为Master运行*/
/*这个地方member的序号是从0开始的，不是rs.conf()结果中的id */

3. 节点类型
/*MongoDB的节点类型有主节点(Master)，副本节点(Slave或者称为Secondary)，仲裁节点，Secondary-Only节点，Hidden节点，Delayed节点和Non-Voting节点*/

/*仲裁节点不存储数据，只是负责故障转移的群体投票，这样就少了数据复制的压力*/
/*Secondary-Only:不能成为primary节点，只能作为secondary副本节点，防止一些性能不高的节点成为主节点*/
/*Hidden:这类节点是不能够被客户端制定IP引用，也不能被设置为主节点，但是可以投票，一般用于备份数据*/
/*Delayed：可以指定一个时间延迟从primary节点同步数据。主要用于备份数据，如果实时同步，误删除数据马上同步到从节点。所以延迟复制主要用于避免用户错误*/
/*Non-Voting：没有选举权的secondary节点，纯粹的备份数据节点*/

4. 设置隐藏节点(Hidden)
/*隐藏节点可以在选举中投票，但是不能被客户端引用，也不能成为主节点。也就是说这个节点不能用于读写分离的场景。
将10.0.18.4设置为隐藏节点。 注意，只有优先级为0的成员才能设置为隐藏节点。
如果设置优先级不为0的节点为隐藏节点，则报错如下*/

/*使用如下命令设置隐藏节点*/

cfg=rs.conf();
cfg.members[1].priority=10
cfg.members[2].priority=1
cfg.members[3].priority=0
cfg.members[3].hidden=1
rs.reconfig(cfg);

/*设置完成之后，使用rs.status() 查看该节点还是SECONDARY状态。
但是通过rs.isMaster()和rs.conf() 可以看到这个节点的变化。
rs.isMaster()的hosts中10.0.18.4 节点已经不可见*/

/*并且rs.conf() 显示该节点状态为hidden*/

5. 设置仲裁节点
/*仲裁节点不存储数据，只是用于投票。所以仲裁节点对于服务器负载很低。
节点一旦以仲裁者的身份加入集群，他就只能是仲裁者，无法将仲裁者配置为非仲裁者，反之也是一样。
另外一个集群最多只能使用一个仲裁者，额外的仲裁者拖累选举新Master节点的速度，同时也不能提供更好的数据安全性。
初始化集群时，设置仲裁者的配置如下*/

config = { _id:"replset", members:[
{_id:0,host:"192.168.1.1:27017"},
{_id:1,host:"192.168.1.2:27017",arbiterOnly:true},
{_id:2,host:"192.168.1.3:27017"}]
}

/*使用仲裁者主要是因为MongoDB副本集需要奇数成员，而又没有足够服务器的情况。在服务器充足的情况下，不应该使用仲裁者节点 */

6. 设置延迟复制节点
/*MongoDB官方没有增量备份方案，只有一个导出的工具mongodump。
他不能像数据库一样，通过binlog或者归档日志将数据推到事故发生的前一刻。
假设每天凌晨2点使用mongodump备份，而下午5点发生事故，数据库损毁，则凌晨2点到下午5点的数据全部都会丢失。
虽然副本集可以一定程度避免这个问题，但是默认情况下不能避免人为的失误。
比如没有指定筛选条件删除了全部的数据。副本节点会应用这个命令，删除所有副本节点的数据。
在这个场景下，可以使用延迟节点，它会延迟应用复制。
如果主节点发生了人为的失误，而这个操作因为延迟的原因，还没有应用在延迟节点。
这个时候，修改延迟节点的优先级为*，使他成为新的Master服务器*/

/*延迟节点的优先级必须为0.这个和hidden节点是一样的, 设置192.168.1.2为延迟节点*/

cfg=rs.conf();
cfg.members[3].priority=0
cfg.members[3].slaveDelay=300
cfg.members[3].hidden=true
cfg.members[3].buildIndexes=true
rs.reconfig(cfg);
#修改一个已经存在的secondary节点为延迟节点,优先级是0，隐藏节点和是否建立索引

rs.add({host:'192.168.2.214:27017',"slaveDelay":300,"priority":0,"hidden":true,"buildIndexes":false});
#新增加一个延迟节点，且设置该节点的相关信息
#可以通过rs.conf()来查看节点的状态，包括延迟信息
/*slaveDelay的单位是秒, 在192.168.1.1主节点删除一个集合所有数据，模拟人为失误*/
/*在10.0.18.2查看,发现数据已经全部丢失*/
/*而在10.0.18.2延迟节点，可以看到因为延迟复制的缘故，数据还在*/

/*这个时候千万不要提升延迟节点的优先级。因为这样他会立即应用原主节点的所有操作，并成为新的主节点。这样误操作就同步到了延迟节点。
首先，关闭副本集中其他的成员，除了延迟节点。
删除其他成员数据目录中的所有数据。确保每个其他成员的数据目录都是空的(除了延迟节点)
重启其他成员，他们会自动从延迟节点中恢复数据 */
7. 设置Secondary-Only节点
/*Priority为0的节点永远不能成为主节点，所以设置Secondary-only节点只需要将其priority设置为0 */

8. 设置Non-Voting节点
/*假设设置10.0.18.5不能投票,则使用如下命令*/

cfg=rs.conf();
cfg.members[4].votes=0;
rs.reconfig(cfg);

9. 增加一个副本集成员

rs.add("10.0.18.14:27017")
rs.conf()
10. 副本集成员状态
/*副本集成员状态指的是rs.status()的stateStr字段*/

STARTUP：刚加入到复制集中，配置还未加载
STARTUP2：配置已加载完，初始化状态
RECOVERING：正在恢复，不适用读
ARBITER: 仲裁者
DOWN：节点不可到达
UNKNOWN：未获取其他节点状态而不知是什么状态，一般发生在只有两个成员的架构，脑裂
REMOVED：移除复制集
ROLLBACK：数据回滚，在回滚结束时，转移到RECOVERING或SECONDARY状态
FATAL：出错。查看日志grep “replSet FATAL”找出错原因，重新做同步
PRIMARY：主节点
SECONDARY：备份节点

11. 读写分离
如果Master节点读写压力过大，可以考虑读写分离的方案。
/*不过需要考虑一种场景，就是主服务器的写入压力非常的大，所以副本节点复制的写入压力同样很大。
这时副本节点如果读取压力也很大的话，根据MongoDB库级别读写锁的机制，
很可能复制写入程序拿不到写锁，从而导致副本节点与主节点有较大延迟*/

如果进行读写分离，首先需要在副本节点声明其为slave,

rs.slaveOk()

/*rs.slaveOk() 后才可以让SECONDARY节点可读，但是不可写*/

标签：

相关文章