【基础】MongoDB: master - slave 架构

最新推荐文章于 2024-04-03 09:00:42 发布

gardener_db

最新推荐文章于 2024-04-03 09:00:42 发布

阅读量2k

点赞数

分类专栏： mongodb 文章标签： mongodb 负载均衡任务 api 网络

本文链接：https://blog.csdn.net/gardener_db/article/details/7333348

版权

本文介绍了MongoDB的主从复制（master-slave）架构，对比了其与Replica Set在数据冗余、失效备援、读负载均衡、维护和故障恢复方面的优缺点。主从架构因其简单性和在特定场景下的可靠性，仍有一定的应用价值。文中还详细展示了master和slave的配置步骤，并提到了注意事项，如不同机器上的dbpath不能指向同一目录，以及slavedelay选项防止错误操作的实用性。

摘要由CSDN通过智能技术生成

MongoDB的Replication架构有两种，master/slave和Replica Set。
MongoDB力推的是Replica Set。但在这里主要想介绍的是master/slave。

1. 相比Replica Set。为什么还要选择master/slave。
对于Replication，MongoDB提出了5大优点。我们依次来看，两种架构在这些方面的表现。
1.1 Data Redundancy(数据冗余)
    master/slave 通过slave节点进行备份，Replica Set本身就是多节点。两者都可以很好的完成冗余备份的任务。

1.2 Automated Failover(失效备援)
    master/slave，如果master节点宕掉了，slave无法接替写数据的任务，系统将只能提供读取服务。
    Replica Set，如果Primary宕掉了，可以立即选举一个新的Primary。系统不受影响，可以继续提供服务。
    显然，对于High Availability(可用性)来说，Replica Set是完胜的。

1.3 Distributing read load(读负载均衡)
    和数据冗余一样，两者没有太大区别

1.4 Simplify maintenance(维护)
    master/slave，如果master宕掉了，系统停止服务，等待重新启动master。如果slave宕掉了，重新启动slave，slave同步后继续提供服务。
    Replica Set，无论什么角色，只需要重起(同步后)就可以继续提供服务。
    R