线上事故记录
文章目录
一、数据库宕机
-
事故时间:2020-08-25
-
事故描述:
- 大量慢查询
- 阿里云数据库RDS,一主三从一备胎主库(共 5 个数据库),主从读写分离失效,大量请求涌入主库,主库承受不住请求压力,主库宕机,备胎主库也失效。
- 主从延迟严重,从库失效,全部查询堆在主库,这样也会导致主库宕机。(比如删除大量数据、更新大量数据的时候)
-
事故错误日志:
1 2 3 4 5 6 7
handleSQLSTATE[HY000] [2812] Connect Failed For Mysql Server No Response fields.index The MySQL server is running with the --read-only option so it cannot execute this statement handleSQLSTATE[HY000] [2831] Failed For Wait Mysql Server Handshake, please check the health of db input.type:log fields.index:xxx-laravel 从库同步主库时,出现主键冲突的 bug
-
事故可能原因分析
- mysql5.7主从同步存在bug:会出现主键冲突异常情况
- 阿里云数据库 RDS 从库失效,一个主库扛不住压力,直接宕机
- 业务系统本身上存在大量慢查询,占用了数据库大量连接数
-
事故解决方案:
- 减少请求量
- 在阿里云提工单,让他们解决失效从库失效和备胎主库问题。
- 避免在系统使用高峰期,大量增删改数据。
- 优化慢 SQL
-
为什么备胎主库和 3 个从库会失效呢?
阿里售后回复:
二、数据库堆积
-
事故描述:数据库 SQL 堆积,往往来自接口请求的堆积,接口请求的堆积, 往往是因为短时间内的请求处理速度慢。
-
解决方案
- 减少数据库慢查询
- 增加缓存代码
- 提高服务器配置
三、mysql连接数暴增,服务器cpu爆满
纠其原因,Golang作为常驻进程,请求第三方服务或者资源完毕后,需要手动关闭连接,否则连接会一直存在。而很多时候,开发者不一定记得关闭这个连接。
|
|
四、object too large for cache
内存空间和数据量大小:
- MemCached可以修改最大内存,采用LRU算法。Redis增加了VM的特性,突破了物理内存的限制。
- Memcached单个key-value大小有限,一个value最大只支持1MB,而Redis最大支持512MB。
五、go源码构建失败却以为构建成功
多服务项目,某个服务代码报错,导致其他服务构建失败,但我们却未看发版结果,误以为构建成功,
然后发现发版后有一些报错,却一直找不出问题!
修改历史代码后,要全局搜索下该方法影响到哪些服务,一定要注意多个服务都要能正常编译运行。
六、服务器接口响应慢
- 事故时间:2022-02-15,持续时长:约 10 分钟
- 事故描述:服务器接口响应慢,大部分接口的响应时间约 35 秒
- 报错日志:dial tcp xxx.x.x.x:11211: connect: connection refused
- 事故原因:运维重启了 memcached 服务,其对外 IP 变更了, 我们的 logic 服务使用了长连接 memcached 服务, logic 服务的 memcached 库没有重试机制,故还是连着 memcached 服务的旧 IP,导致很多用到 memcached 的接口响应慢
- 解决方案:重启所有连接 memcached 的所有 logic 服务,同时可考虑加上 memcached 服务的重试机制。
七、数据库从库同步延迟严重
- 事故时间:2022-03-15
- 事故描述:数据库从库同步延迟,用户在界面变更了数据,但后端接口却返回了旧数据,让用户误以为变更失败。
- 事故原因:OA数据库50G的大表结构变更,导致所有同步该大表的项目都出现从库延迟严重的情况。
- 解决方案:(1) 暂时放弃从库,直连主库;(2) 清缓存,避免缓存从库的旧数据。