問題の起源：
早朝に突然、ディスクの残りが15未満であるというザビックスの警告が表示されたので、急いで何が起こっているかを確認してください。
調査プロセス
1. df -ahチェックして、/ dataディレクトリがすでに91％を占めていることを確認します
2. / dataの下のどのディレクトリが使用されているかを調べ、最後にmysql binlogによって占有されているディレクトリを見つけます。これは明らかにbinlogの書き込みが多すぎることが原因です。ps
、ここでのトラブルシューティングプロセスの図は、切り落とすのを忘れたため、使用できます。 du -ah -d 1特定のディレクトリ内のすべてのサブディレクトリの占有サイズを確認します-dは階層関係を表し、レベルごとに入力すると、使用するディレクトリを見つけることができます
3.binlogをrawモードからSTATEMENTモードに変更し始めます。
mysql> show global variables like "%binlog_format%";
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.01 sec)
mysql> SET global binlog_format='STATEMENT';
Query OK, 1 rows affected (0.00 sec)mysql構成を変更した後、binlogディレクトリに移動してもう一度確認すると、多数のbinlogがなくなり、ディスク使用量が通常に減少していることがわかります。
4.構成モードを変更することもできます
。mysqlのmy.cnfに移動し、対応する値を変更します。
# 1天过期清理binlog日志
expire_logs_days =1
# 修改记录模式为statement
binlog_format = statement
# 原因分析
mysql是默认开启binlog日志的并且对于已经存储的binlog日志没有设置自动清理时间，最蛋疼的是mysql在5.7.7版本之后默认binlog存储格式改为了ROW（也就是最详细最消耗磁盘的一种）刚好那几个磁盘飙升的应用恰好是有大量数据新增和删除的操作，所以会出现binlog日志50多G的情况
### binlog基本概念
binlog是Mysql sever层维护的一种二进制日志，与innodb引擎中的redo/undo log是完全不同的日志；其主要是用来记录对mysql数据更新或潜在发生更新的SQL语句，记录了所有的DDL和DML(除了数据查询语句)语句，并以事务的形式保存在磁盘中，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlogの3つのストレージモード
行
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条被修改。
缺点：row level，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，会产生大量的日志内容。ステートメント
优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能，因为它只需要在Master上锁执行的语句的细节，以及执行语句的上下文的信息。
缺点：由于只记录语句，所以，在statement level下 已经发现了有不少情况会造成MySQL的复制出现问题，主要是修改数据的时候使用了某些定的函数或者功能的时候会出现。混合
在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志格式，也就是在Statement和Row之间选择一种。如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。