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.可见这样恢复一定是很慢的.
posted on 2016-02-07 13:03 LittlePony 阅读(3967) 评论(0) 编辑 收藏 举报