共计 5946 个字符，预计需要花费 15 分钟才能阅读完成。
随着监控助理忽然提醒很多数据库连贯谬误：
排查数据库谬误便随之提上了日程。
重启大法
不得不说，有时候重启大法还是挺好使的。所以咱们上来也尝试重启 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 status
mysql 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 # ls
keyring my.cnf my.cnf.sample而后咱们备份一个配置文件 cp my.cnf my.cnf.bak 后再对其进行编辑：
[mysqld]
log = /var/log/mysql/mysqld.log
log-error = /var/log/mysql/error.log
user = mysql
port = 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 completed
2022-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.html
2022-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 -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufsid/59a7effe7885633c 39G 36G 124M 100% /
devfs 1.0K 1.0K 0B 100% /dev
zroot/mengyunzhi 48G 40G 8.4G 82% /mengyunzhi
zroot 8.4G 23K 8.4G 0% /zroot首先咱们查看 my.cnf 中的数据库文件配置门路:
datadir = /var/db/mysql
tmpdir = /var/db/mysql_tmpdir
slave-load-tmpdir = /var/db/mysql_tmpdir
secure-file-priv = /var/db/mysql_secure而后顺次查看其占用空间：
root@YunzhiTest:/var/db # du -h -d 1
180M ./portsnap
3.1M ./etcupdate
8.0K ./zfsd
36K ./entropy
4.0K ./ipf
4.0K ./hyperv
87M ./pkg
688K ./ports
1.5G ./freebsd-update
12K ./ntp
148K ./fontconfig
8.0K ./sudo
18G ./mysql
4.0K ./mysql_secure
4.0K ./mysql_tmpdir
8.0K ./redis
8.0K ./colord
20G .发现 mysql 占用了 18G，但实际上并没有这么多数据。进入 mysql 文件夹后持续查看：
root@YunzhiTest:/var/db/mysql # du -ah | sort -h
104M ./log/log.ibd
105M ./log
130M ./mysql/slow_log.CSV
131M ./mysql-bin.000108
136M ./measurement/instrument.ibd
142M ./mysql-bin.000113
145M ./mysql-bin.000104
150M ./mysql
190M ./mysql-bin.000114
214M ./mysql-bin.000111
224M ./mysql-bin.000109
230M ./mysql-bin.000103
256M ./ib_logfile0
256M ./ib_logfile1
256M ./mysql-bin.000106
274M ./mysql-bin.000107
287M ./mysql-bin.000110
344M ./mysql-bin.000102
346M ./instrument
380M ./mysql-bin.000112
404M ./measurement/instrument_check_info_mandatory_instrument_check_ability_list.ibd
502M ./mysql-bin.000120
658M ./mysql-bin.000121
678M ./mysql-bin.000125
786M ./mysql-bin.000116
813M ./mysql-bin.000123
900M ./mysql-bin.000118
1.0G ./measurement
1.0G ./mysql-bin.000115
1.0G ./mysql-bin.000117
1.0G ./mysql-bin.000119
1.0G ./mysql-bin.000122
1.0G ./mysql-bin.000124
1.2G ./switchgear1
1.2G ./switchgear1/record_value.ibd
2.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.000115
root@YunzhiTest:/var/db/mysql # rm mysql-bin.000124
root@YunzhiTest:/var/db/mysql # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufsid/59a7effe7885633c 39G 34G 2.1G 94% /
devfs 1.0K 1.0K 0B 100% /dev
zroot/mengyunzhi 48G 40G 8.4G 82% /mengyunzhi
zroot 8.4G 23K 8.4G 0% /zroot将 bin 文件的保留天数据设置为 10：
binlog_cache_size = 16M
expire_logs_days = 10最初尝试启动 mysql
root@YunzhiTest:/usr/local/etc/mysql # /usr/local/etc/rc.d/mysql-server start
Starting mysql.
root@YunzhiTest:/usr/local/etc/mysql # /usr/local/etc/rc.d/mysql-server status
mysql is not running.其实除此办法外，如果你的第二硬盘空间够用，还能够间接把 mysql 的数据文件迁徙到第二块硬盘上，我只所以没有这么做是因为我第二块硬盘的残余空间也仅有 8.4G，而这个值小于以后 mysql 的占用空间 18G。所以即使是我想进行迁徙，也迁徙不过来。其根本原因是因为当下有个零碎须要上传大量的较大的文件，而我并没有应用 存储 来解决这些文件，是时候应用 存储 来专门寄存资源文件了。
追踪：尽管将 expire_logs_days 的值设置成了 10，但 mysql 在启动的时候并没有主动删除历史的日志，可能还须要在某个工夫节点上触发吧，待后续进行追踪。
