沈阳这大风，也没阻挡我去公司处理生产数据库问题~

Posted 2020-09-17

一、描述

今日发现企业扣扣各种CPU、磁盘IO过载报警，可怜的是刚搬家还没有办理宽带，只能背着最亲密的搭档来到公司，到公司都1点半了，沈阳这大风刮的，完全不在状态，还好有大连的同事一起来搞。

二、过程

1. 检查数据库，远程登录主机，查看性能glances,查看报警、慢查询日志等，登录数据库查看线程，这些步骤必须要走。

   
   

2.  中途接了一个北京的电话，百信银行，669，坐标北京，问我去不去，一脸蒙圈的告诉他我是沈阳的，电话挂后接着搞，心情很不爽。

3. 上百个binlog同步的用户连接，很不正常，让同事把相关服务停掉后，还有三十多个并发插入，一直在写，问题是真写不进去，IO等待超级高，敲个命令都很卡好不好，突然，从客户端自动跳出来了。看了一下日志，数据库自动重启了，在自动恢复中~ 等了半天还是没有起来，实在是没耐心了，直接kill掉也不好使，直接kill -9 (务模仿，需要有耐心)。

4.由于一些原因，业务不能关闭，那只好把数据库端口给修改了，配置文件/etc/my.cnf 。谁也别来打扰我，数据库起来后，自己来慢慢搞。谁也登陆不上来了哈哈，因为不知道端口，必须连不进来了。

5.有两个几十G的大表，还没有分区，有慢查询，问题是日志表，数据是可以清除的，正常情况下，我们都会创建分区表。也不知道为啥当时没有分区，原因就不说了。开始编写脚本，思路就是要重命名表，然后创建两个分区表，把数据库端口给改回来，让应用再连接进来就好了。最后还是要把数据库灌回到新创建的两个分区表中。

6.为啥今天会出现超级多的并发写入我还得观察观察，最近有点对它照顾不周啊，得自我批评一下。好久没出现什么故障了，也快到时候了。

三、遇到的问题

1.分区是timestamp类型，折腾了半天，官网查了发现需要使用UNIX_TIMESTAMP函数,不然会报错，以前创建的分区表字段大部分都是datetime,这里需要记录一下。

2.数据为啥能灌回去，没有丢失数据，因为我们的主键是UUID，不然要考虑会不会主键冲突。

3.后续又把一些当年的bak_开头的表删除了，分区又清理了一下，然后记录下这个问题，准备回家了。

不管做什么，大家都要有职业精神，我们就是要7*24随叫随到。即使不是自己公司的数据库，该出手也要出手哈哈~欢迎大家一起来学习、交流Oracle MySQL Hbase 数据库哈

本文出自 “roidba” 博客，请务必保留此出处http://roidba.blog.51cto.com/12318731/1922726