nosql专栏

一、告警 二、日志输出 三、分析 主从复制的时候，复制的rdb文件超过buffer的限制导致。 四、处理 检查get set 检查

redis-cli -a "2ghlmvl_EC" -h 172.21.36.87 -p 6379 --bigkeys redis-cli -a "2ghlmvl_EC" -h 172.21.36.

一、背景 DBA标准redis是通过dmp管理平台实现部署交付与管理，但对超大容量的redis集群的管理dmp会出问题，所以就手工部署这类的超大容量的redis。 大数据部分会有一些非标的redis部

最终调整后 二、准备 redis规划 最终是5主5从的cluster 三、对标的redis集群 问题点： 对标集群中，5主5从，有几个分片的maxmemory 配置的是192G，其他是250G 四、部

一、背景 非标redis水平扩容后，槽位平衡 变更背景： 推荐中台 新发展机房redis组件扩容 变更环境： y4 影响范围： xxx 变更类型： 黑屏操作 涉及SID： xx 涉及系统等级： A级

一、背景与目的 经过压测后业务怀疑DBA交付的redis性能不及开发自己部署的redis，所以组织本次压测。 目的： 验证两套redis之间的性能差距。 验证redis白皮书中关于性能的指标 二、准备

一、背景 非标redis水平扩容后，旧分片的数据迁移与旧分片下线。 变更背景： 推荐中台 新发展机房redis组件扩容 变更环境： y4 影响范围： 推荐中台PH场景 变更类型： 黑屏操作 涉及SID

一、摘要 对redis服务本身进行压测，配置一个节点。如果是分片集群，将每个master节点同时压测。 二、部署 随着redis server 的安装自带上了。 三、参数 参数 说明 -h 连接的主机

测试与验证HA模式数据全量迁移到分片集群， 工具： redisShake4.3.1 二、准备 原集群 目的集群 工具 三、全量数据同步源 原集群数据量检查 redisShake配置文件调整shake.

平时工作中的笔记整理，废话不多说。兄弟们，直接上干货 一、背景 二、准备 mongo集群信息 http://172.20.171.9:8090/pages/viewpage.action?pageId

版本控制：（C、A、M、D：创建、增加、修订、删除） 版本号 变更日志 变更类型（C/A/M/D） 修改人 摘要 备注 1.0 2024-12-19 C xxx 一、思路 使用mongodump 工具

一、简介 mongoexport 工具可以连接从节点，在从节点上导出表数据，输出格式以CSV。 二、操作 三、参数说明

mongo的repSet转换为standalone 一、概述 wg mongo 在2022.08.15 晚10点secondary节点需要停机维护宿主机，导致需要停机。同时cpos mongo的服务不

一、集群信息 略 二、清理策略 清理的collection信息 三、操作 连接mongo主节点 切换menu 确认需要删除的collection大小 删除 再次确认是否删除完成 说明： 显示NaN 表

1、Mongo 1、巡检工具 mongodb巡检时主要采用了两种方式：grafana 2、流程 集群状态：选择相应的集群信息，选中后查看其运行节点数，查看集群状态是否存在异常 磁盘信息：在该页面中查看

背景 Mongodb 4.4+版本后，mongo的日志变成了json格式，由于之前日志分析一直使用的是mtools, mtools不支持json格式的日志，需要调研新的分析工具，推荐使用方案3 解决方

一、准备 确定mongo版本 本次使用cpos的一次操作作为展示用例 工具：mongodump 和 mongorestore 在DBA跳板机上有，直接使用即可。 DBA跳板机：172.25.243.9

rpm包 对mongo exporter 的版本没太大要求 二、步骤 1、创建monitor 账号 2、 rpm 方式安装exporter 3、开机启动 systemctl enable mongod

一、说明 配合安全团队，对每个DBA接管的数据库，提前埋入安全扫描账号。 二、操作 找到primary节点 在 confluence中找到DBA接管的mongo信息。 http://172.20.17

一、背景 es节点CPU在高峰时间段使用率超过80%，业务担心支撑不了活动，申请水平扩容data节点。 KSA和WGA两套cpos es都要做水平扩容。 二、集群信息 带xpack的es 7.10.2