第五天 主从复制

  从这一篇开始我们主要讨论mongodb的部署技术。

  我们知道mysql能够做到读写分离,双机热备份和集群部署,当然mongodb也能做到,实际应用中我们不希望数据库采用单点部署,如果碰到数据库宕机或者被毁灭性破坏那是多么的糟糕。

一、主从复制

  1、首先看看模型图

    

  2、从上面的图形中我们可以分析出这种架构有如下的好处:

    a. 数据备份

    b. 数据恢复

    c. 读写分离

  3、下面我们就一一实践

    实际应用中我们肯定是多服务器部署,限于自己懒的装虚拟机,就在一台机器上实践了。

    第一步:我们把mongodb文件夹放在D盘和E盘,模拟放在多服务器上。

    第二步:启动D盘上的mongodb,把该数据库指定为主数据库,其实命令很简单:>mongodb --dbpath=‘XXX‘ --master,端口还是默认的27017.

        

    第三步:同样的方式启动E盘上的mongodb,指定该数据库为从属数据库,命令也很简单,当然我们要换一个端口,比如:8888。source 表示主数据库的地址。

         >mongod --dbpath=xxxx --port=8888 --slave --source=127.0.0.1:27017

        

    第四步:从图中的红色区域我们发现了一条:“applied 1 operations"这样的语句,并且发生的时间相隔10s,也就说明从属数据库每10s就向主数据库同步数据,同步依据也就是寻找主数据库的”OpLog“日志,可以在图中红色区域内发现”sync_pullOpLog“字样。

        接下来我们要做的就是测试,惊讶的发现数据已经同步更新,爽啊。

        

  4、如果我还想增加一台从属数据库,但是我不想在启动时就指定,而是后期指定,那么mongodb可否做的到呢?答案肯定是可以的。

    我们的主或者从属数据库中都有一个叫做local的集合,主要是用于存放内部复制信息。

    好,那么我们就试一下,我在F盘再拷贝一份mongodb的运行程序,cmd窗口好多啊,大家不要搞乱了。

    

    看上面的log,提示没有主数据库,没关系,某一天我们良心发现,给他后期补贴一下,哈哈,再开一个cmd窗口,语句也就是

    在sources中add一个host地址,最后发现数据也同步到127.0.0.1:5555这台从属数据库中....

    

  5、读写分离

    这种手段在大一点的架构中都有实现,在mongodb中其实很简单,在默认的情况下,从属数据库不支持数据的读取,但是没关系,在驱动中给我们提供了一个叫做“slaveOkay"来让我们可以显示的读取从属数据库来减轻主数据库的性能压力,这里就不演示了。

二、副本集

  这个也是很牛X的主从集群,不过跟上面的集群还是有两点区别的。

  (1)  该集群没有特定的主数据库。

  (2)  如果哪个主数据库宕机了,集群中就会推选出一个从属数据库作为主数据库顶上,这就具备了自动故障恢复功能,很牛X的啊。

好,我们现在就来试一下,首先把所有的cmd窗口关掉重新来,清掉db下的所有文件。

  第一步: 既然我们要建立集群,就得取个集群名字,这里就取我们的公司名shopex, --replSet表示让服务器知道shopex下还有其他数据库,

      这里就把D盘里面的mongodb程序打开,端口为2222。指定端口为3333是shopex集群下的另一个数据库服务器。

       

  第二步:既然上面说3333是另一个数据库服务器,不要急,现在就来开,这里把E盘的mongodb程序打开。

      

  第三步:ok,看看上面的日志红色区域,似乎我们还没有做完,是的,log信息告诉我们要初始化一下“副本集“,既然日志这么说,那我也就这么做,随便连接一下哪个服务器都行,不过一定要进入admin集合。

       

  第四步: 开启成功后,我们要看看谁才能成为主数据库服务器,可以看到端口为2222的已经成为主数据库服务器。

       

  第五步:我们知道sql server里面有一个叫做仲裁服务器,那么mongodb中也是有的,跟sql server一样,仲裁只参与投票选举,这里我们把F盘的mongodb作为仲裁服务器,然后指定shopex集群中的任一个服务器端口,这里就指定2222。

       

  然后我们在admin集合中使用rs.addArb()追加即可。

       

   追加好了之后,我们使用rs.status()来查看下集群中的服务器状态,图中我们可以清楚的看到谁是主,还是从,还是仲裁。

       

  不是说该集群有自动故障恢复吗?那么我们就可以来试一下,在2222端口的cmd服务器按Ctrl+C来KO掉该服务器,立马我们发现在3333端口的从属服务器即可顶上,最后大家也可以再次使用rs.status()来看下集群中服务器的状态。

       

时间: 2024-10-12 13:59:43

第五天 主从复制的相关文章

8天学通MongoDB——第五天 主从复制

从这一篇开始我们主要讨论mongodb的部署技术. 我们知道sql server能够做到读写分离,双机热备份和集群部署,当然mongodb也能做到,实际应用中我们不希望数据库采用单点部署, 如果碰到数据库宕机或者被毁灭性破坏那是多么的糟糕. 一:主从复制 1: 首先看看模型图 2: 从上面的图形中我们可以分析出这种架构有如下的好处: <1>  数据备份. <2>  数据恢复. <3>  读写分离. 3:下面我们就一一实践 实际应用中我们肯定是多服务器部署,限于自己懒的装

MySQL第五章——主从复制

一.复制的基本原理 slave会从master读取binlog(二进制日志文件)进行数据同步 步骤: 详细操作步骤请参见:http://www.cnblogs.com/luckcs/articles/2543607.html 二.复制的基本原则 三.复制的问题 延时 四.一主一从常见配置 版本最好一致: 网段一致(能ping通): 配置都是在 [mysqld] 下,且都是小写(建议): 复制的配置参见:http://blog.csdn.net/yangyan19870319/article/de

20160916-3:mysql主从复制

一.什么是主从复制 将一个数据库节点的数据拷贝到一个或多个数据库节点(主节点—>从节点) 二.主从复制的原理 [简述]:将主节点上的变更操作存储到binlog,从节点建立了到主节点的复制关系后,会发起两个线程:IO thread和SQL thread,IO线程负责和主节点建立关系(长连接),将主节点的binlog异步实时保存到relay-log,接着SQL线程实时读取从节点的relay-log,如果relay-log有更新则根据日志内容在从节点上做数据操作. (1)binlog日志格式:stat

MySQL主从复制架构使用方法

一. 单个数据库服务器的缺点 数据库服务器存在单点问题 数据库服务器资源无法满足增长的读写请求 高峰时数据库连接数经常超过上限 二. 如何解决单点问题 增加额外的数据库服务器,组建数据库集群 同一集群中的数据库服务器需要具有相同的数据 集群中的任一服务器宕机后,其它服务器可以取代宕机服务器 三. MySQL主从复制架构 1. 主库将变更写入到主库的binlog中 一些MySQL版本并不会开启二进制日志,所以一定要检查是否开启 如果刚开始没有开启,后面再进行开启的话,需要重启数据库才能生效,而且数

MySQL备份和还原系列一:备份类型

一.mysql备份类型 1.按照mysql服务器状态 cold    离线备份,读.写操作均中止 warm    仅可执行读操作 hot     读.写操作不受影响 2.按照数据一致性 consistent inconsistent 3.按照备份数据格式 logical     备份sql语句,在恢复的时候执行备份的sql语句实现数据库数据的重现 physical    文件系统层面直接拷贝数据文件,但真正备份的时候自然不是cp这么简单 4.数据存储方式 full            完全备份

MongoDB 副本集的相关概念【转】

一.副本集基本概念 副本集(replica set) MongoDB的replica set是一个mongod进程实例簇,数据在这个簇中相互复制,并自动进行故障切换. MongoDB的数据库复制增加了冗余,确保了高可用性,简化了管理任务如备份,并且增加了读能力.大多数产品部署都使用了复制.MongoDB中primary处理写操作,其它进行复制的成员则是secondaries. 一个副本集可以最多支持12个成员,但是只有7个成员可以参与投票. 注:MongoDB同时提供了传统的master/sla

mysql备份攻略

一.MySQL备份类型 1.热备份.温备份.冷备份 (根据服务器状态) 热备份:读.写不受影响: 温备份:仅可以执行读操作: 冷备份:离线备份:读.写操作均中止: 2.物理备份与逻辑备份 (从对象来分) 物理备份:复制数据文件: 逻辑备份:将数据导出至文本文件中: 3.完全备份.增量备份.差异备份 (从数据收集来分) 完全备份:备份全部数据: 增量备份:仅备份上次完全备份或增量备份以后变化的数据: 差异备份:仅备份上次完全备份以来变化的数据: 4.逻辑备份的优点: 在备份速度上两种备份要取决于不

MySQL 备份与还原详解

相关阅读: MySQL备份和恢复具体实施 http://www.linuxidc.com/Linux/2012-12/76257.htm MySQL备份与恢复的三种方法总结 http://www.linuxidc.com/Linux/2012-12/75428.htm MySQL备份还原(视图.存储过程) http://www.linuxidc.com/Linux/2012-01/52665.htm 一.MySQL备份类型 1.热备份.温备份.冷备份 (根据服务器状态) 热备份:读.写不受影响:

3mysql查询截取分析

***explain   ****分析******* 1观察,至少跑一天,看看生产的慢SQL情况 2开启慢查询日志,设置阙值,比如超过5秒钟的就是慢SQL,并将它抓取出来 3explain+慢SQL分析 4show profile 5运维经理 or DBA,进行SQL数据库服务器的参数调优 *****总结***** 1慢查询的开启并捕获 2explain+慢SQL分析 3show profile查询SQL在Mysql服务器里面的执行细节和生命周期情况 4SQL数据库服务器的参数调优 ******