MongoDB仲裁节点的理解及Memcached,Zookeeper,Redis故障恢

在进行副本集部署时我们会添加一个或多个仲裁节点,仲裁节点不用于备份数据,由于它职责的职责是负责选举主节点,所以对硬件没有太高要求,可以将它部署在单独的服务器上,这个服务器可以是监听服务器,也可以部署在虚拟机上,但是有一点仲裁节点一定不能备份数据.仲裁节点和注解点都可以参与选举,而选举对象是各个非投票成员,也就是需要备份数据的从节点.

图例

MongoDB仲裁节点的理解及Memcached,Zookeeper,Redis故障恢复方案思考

这让我想起了以前了解过的zookeeper集群中的选举方案,它和MongoDB有所不同.

ZooKeeper采用一种称为Leader election的选举算法。在整个集群运行过程中,只有一个Leader,其他的都是Follower,如果ZooKeeper集群在运行过程中Leader出了问题,系统会采用该算法重新选出一个Leader。因此,各个结点之间要能够保证互相连接,必须配置上述映射。

ZooKeeper集群启动的时候,会首先选出一个Leader,在Leader election过程中,某一个满足选举算的结点就能成为Leader。

而对于memcached不提供分布式方案,我们可以利用代理服务器来实现分布式部署.而Magent就是一个memcached代理服务器,但是它不存在什么leader,secondary,所有的命令入口都是magent这个代理服务器,当某个节点出现done机时,而请求数据找不到,它会从备份节点上获取.当让我们可用通过zookeeper来管理memcached分布式集群.

而对于Redis  当设置好slave服务器后,slave会建立和master的连接,然后发送sync命令。无论是第一次同步建立的连接还是连接断开后的重新连 接,master都会启动一个后台进程,将数据库快照保存到文件中,同时master主进程会开始收集新的写命令并缓存起来。后台进程完成写文件 后,master就发送文件给slave,slave将文件保存到磁盘上,然后加载到内存恢复数据库快照到slave上。接着master就会把缓存的命 令转发给slave。而且后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从 client发送的命令使用相同的协议格式。当master和slave的连接断开时slave可以自动重新建立连接。如果master同时收到多个 slave发来的同步连接命令,只会使用启动一个进程来写数据库镜像,然后发送给所有slave。对于master出现故障时,我们可以通过持久化数据来恢复,而对于salve出现故障那么它会和master重新连接然后将所有的内从快照写入slave.可见这样恢复一定是很慢的。

更多MongoDB相关教程见以下内容

CentOS 编译安装 MongoDB与mongoDB的php扩展

CentOS 6 使用 yum 安装MongoDB及服务器端配置

Ubuntu 13.04下安装MongoDB2.4.3

MongoDB入门必读(概念与实战并重)

Ubunu 14.04下MongoDB的安装指南

《MongoDB 权威指南》(MongoDB: The Definitive Guide)英文文字版[PDF]

Nagios监控MongoDB分片集群服务实战

基于CentOS 6.5操作系统搭建MongoDB服务 uxidc.com/Linux/2014-11/108900.htm

MongoDB 的详细介绍请点这里
MongoDB 的下载地址请点这里

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/d886a10931509ae3695cc85970267848.html