跳到正文
数据库迁移与备份运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 5
个案例。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 20 期｜数据表truncate缓慢
- 专辑文件：
22.html，第 2 个案例
- 查看原文
- 现象：
业务侧反馈只有几百行的表在truncate时较慢。
- 处置过程：
业务在truncate表时反映较慢，但表数据量很小，核实表行数确实很少，但在truncate时较慢，等再次truncate时观察等待事件，发现IO类等待事件较高。；查找相关资料，可能盘存在坏块，或者初始值大。；核查原因1不可能，查表的ddl，表初始值很大。与业务沟通，业务也不清楚为啥这个表初始值这么大。
- 运维建议：
规范的DDL操作至关重要；在于表的初始设置；（如初始存储参数）
第 15
期｜反向增量，ob侧执行rename导致数据不同步
- 专辑文件：
27.html，第 4 个案例
- 查看原文
- 现象：
反向增量，ob侧执行rename导致数据不同步。
- 处置过程： 业务侧DDL；alter table
ras_hubei.zfzx_pay rename to；ras_hubei.zfzx_pay_bak;
- 运维建议：
动态更新白名单；在执行DDL操作如rename之前，确保动态更新白名单设置。可以考虑实现自动化脚本或工具，当捕捉到DDL操作前，自动将涉及的新表名加入白名单。；改进日志抽取策略
第 15
期｜资源超卖引起unit迁移
- 专辑文件：
27.html，第 9 个案例
- 查看原文
- 现象： 资源超卖引起unit迁移。
- 处置过程： resource_hard_limit =
110；变更租户资源规格。
- 运维建议：
设置阈值预警；当资源使用接近限制时自动通知管理员，以便及时采取行动。；使用更灵活的资源管理策略
第 8
期｜mongo服务组成集群异常处置
- 专辑文件：
34.html，第 4 个案例
- 查看原文
- 现象：
三台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 个案例
- 查看原文
- 现象：
某运营商账务中心业务调用出现超时，持续一段时间后又自动恢复。；通过pinpoint观察，发现整个调用链中某个服务调用缓慢，并有超时；；通过查看该服务的调用堆栈，发现是调用ctgcache超时，并在故障时段频发；