文章简介 工作这几年,技术栈在不断更新,项目管理心得也增加了不少,写代码的速度也在提升,感觉很欣慰,毕竟是在一直进步,但是过程中也有许许多多的曲折,也踩过了数不尽的坑坑洼洼,从一个连百度都不知道用的萌新到一个悠哉悠哉的老油子也不容易,很多人应该都有类似的经历和感受,因此博客中也会整理一些曾经碰到过的事故和问题给自己提个醒. 由于接下来要在perfect-ssm项目中引入缓存模块,恰好在翻看日记时看到了这次事故的记录,因此整理了这篇文章,根据事件发生时的日记来回顾一下这次事件,通过这次数据库事故的…

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载. 文章简介 工作这几年,技术栈在不断更新,项目管理心得也增加了不少,写代码的速度也在提升,感觉很欣慰,毕竟是在一直进步,但是过程中也有许许多多的曲折,也踩过了数不尽的坑坑洼洼,从一个连百度都不知道用的萌新到一个悠哉悠哉的老油子也不容易,很多人应该都有类似的经历和感受,因此博客中也会整理一些曾经碰到过的事故和问题给自己提个醒. 由于接下来要在perfect-ssm项目中…

前文提要 承接前文<一次线上Mysql数据库崩溃事故的记录>,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑. 由于时间原因,其中只讲了当时的一些经过以及我当时的一些心理活动,至于原因和后续处理步骤并没有在文章中很清晰的写出来,以致于很多朋友说看得不清不楚的,这里向他们道个歉,主要是上周真的没有足够的时间将两篇文章同时准备好,不然也不会草草结尾了,而且上篇文章中主观因素占了较大的比重,因为回忆起这件事的时候确实有很多想法,因此显得有些个人化.日记化了.…

前文提要 承接前文<一次线上Mysql数据库崩溃事故的记录>,在文章中讲到了一次线上数据库崩溃的事件记录,建议两篇文章结合在一起看,不至于摸不着头脑. 由于时间原因,其中只讲了当时的一些经过以及我当时的一些心理活动,至于原因和后续处理步骤并没有在文章中很清晰的写出来,以致于很多朋友说看得不清不楚的,这里向他们道个歉,主要是上周真的没有足够的时间将两篇文章同时准备好,不然也不会草草结尾了,而且上篇文章中主观因素占了较大的比重,因为回忆起这件事的时候确实有很多想法,因此显得有些个人化.日记化了.…

        最近线上项目报了一个MySQL死锁(DealLock)错误,虽说对业务上是没有什么影响的,由于自己对数据库锁这块了解不是很多,之前也没怎么的在线上碰到过.这次刚好遇到了,便在此记录一下.   出现死锁问题背景         项目层面:报错的项目做的是一个批量下单的动作,会同时写入多条订单数据,代码之前写的是一个事务中一个循环一条一条insert到数据库(至于为啥没用批量插入就不追究了,历史原因了).         数据库层面:一张test表(非线上真实表),比较重要的是有一个…

前言 生产环境的数据库往往需要经过严格的安全限制,所以禁用密码登录,使用秘钥的方式是一种相对安全的登录方式. 原理: 角色: 主机A:其他主机,有访问线上数据库的权限 主机B:线上数据库的主机 主机C:本机电脑,无访问线上数据库的权限 在本机C上(无访问B的权限),通过ssh配置的主机A(有访问B的权限),访问Navicat常规配置的主机B,即以A的身份连接使用B. 前期准备 生成ssh密钥对.可参考前期博文:快速通道 Navicat配置登录 1.连接的主机配置,如果连接的是线上数据库,就用线上…

从发现问题,到最后解决一共消耗两个半小时(7:30~10:00),报警电话16通,警察坐镇,未完待续 ......…

背景 前段时间收到运维反馈,线上Mysql数据库凌晨时候出现慢查询的报警,并把原始sql发了过来: --去除了业务含义的sql update test_user set a=1 where id=1; 表数据量200W左右,不是很大,而且是根据主键更新. 问题排查 排查Mysql数据库 我看到sql后第一反应就是是不是数据库出问题了,每个小时都有业务,偏偏白天业务高峰时间段正常,凌晨业务量很少时候出问题,让运维先检查了数据库的状态,反馈是数据库正常. 排查业务代码(第一次) 这块业务代码比较复杂…

起因: 线上 user 数据库没有自增字段,数据量已经达到百万级.无论是给离线仓库还是数据分析同步数据,没有主键自增 id 都是杀手级的困难.所以在使用 create_time 痛苦了几次之后准备彻底来解决这个问题. 解决问题的思路: 当时理了两个思路,一个是直接找个夜生人静的夜晚,drop 掉目前的 primary key .然后再 add 一个 id 字段做 primary key auto increament .我觉得这个方法对于 100w 以下的数据表是一个不错的方法,首先简单,其次找…

前言 在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法. 生产环境架构图 目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务.在发生故障时,切换到slave上,并将其变成master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错.下面是我收录下来的报错信息. 常见错误 最常见的3种情…