MongoDB 第五期 : 托管 MongoDB 操作指南

一、自动化部署工具介绍

1、业务入口

(1)MongoDB申请

①界面地址:http://bianque.webdev.com/mongo/mongoApply

②注意事项:

②注意事项:

  • 可在回执查询界面查询用户名、密码
  • 通过解析名字服务,取得MongoDB服务(多入口)的IP和PORT
  • 客户端版本不兼容2.X版本的,请升级MongoDB客户端至3.X以上
  • 账号密码验证,统一在“admin”库中认证 (3)MongoDB实时监控 ①界面地址:http://bianque.webdev.com/mongo/mongoApplyInfo

②注意事项:

  • 针对线上业务提供多维度监控,测试业务仅提供“容量历史”和“慢日志”的监控
  • "容量历史”监控精确到集合级别,可查询“库”—>“集合”的容量

2、运维入口

(1)MongoDB机器上架

① 界面地址:http://bianque.webdev.com/mongo/mongoApplyInfo

②数据表名:mongodev

③注意事项:

  • 上架机器时注意区分业务机(IP_1、IP_2)和备份机(IP_BACKUP)
  • 上架机器时,标记“是否独立部署”
  • 复用备份机时,必须确定其具有可用端口数 (2)MongoDB备份查看 ①界面地址:http://bianque.webdev.com/mongo/mongoApplyInfo ②数据表名:backup_stat ③注意事项:
  • 备份分为“全量备份”和“oplog备份”,按需提取文件
  • 备份文件存放地址、状态、时间等详细信息

二、MongoDB部署流程

1、服务类型

2、“1+1+1”模式业务接入

(1)概述

“1+1+1”模式业务,即业务采用全新(各机器上均未部署过MongoDB业务)三台机器(1台业务机、1台业务机、1台备份机)进行部署(独立/混合),在部署时需进行如下步骤:

(2)操作流程

①业务接入

  • 上架机器 扁鹊平台----> MongoDB---->机器上架
  • 选择部署集群 在200上执行mgstart命令:
  • 选择可用端口
  • 选择上线业务
  • 是否独立部署
  • 确定相关信息

②软件包部署

  • 软件包传输 在“1+1+1”模式下,三台机器均未部署过MongoDB,故软件包均需传输。
  • 软件包安装

③监控初始化

监控系统会部署到每台机器上,并完成初始化和自启动。

④集群初始化

  • 配置(mongod、config、mongos)
  • 启动(mongod、config、mongos)
  • 建立集群(主从副本配置、根据业务需求调整参数)
  • 管理授权(mongod和config的管理权限配置)

⑤用户授权

根据既定规则,生成用户名、密码,并且设置相关权限,提供给用户使用,并将其写入t_mongo_apply表中,用户可在回执中查看。

⑥备份初始化

  • 备份系统安装(仅备库) 在“备机”上安装备份系统,这样可以保障备份操作不用影响主库和从库的读写。
  • 完成信任关系建立

由于备份机制的规则约束,完成“1+1+1”模式业务上线后,必须完善“备机”与“冷备存储(104)”的信任关系建立,之后整个上线过程结束了。

3、“2+1”模式业务接入

(1)概述

“2+1”模式业务,即业务采用全新(各机器上均未部署过MongoDB业务)两台机器(业务机),以及复用一台大存储备份机(机器上部署过MongoDB业务的备份机)进行部署(独立/混合),在部署时需进行如下步骤:

(2)操作流程

①业务接入

  • 上架机器
  • 选择部署集群
  • 选择可用端口
  • 选择上线业务
  • 业务是否独立部署
  • 确定相关信息

②软件包部署

  • 软件包传输(仅业务机)

由于“2+1”模式的备份机属于多业务混用,已经部署过软件包,故无需重新传输。

  • 软件包安装(仅业务机)

由于“2+1”模式的备份机属于多业务混用,已经部署过软件包,故无需在重新安装。

③监控初始化

  • 由于“2+1”模式的备份机属于多业务混用,其上已经安装过监控系统,故无需安装。

④集群初始化

  • 配置
  • 启动
  • 建立主从
  • 管理授权

⑤用户授权

4、测试业务接入

(1)概述

测试业务,即给业务提供功能测试的MongoDB平台,将接入业务部署到托管平台所提供的MongoDB测试集群中(sz_test),进行混合部署,在部署时需进行如下步骤:

(2)操作流程

①查找测试集群

  • 在机器上架界面查看测试集群
  • 在脚本帮助界面查看sz_test的IP地址
  • 在数据库(10.240.64.138:4120中的mongodev表中查看“grp”字段) ②用户授权 在200机器中,使用脚本---myuser进行用户授权,帮助信息如下:

三、关于监控

1、结构说明

采集到的数据保存到10.240.64.138:4120里,采集间隔为一分钟,可在采集程序配置文件修改。采集通过连接mongodb,获取serverstatus,dbstats,colstat,rs.status等系统内置命令获取。每个机器上可能有多个mongodb实例,可在配置文件里配置相应的端口,每个实例启动一个线程采集数据。连接mongodb使用账号root:root, 需要在每台mongodb里添加认证,zabbix采集脚本里也需要配置,如果需要改动,需要更改zabbix自定义采集脚本和mongomon代码。

由于mongomon采集数据的时候依赖于ip,port,无法方便的与产品线关联,在mongodb配置的时候,会把标志每个产品的bid,配置成mongodb的setname里,获取数据的时候联同bid一起写入mysql,这样就实现了监控数据和产品的映射。

报警由zabbix触发,可在zabbix上配置监控策略,zabbix调用脚本进行告警。告警脚本调用微信的接口,接口文档可在http://alarm.weixin.oa.com/查看。

当zabbix触发报警时,会调用10.49.102.18目录/usr/local/zabbix/share/zabbix/alertscripts下,后续可根据zabbix发送的报警信息,去10.240.64.138:4120里查询业务信息,然后发送到微信群。

2、采集程序部署、配置

采集程序部署在/data1/opbin/mongomon

zabbix部署在/data1/opbin/zabbix

(1)Mongomon

启动采集程序使用目录里的脚本control

./control start 启动程序

./control status 查看运行状态

./control stop 停止程序

日志保存在mongomon/var目录下

(2)zabbix

①部署

每台需要监控的机器上都需要部署zabbix agent

zabbix部署在下面两台机器,agent需要在每台mongodb上部署

zabbix proxy 100.65.33.201

zabbix server 10.49.102.18

②报警

报警脚本在10.49.102.18机器的下面目录里

           /usr/local/zabbix/share/zabbix/alertscripts/tg_alarm.py

该脚本根据zabbix相关报警信息发送报警消息

③配置

zabbix agent配置文件在zabbix/etc目录

只需要修改hostname为本机ip即可

3、mongodb日报

日报程序在10.166.141.29的/data/aid.qq.com/qywx/scripts/mongodb_scripts目录下,由两个脚本构成:

  • create_mongodb_daily_data.py 生成按天统计数据
  • daily_report.py 发送日报

统计数据保存在10.240.64.138:4120上,每天0点1分生成前一天的按天统计数据,十点发送日报。

4、数据库表结构

(1)库地址 : 10.240.64.138:4120

(2)库名 : database: tg_data

(3)表结构:

①监控信息

create table mongomon (

        `Id` int(11) auto_increment primary key,              //自增ID

        `Bid` varchar(30) not null,                                   //bid

        `MongoIns` varchar(30) not null,                //mongodb实例,格式为IP:port

        `IsMaster` bool not null default false,              //是否是master

        `Insert` int(10) not null default 0,                            //insert操作的量

        `Query` int(10) not null default 0,                            //query操作的量

        `Update` int(10) not null default 0,                         //update操作的量

        `Delete` int(10) not null default 0,                           //delete操作的量

        `Getmore` int(10) not null default 0,                 //getmore操作的量

        `Command` int(10) not null default 0,           //command操作的量

        `NetIn` bigint not null default 0,                         //网络进流量

        `NetOut` bigint not null default 0,                           //网络出流量

        `NumRequests` int(10) not null default 0,       //请求量

        `ConnAvg` int(10) not null default 0,

        `ConnTotal` int(10) not null default 0,               //总连接数

        `ConnAvail` int(10) not null default 0,               //可用连接数

        `ConnCurr` int(10) not null default 0,                //当前连接数

        `MemResident` bigint not null default 0,         //物理内存使用量,Mb

        `MemVirtual` bigint not null default 0,

        `PageFaults` int(10) not null default 0,                   //页错误量

        `AssertsWarning` int(10) not null default 0,        

        `AssertsUser` int(10) not null default 0,

        `AssertsRollovers` int(10) not null default 0,

        `AssertsRegular` int(10) not null default 0,

        `AssertsMsg` int(10) not null default 0,

        `GLQueueRead` int(10) not null default 0,   //等待读锁的队列数

        `GLQueueWrite` int(10) not null default 0,  //等待写锁的队列数

        `GLQueueTotal` int(10) not null default 0,   //等待锁的队列总数

        `GLActiveConnRead` int(10) not null default 0,   //执行读操作的活动连接数

        `GLActiveConnWrite` int(10) not null default 0,  //执行写操作的活动连接数

        `GLActiveConnTotal` int(10) not null default 0,    //活动连接总数

        `Delay` int(10) not null default 0,                             //主从同步延时

        `Timestamp` datetime not null,

        indexbid_i (`Bid`),

        indexmongoins_i (`MongoIns`),

        indextimestamp_i (`Timestamp`),

        indexmongotime_i (`MongoIns`,`Timestamp`))

        ENGINE=InnoDB DEFAULT CHARSET=utf8;

②保存库信息数据

create table dbstat (

        `Id` int(11) auto_increment primary key,

        `Bid` varchar(30) not null,

        `MongoIns` varchar(30) not null,

        `Dbname` varchar(50) not null,                      //库名

        `Collections` int(10) not null default 0,                   //collection的量

        `Objects` bigint not null default 0,                           //document的量

        `AvgObjSize` int(10) not null default 0,                   //平均document大小

        `DataSize` bigint not null default 0,               //压缩前数据大小,kb

        `StorageSize` bigint not null default 0,                   //存储空间大小,kb

        `Indexes` int(10) not null default 0,                         //索引数量

        `IndexSize` bigint not null default 0,              //索引大小,kb

        `Slowlog` int(10) not null default 0,                         //慢日志条数

        `Timestamp` datetime not null,

        indexbid_i (`Bid`),

        indexmongoins_i (`MongoIns`),

        indextimestamp_i (`Timestamp`),

        indexmongotime_i (`MongoIns`,`Timestamp`))

        ENGINE=InnoDB DEFAULT CHARSET=utf8;

③保存collections信息数据

create table colstat (

        `Id` int(11) auto_increment primary key,

        `Bid` varchar(30) not null,

        `MongoIns` varchar(30) not null,

        `Dbname` varchar(50) not null,                      //库名

        `Colname` varchar(50) not null,                      //collection名

        `Count` bigint not null default 0,                    //document量

        `Size` bigint not null default 0,                        //总记录大小,kb

        `AvgObjSize` int(10) not null default 0,                   //平均单个记录大小

        `StorageSize` bigint not null default 0,                   //总存储空间,kb

        `Indexes` int(10) not null default 0,                         //索引数量

        `TotalIndexSize` bigint not null default 0,     //总索引大小,kb

        `Max` int(10) not null default 0,

        `Maxsize` int(10) not null default 0,

        `Timestamp` datetime not null,

        indexbid_i (`Bid`),

        indexmongoins_i (`MongoIns`),

        indextimestamp_i (`Timestamp`),

        indexmongotime_i (`MongoIns`,`Timestamp`))

        ENGINE=InnoDB DEFAULT CHARSET=utf8;

④保存存储容量日报信息数据

CREATE TABLE `mongo_datasize_daily` (

  `Id` int(11) NOT NULL AUTO_INCREMENT,

  `Bid` varchar(30) NOT NULL,

  `Db_num` int(10) NOT NULL DEFAULT '0',

  `Col_num` int(10) NOT NULL DEFAULT '0',

  `Obj_num` int(10) NOT NULL DEFAULT '0',

  `StorageSize` bigint(20) NOT NULL DEFAULT '0',

  `DataSize` bigint(20) NOT NULL DEFAULT '0',

  `Index_num` int(10) NOT NULL DEFAULT '0',

  `IndexSize` bigint(20) NOT NULL DEFAULT '0',

  `D_Date` date NOT NULL,

  PRIMARY KEY (`Id`),

  UNIQUE KEY `bid_date` (`Bid`,`D_Date`),

  KEY `bid_i` (`Bid`),

  KEY `d_date_i` (`D_Date`)

) ENGINE=InnoDB AUTO_INCREMENT=64 DEFAULT CHARSET=utf8

⑤保存访问量日报信息数据

CREATE TABLE `mongo_qps_daily` (

  `Id` int(11) NOT NULL AUTO_INCREMENT,

  `Bid` varchar(30) NOT NULL,

  `QpsWrite` int(10) NOT NULL DEFAULT '0',

  `QpsRead` int(10) NOT NULL DEFAULT '0',

  `QpsTotal` int(10) NOT NULL DEFAULT '0',

  `D_Date` date NOT NULL,

  PRIMARY KEY (`Id`),

  UNIQUE KEY `bid_date` (`Bid`,`D_Date`),

  KEY `bid_i` (`Bid`),

  KEY `d_date_i` (`D_Date`)

) ENGINE=InnoDB AUTO_INCREMENT=70 DEFAULT CHARSET=utf8

⑥保存bid,mongodb实例映射信息

CREATE TABLE `mongoins` (

  `Id` int(11) NOT NULL AUTO_INCREMENT,

  `bid` char(20) NOT NULL,

  `ip` char(20) NOT NULL,

  `port` int(11) NOT NULL,

  `name_server` char(80) NOT NULL,

  `grp` varchar(50) NOT NULL,

  `isbackup` tinyint(1) NOT NULL,

  PRIMARY KEY (`Id`),

  KEY `ipport` (`ip`,`port`),

  KEY `name_server` (`name_server`)

) ENGINE=InnoDB AUTO_INCREMENT=33 DEFAULT CHARSET=utf8

四、关于备份恢复

1、备份策略

每天1点备份全库,每小时备份一次oplog

2、备份实现

  • 使用mongodump备份,备份前锁库,备份完成后解锁
  • 备份oplog同样使用mongodump,指定查询条件,只备份一个小时的数据。
  • 备份脚本保存在 /data1/mongodb/backup
  • 备份数据备份在 /data1/mongodb/backup/data
  • 为了节省空间,备份完成后删除备份数据
  • 备份数据压缩后传输到10.62.19.104 /data/mongodb/backup目录下

目前备份会在两台Secondary上其中一台固定执行,这台机器一般需要使用磁盘容量较大的机器,这台机器优先级较低,不会被选成master。因为磁盘容量大,这台机器可多跑几个mongodb实例,但是不能影响复制延时。注意: 备份的机器需要跟10.62.19.104建立信任关系,方便传输备份文件到上面。

3、备份状态查询

备份数据相关信息写入mysql,10.240.64.138:4120, 在tg_data库,backup_stat表里。

表结构如下:

CREATE TABLE `backup_stat` (

`Id` int(11) NOT NULL AUTO_INCREMENT,

`Bid` varchar(30) NOT NULL,            #bid,也就是mongo的setname

`Filename` varchar(255) NOT NULL,      #文件名

`Size` varchar(50) NOT NULL,           #文件大小

`Type` varchar(50) NOT NULL,          #备份类型 all,全库备份,oplog

`Status` char(10) NOT NULL,           #状态  success, failure

`T_Timestamp` datetime NOT NULL,

PRIMARY KEY (`Id`),

KEY `bid_i` (`Bid`),

KEY `timestamp_i` (`T_Timestamp`),

KEY `bidtime_i` (`Bid`,`T_Timestamp`)

) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

4、恢复数据

(1)原则

数据恢复原则一般为:

①优先用冷备数据,冷备数据无法满足(备份失败、实时性差等)时,采用在从库down数据,并进行恢复

②误操作、分子操作回滚等优先使用oplog进行恢复

③为保证数据一致性,在进行down数据时,必须先进行锁表操作

④在集群机器替换和数据恢复前,需将机器remove出集群配置(在主上操作)

(2)常用恢复语句

①锁库、解锁

usedb

db.fsyncLock()

db.fsyncUnlock()

②状态命令

 rs.status();--查看状态

rs.slaveOk();--sencondary机器授权查询

 rs.isMaster();--查看副本集状态

③节点操作

           rs.remove("localhost:20001");--删除节点在主服务器执行

           rs.add("localhost:20001");--增加节点

       ④数据备份

    /data/mongodb/server/mongo/bin/mongodump --port 27019 --db omg --out /data/mongodb/shard23_27019/backup

④数据恢复

/data1/mongodb/m_server/bin/mongorestore -h 10.49.120.147 --port 25031  -u xxx -p

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

增量数据丢失的原因分析(三)(r8笔记第91天)

今天开发的同事找到我说,他们发现一个应用今天应该会同步过来一部分数据,但是今天却没有,所以想让我帮忙看看到底是怎么回事。 对于这类需求也算是轻门熟路,不光维护管...

3344
来自专栏智能大石头

每天4亿行SQLite订单大数据测试(源码)

SQLite作为嵌入式数据库的翘楚,广受欢迎! 新生命团队自2010年以来,投入大量精力对SQLite进行学习研究,成功应用于各系统非致命数据场合。

810
来自专栏PHP技术

不同场景下 MySQL 的迁移方案

原文出处: 温国兵(@dbarobin) 一 为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作。迁移,究其本义,无非是把实际存在的物体挪走,...

3925
来自专栏数据和云

ProxySQL!像C罗一样的强大!

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

1044
来自专栏PHP技术

MySQL初始配置调优

随着 大量默认选项的改进, MySQL 5.6比以前版本需要调优的选项大为减少。 在本文中我将讲述需要优化的配置项。   InnoDB设置   innodb_b...

4206
来自专栏乐沙弥的世界

Oracle 常见故障及日常规划

对任何数据库系统而言,对显而易见的故障,应当避免发生本文列出了Oracle常见的故障并给出了解决方案,同时列出了一些日常规划。

562
来自专栏数据和云

【12.2新特性】Oracle Sharding分片级别的高可用实现

编辑手记:Oracle Sharding是从12c推出的通过分区技术实现的一种数据库架构,在12.2中这项技术也越来越成熟。release 2中新特性包含:分片...

4047
来自专栏逸鹏说道

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁...

3218
来自专栏杨建荣的学习笔记

10g 一主多备的搭建技巧(r6笔记第13天)

在数据库环境中,一主一备是比较传统的使用方式,在灾难发生的时候,可以灵活的切换主备角色,依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤,一主...

2716
来自专栏Linyb极客之路

基于docker的微服务容器化与编排

在本人的微服务系列中,已经演示了各个spring cloud微服务组件的使用,以及相关的示例微服务应用。在每次启动微服务和对微服务进行扩容、缩容都不方便,本文使...

963

扫码关注云+社区