# 数据库迁移与备份运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **5 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 20 期｜数据表truncate缓慢](#case-1)
- [第 15 期｜反向增量，ob侧执行rename导致数据不同步](#case-2)
- [第 15 期｜资源超卖引起unit迁移](#case-3)
- [第 8 期｜mongo服务组成集群异常处置](#case-4)
- [第 3 期｜CTGCACHE异常处置](#case-5)
## 第 20 期｜数据表truncate缓慢
- 专辑文件：`22.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** 业务侧反馈只有几百行的表在truncate时较慢。
- **处置过程：** 业务在truncate表时反映较慢，但表数据量很小，核实表行数确实很少，但在truncate时较慢，等再次truncate时观察等待事件，发现IO类等待事件较高。；查找相关资料，可能盘存在坏块，或者初始值大。；核查原因1不可能，查表的ddl，表初始值很大。与业务沟通，业务也不清楚为啥这个表初始值这么大。
- **运维建议：** 规范的DDL操作至关重要；在于表的初始设置；（如初始存储参数）
## 第 15 期｜反向增量，ob侧执行rename导致数据不同步
- 专辑文件：`27.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** 反向增量，ob侧执行rename导致数据不同步。
- **处置过程：** 业务侧DDL；alter table ras_hubei.zfzx_pay rename to；ras_hubei.zfzx_pay_bak;
- **运维建议：** 动态更新白名单；在执行DDL操作如rename之前，确保动态更新白名单设置。可以考虑实现自动化脚本或工具，当捕捉到DDL操作前，自动将涉及的新表名加入白名单。；改进日志抽取策略
## 第 15 期｜资源超卖引起unit迁移
- 专辑文件：`27.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** 资源超卖引起unit迁移。
- **处置过程：** resource_hard_limit = 110；变更租户资源规格。
- **运维建议：** 设置阈值预警；当资源使用接近限制时自动通知管理员，以便及时采取行动。；使用更灵活的资源管理策略
## 第 8 期｜mongo服务组成集群异常处置
- 专辑文件：`34.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** 三台mongo服务组成集群模式，其中1台CPU告警，发现仅cpu的us值负载高，其他值都很低，通过监控发现，高峰期比较规律，一般为每小时的前20分钟，之后峰值就自动下去恢复到正常状态，期间执行任何命令都很流畅。
- **排查与原因：** 通过排查分析应该与mongo的计划任务有关。
- **处置过程：** 使用top和atop命令查看全部CPU使用情况，显示cpu的us值都有好几个cpu的us值100%，sy值却很低。进程依然看不到高负载。；使用pidstat命令：pidstat ｜grep -E “PID｜mongo”，发现mongo进程的是us使用率很高。；登录同集群的其他主机，执行相同的命令进行对比。
- **运维建议：** 收集和分析CPU、内存信息，比较不同时间段的数据，寻找规律，业务组调整计划任务时间、优化语句或扩容。
## 第 3 期｜CTGCACHE异常处置
- 专辑文件：`39.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** 某运营商账务中心业务调用出现超时，持续一段时间后又自动恢复。；通过pinpoint观察，发现整个调用链中某个服务调用缓慢，并有超时；；通过查看该服务的调用堆栈，发现是调用ctgcache超时，并在故障时段频发；