随着监控助理忽然提醒很多数据库连贯谬误:

排查数据库谬误便随之提上了日程。

重启大法

不得不说,有时候重启大法还是挺好使的。所以咱们上来也尝试重启mysql

$ /usr/local/etc/rc.d/mysql-server stop$ /usr/local/etc/rc.d/mysql-server start

再次连贯,数据数据间接就连不上了。此时便须要来到正确的轨迹上:看报错内容,依据报错内容来排查起因,解决问题。

谬误日志

很遗憾的是,mysql在启动过程中,即便启动失败,也不会报什么的错误信息。咱们查看mysql是否胜利启动则须要应用mysql-server status命令:

root@YunzhiTest:/usr/home/panjie # /usr/local/etc/rc.d/mysql-server statusmysql is not running.

而是否打印日志,以及日志的地位放在哪,则须要咱们进行手动配置。在mysql服务胜利启动的前提下,咱们其实是能够应用mysql的相干命令来查看以后的配置文件地位的,无奈以后mysql并没有胜利启动,所以此时则须要借助一些查问软件或是当初装置mysql应用的工具(比方FreeBSD的ports)来查找mysql的配置文件地位了。在FreeBSD中,mysql的配置文件位于/usr/local/etc/mysql中:

root@YunzhiTest:/usr/home/panjie # cd /usr/local/etc/mysql/root@YunzhiTest:/usr/local/etc/mysql # lskeyring        my.cnf        my.cnf.sample

而后咱们备份一个配置文件cp my.cnf my.cnf.bak后再对其进行编辑:

[mysqld]log                             = /var/log/mysql/mysqld.loglog-error                       = /var/log/mysql/error.loguser                            = mysqlport                            = 3306

在 mysqld 下减少两项:log及log-error,别离存个别日志及谬误日志。同时因为以后mysql启动的用户是mysql,还须要保障mysql用户对相干日志门路领有相对权限:

$ mdkir /usr/log/mysql$ chown mysql:mysql /usr/log/mysql

查看日志

此时咱们再次启动mysql 服务,则能够查看在/var/log/mysql/下生成的error.log文件了:

$ /usr/local/etc/rc.d/mysql-server start

其比拟重要的错误信息如下:

2022-07-11T14:22:25.946391Z 0 [Note] InnoDB: Rollback of non-prepared transactions completed2022-07-11T14:22:25.946435Z 0 [Note] InnoDB: Setting file '/var/db/mysql/ibtmp1' size to 128 MB. Physically writing the file full; Please wait ...2022-07-11T14:22:25.947132Z 0 [Note] InnoDB: Progress in MB: 1002022-07-11T14:22:26.085805Z 0 [Warning] InnoDB: Retry attempts for writing partial data failed.2022-07-11T14:22:26.085855Z 0 [ERROR] InnoDB: Write to file /var/db/mysql/ibtmp1failed at offset 133169152, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.2022-07-11T14:22:26.085940Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'2022-07-11T14:22:26.085951Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html2022-07-11T14:22:26.085968Z 0 [ERROR] InnoDB: Could not set the file size of '/var/db/mysql/ibtmp1'. Probably out of disk space

上述谬误大略就是在说一个问题:磁盘空间满了,此问题导致mysql无奈启动。

整顿数据

问题的根本原因找到了,解决问题便成了最轻松的事件。

root@YunzhiTest:/usr/local/etc/mysql # df -hFilesystem                     Size    Used   Avail Capacity  Mounted on/dev/ufsid/59a7effe7885633c     39G     36G    124M   100%    /devfs                          1.0K    1.0K      0B   100%    /devzroot/mengyunzhi                48G     40G    8.4G    82%    /mengyunzhizroot                          8.4G     23K    8.4G     0%    /zroot

首先咱们查看my.cnf中的数据库文件配置门路:

datadir                         = /var/db/mysqltmpdir                          = /var/db/mysql_tmpdirslave-load-tmpdir               = /var/db/mysql_tmpdirsecure-file-priv                = /var/db/mysql_secure

而后顺次查看其占用空间:

root@YunzhiTest:/var/db # du -h -d 1180M    ./portsnap3.1M    ./etcupdate8.0K    ./zfsd 36K    ./entropy4.0K    ./ipf4.0K    ./hyperv 87M    ./pkg688K    ./ports1.5G    ./freebsd-update 12K    ./ntp148K    ./fontconfig8.0K    ./sudo 18G    ./mysql4.0K    ./mysql_secure4.0K    ./mysql_tmpdir8.0K    ./redis8.0K    ./colord 20G    .

发现mysql占用了18G,但实际上并没有这么多数据。进入mysql文件夹后持续查看:

root@YunzhiTest:/var/db/mysql # du -ah | sort -h104M    ./log/log.ibd105M    ./log130M    ./mysql/slow_log.CSV131M    ./mysql-bin.000108136M    ./measurement/instrument.ibd142M    ./mysql-bin.000113145M    ./mysql-bin.000104150M    ./mysql190M    ./mysql-bin.000114214M    ./mysql-bin.000111224M    ./mysql-bin.000109230M    ./mysql-bin.000103256M    ./ib_logfile0256M    ./ib_logfile1256M    ./mysql-bin.000106274M    ./mysql-bin.000107287M    ./mysql-bin.000110344M    ./mysql-bin.000102346M    ./instrument380M    ./mysql-bin.000112404M    ./measurement/instrument_check_info_mandatory_instrument_check_ability_list.ibd502M    ./mysql-bin.000120658M    ./mysql-bin.000121678M    ./mysql-bin.000125786M    ./mysql-bin.000116813M    ./mysql-bin.000123900M    ./mysql-bin.0001181.0G    ./measurement1.0G    ./mysql-bin.0001151.0G    ./mysql-bin.0001171.0G    ./mysql-bin.0001191.0G    ./mysql-bin.0001221.0G    ./mysql-bin.0001241.2G    ./switchgear11.2G    ./switchgear1/record_value.ibd2.3G    ./ibdata1

最终发现空间小户如上,咱们发现零碎中的.mysql-bin文件占据了较大的空间,而mysql-bin文件大体有两个作用:1是用来进行数据恢复;2是在主从数据库的时保障高可用性。

尽管能够删除相应的mysql-bin文件,然而保留该文档还是有肯定的必要性的。但咱们能够将其保留的日期缩短一些,比方咱们只保留一周的。查看文件的生成日期:

root@YunzhiTest:/var/db/mysql # ls -alh-rw-r-----   1 mysql  mysql   344M Jun 13 17:02 mysql-bin.000102-rw-r-----   1 mysql  mysql   229M Jun 14 13:53 mysql-bin.000103-rw-r-----   1 mysql  mysql   145M Jun 14 20:44 mysql-bin.000104-rw-r-----   1 mysql  mysql    56M Jun 15 00:11 mysql-bin.000105-rw-r-----   1 mysql  mysql   256M Jun 15 22:34 mysql-bin.000106-rw-r-----   1 mysql  mysql   274M Jun 16 11:29 mysql-bin.000107-rw-r-----   1 mysql  mysql   131M Jun 16 17:38 mysql-bin.000108-rw-r-----   1 mysql  mysql   224M Jun 17 04:00 mysql-bin.000109-rw-r-----   1 mysql  mysql   287M Jun 17 17:26 mysql-bin.000110-rw-r-----   1 mysql  mysql   214M Jun 18 03:29 mysql-bin.000111-rw-r-----   1 mysql  mysql   380M Jun 18 21:19 mysql-bin.000112-rw-r-----   1 mysql  mysql   142M Jun 20 17:02 mysql-bin.000113-rw-r-----   1 mysql  mysql   189M Jun 21 00:09 mysql-bin.000114-rw-r-----   1 mysql  mysql   1.0G Jun 22 19:35 mysql-bin.000115-rw-r-----   1 mysql  mysql   785M Jun 24 00:16 mysql-bin.000116-rw-r-----   1 mysql  mysql   1.0G Jun 25 19:06 mysql-bin.000117-rw-r-----   1 mysql  mysql   900M Jun 27 08:14 mysql-bin.000118-rw-r-----   1 mysql  mysql   1.0G Jun 29 11:30 mysql-bin.000119-rw-r-----   1 mysql  mysql   502M Jul  1 13:09 mysql-bin.000120-rw-r-----   1 mysql  mysql   657M Jul  5 01:38 mysql-bin.000121-rw-r-----   1 mysql  mysql   1.0G Jul  6 21:05 mysql-bin.000122-rw-r-----   1 mysql  mysql   813M Jul  8 09:05 mysql-bin.000123-rw-r-----   1 mysql  mysql   1.0G Jul 10 10:36 mysql-bin.000124-rw-r-----   1 mysql  mysql   677M Jul 11 21:28 mysql-bin.000125

发现该文件以后保留了近1个月,此时咱们先删除两个稍大的历史文件,把空间开释一些进去,而后再去批改一下my.cnf中的保留日期将其缩短为10天。

root@YunzhiTest:/var/db/mysql # rm mysql-bin.000115root@YunzhiTest:/var/db/mysql # rm mysql-bin.000124root@YunzhiTest:/var/db/mysql # df -hFilesystem                     Size    Used   Avail Capacity  Mounted on/dev/ufsid/59a7effe7885633c     39G     34G    2.1G    94%    /devfs                          1.0K    1.0K      0B   100%    /devzroot/mengyunzhi                48G     40G    8.4G    82%    /mengyunzhizroot                          8.4G     23K    8.4G     0%    /zroot

将bin文件的保留天数据设置为10:

binlog_cache_size               = 16Mexpire_logs_days                = 10

最初尝试启动mysql

root@YunzhiTest:/usr/local/etc/mysql # /usr/local/etc/rc.d/mysql-server startStarting mysql.root@YunzhiTest:/usr/local/etc/mysql # /usr/local/etc/rc.d/mysql-server statusmysql is not running.

其实除此办法外,如果你的第二硬盘空间够用,还能够间接把mysql的数据文件迁徙到第二块硬盘上,我只所以没有这么做是因为我第二块硬盘的残余空间也仅有8.4G,而这个值小于以后mysql的占用空间18G。所以即使是我想进行迁徙,也迁徙不过来。其根本原因是因为当下有个零碎须要上传大量的较大的文件,而我并没有应用存储来解决这些文件,是时候应用存储来专门寄存资源文件了。

追踪:尽管将expire_logs_days的值设置成了10,但mysql在启动的时候并没有主动删除历史的日志,可能还须要在某个工夫节点上触发吧,待后续进行追踪。