Mongodb升级方案概述

Mongodb现在最新已经发布到4.4.5版,在日常运维工作中,时常有数据库升级的需求,相对于其他数据库产品来说,Mongodb的版本升级相对简单,所以本文对mongodb的升级进行简单介绍,以及介绍一下之前升级过程中碰到的问题总结。

与所有数据库产品一样,有逻辑迁移升级和物理升级两种方式。

一.  逻辑迁移升级
提前搭建新版本数据库,然后mongodump/mongorestore进行逻辑迁移。使用此方案的优点是可以跨多个版本进行迁移升级,缺点是数据迁移速度慢。
二. 物理升级
由于Mongodb基本没有数据字典的概念,所以物理升级的优势就是速度快,影响业务时间短,但是有个明显的缺点就是无法跨多个大版本进行升级,Mongodb发行至今有2.6、3.2、3.4、3.6、4.0、4.2、4.4等大版本,比如说从3.2是不能直接升级到3.6的,必须先从3.2升级到3.4,再升级到3.6。

不管数据库是什么架构,若允许停库进行升级,则直接用新版本的软件,读取旧版本的数据库文件(–dbpath),重新启动即可。如果是复制集或者分片集群架构,则可利用复制集可以在线进行备机初始化的特性,进行滚动升级。滚动升级具有如下优势:

  • 用新版本软件新加从节点或者删除原有从节点进行重新初始化,然后主从切换,此方案对业务基本无影响,只有几秒钟的切换时间。
  • 滚动升级多了一层数据保护,若升级异常,可快速回退。避免了升级异常导致业务异常或者数据丢失等问题。

从低版本升级到3.4以上版本时,在升级完成后,需要修改数据库兼容性参数,低于3.4以下版本,则无需修改,方法如下:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) ;
db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } );
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) ;

 

对于分片集群来说,由于每一个片和config都是一个复制集,所以可以同样可以采用复制集滚动升级的方式实现,并且mongos也可以滚动替换,业务基本无感知。但对于分片集群的升级,有一下情况需要注意:

  1. 停止业务侧的元数据变更
  2. 禁止分片集群的balancer操作,及停止在不同的分片间移动chunk。

    sh.stopBalancer()

    sh.getBalancerState()

    升级完成后,启用分片balancer。sh.setBalancerState(true)

  3. 备份config数据库
  4. 修改兼容性参数只能从mongos上修改

另外升级过程中,需要注意以下问题:

  1. 如果由3.4升级到3.6 ,可能存在部分实例没有配置bind_ip参数,因为3.6以前版本默认监听所有IP,3.6及以后默认只监听127.0.0.1 需要修改监听IP

    bind_iP=localhost,IP

  2. 升级到3.6以后,PSA架构需要添加参数enableMajorityReadConcern=false

发表评论

登录后才能评论

评论列表(1条)

联系杨振
联系杨振
侵权联系 投诉举报
分享本页
返回顶部