引言

2023年8月27日,随着新业务的接入,我们开始进行项目的灰度发布。然而,直到2023年8月31日下午,我们才发现一个新字段并没有进行字段刷新,导致所有数据都是默认值,从而无法继续进行灰度测试。在业务方的要求下,我们需要进行批量更新字段。鉴于我们已经知道了时间范围,我们决定在白天进行批量更新数据。正是在这个过程中,故障发生了!

系统简介

该系统是一个服务群,其请求量主要集中在工作时间(9点-17点),大约有110万个请求。此外,系统还有各种定时任务和批处理任务。其中,涉及本次更新表的服务集群在工作时间其请求量约为90万个,这表明该服务是服务群中的核心请求服务。

然而,整个系统只有一个后台数据库,并且采用的是主从架构。遗憾的是,并没有实现读写分离。从库仅用作备份和应急数据库处理。

时间线

  1. 8月31日下午13点50分,运维人员根据时间点执行了查询语句,查询了即将要更新的数据量为200万行。其中,dateCol字段是一个独立的时间索引。
  2. 8月31日下午16点0分,运维人员使用数据库工具执行了更新单表数据的操作,并未查看执行计划。SQL语句如下:update table set newCol = oldCol where dateCol >= 时间点;
  3. 8月31日下午16点8分,在更新操作执行了8分钟后,运维人员意识到存在问题,点击了数据库工具上的取消按钮,想要终止更新操作。
  4. 8月31日下午16点16分,在取消操作成功之间的经过了8分钟,业务请求开始超时,整个数据库陷入瘫痪状态。尽管最后取消更新操作显示为成功,但数据库仍然无法正常运行。
  5. 8月31日下午16点30分,紧急关停了所有服务,开始切换数据库,并查看相关数据库执行日志。
  6. 8月31日下午17点,数据库切换工作完成,所有服务正常启动。通过查看执行日志,发现问题出在运维人员执行的更新语句上。而且执行计划显示该语句并未命中时间索引。

问题分析

时间索引

我们先来看下时间索引,时间索引是数据库中一种常见的索引类型,用于加速针对时间列的查询操作。它的特点包括:

  • 有序性:时间索引按照时间的顺序进行排序,使得查询根据时间范围进行过滤更加高效。
  • 快速定位:时间索引通过使用B树或B+树等数据结构,使得数据库可以快速定位到指定时间点或时间范围的数据。
  • 支持时间范围查询:时间索引可以用于查询满足特定时间范围的数据,如查询某一天、某一周或某一月的数据。
  • 支持时间序列分析:时间索引可以用于时间序列数据的分析与聚合操作,如计算某一时间段内的平均值、总和等。

然而,时间索引也存在失效的场景,包括但不限于:

  • 索引列数据分布不均匀:如果时间列的取值分布不均匀,例如某些时间段的数据较多,而其他时间段的数据较少,那么时间索引的效果可能会大打折扣,导致查询性能下降。
  • 大量更新操作:当有大量的数据更新操作(如插入、更新、删除)发生时,时间索引的维护成本较高,可能导致索引失效或性能下降。
  • 跨时间段查询:如果查询涉及到多个时间段的数据,时间索引可能无法有效利用,需要进行全表扫描,影响查询性能。

问题点

根据整个流程,我们可以思考一下存在哪些不当之处。我已经考虑了以下几个问题点:

  1. 执行时间不当:在正常的月末业务月结期间,数据库请求量非常大,批量数据的更新应该在晚上进行,而不是在下午这个关键时间点。这样可以避免对系统的正常运行造成干扰。
  2. 操作流程不当:按照公司规定,在执行更新语句之前,至少需要两个人同时查看,确保没有数据库问题才能进行执行。然而,在这次更新中只有一个人进行了操作,违反了公司的规定。这样的做法可能增加了潜在的风险。
  3. 缺乏执行计划:在执行更新操作之前,用户没有查看执行计划,无法得知时间索引是否已经失效了,该更新语句是否会导致全锁。缺乏对执行计划的了解可能会导致性能问题或者不必要的资源浪费。
  4. 缺乏限流机制:系统中缺乏引入限流工具,当数据库压力剧增时,大量请求同时访问数据库,这会增加数据库的负载压力。引入限流机制可以有效降低数据库的访问量,避免过载导致的性能问题。

经验总结

根据以上问题点,我总结了一下可以改进的建议:

  1. 确认数据库的更新时间:根据业务的风险级别,安排合适的批量更新操作时间。
  2. 优化更新操作:通过查看执行计划,针对性地优化更新语句,避免全锁的情况发生。并不是修改成分批更新就行了,可能在更新7月的数据还是可以命中时间索引的,但是在更新8月份的时候就失效了,所以只要条件发生变更就需要重新查看执行计划。
  3. 使用限流工具:在系统中引入限流工具,如Sentinel,对请求进行限流,避免大量请求同时访问数据库。可以设置合理的流量控制策略,防止数据库被过多的请求压力影响性能。
  4. 设置超时时间和重试机制:对业务请求设置合理的超时时间和重试机制,当请求超时时及时进行重试或返回错误信息,避免请求一直处于等待状态。可以通过配置合理的超时时间和实现自动重试机制,提高系统的稳定性和响应能力。
  5. 调整数据库参数:根据实际情况,调整数据库的参数,如连接池大小、最大连接数等,以提高数据库的性能和稳定性。
  6. 定期维护和优化数据库:定期进行数据库的维护和优化工作,如清理无用数据、重建索引等,以保持数据库的良好状态。可以定期进行数据清理和归档,优化数据表结构和索引,提升数据库的查询和更新效率,以保持数据库的良好状态。就比如我们这张表尽然存在着5年前的数据,而业务最多可能会涉及最近2年的数据量,对于长时间未使用的数据,可以将其迁移到另一张表或者进行冷热数据分离,以减少单张数据表的数据量。

总结

在这次操作不当导致数据库瘫痪的故障中,我们发现了几个问题点:执行时间不当、操作流程不当、缺乏执行计划和限流机制。针对这些问题,我们提出了改进建议:确认数据库更新时间、优化更新操作、使用限流工具、设置超时时间和重试机制、调整数据库参数以及定期维护和优化数据库。通过这次故障的经验分享,我们应该引以为戒,加强对操作的谨慎性和规范性,以确保系统的稳定运行。

09-10 09:23