记一次由于操作失误致使数据库瘫痪的故障分析与解决方案-Toy模板网

这篇具有很好参考价值的文章主要介绍了记一次由于操作失误致使数据库瘫痪的故障分析与解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

引言

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

系统简介

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

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

时间线

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

问题分析

时间索引

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

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

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

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

问题点

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

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

经验总结

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

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

总结

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

到了这里，关于记一次由于操作失误致使数据库瘫痪的故障分析与解决方案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！