突然间，大量的binlog文件

Question

在Percona XtraDB集群的所有三个节点中，我都看到了大量的二进制日志文件的突然增加：

-rw-rw----  1 mysql mysql 1,1G 19 oct.  16:11 binlog-32.000001
-rw-rw----  1 mysql mysql 1,1G 19 oct.  16:36 binlog-32.000002
-rw-rw----  1 mysql mysql 1,1G 19 oct.  16:48 binlog-32.000003
-rw-rw----  1 mysql mysql 1,1G 19 oct.  16:59 binlog-32.000004
-rw-rw----  1 mysql mysql 1,1G 19 oct.  17:08 binlog-32.000005
-rw-rw----  1 mysql mysql 1,1G 19 oct.  17:26 binlog-32.000006
-rw-rw----  1 mysql mysql 1,1G 19 oct.  17:38 binlog-32.000007
-rw-rw----  1 mysql mysql 1,1G 19 oct.  17:47 binlog-32.000008
-rw-rw----  1 mysql mysql 1,1G 19 oct.  17:59 binlog-32.000009
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:10 binlog-32.000010
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:20 binlog-32.000011
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:29 binlog-32.000012
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:37 binlog-32.000013
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:45 binlog-32.000014
-rw-rw----  1 mysql mysql 1,1G 19 oct.  18:53 binlog-32.000015
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:01 binlog-32.000016
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:11 binlog-32.000017
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:19 binlog-32.000018
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:28 binlog-32.000019
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:38 binlog-32.000020
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:44 binlog-32.000021
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:52 binlog-32.000022
-rw-rw----  1 mysql mysql 1,1G 19 oct.  19:59 binlog-32.000023
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:08 binlog-32.000024
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:17 binlog-32.000025
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:24 binlog-32.000026
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:32 binlog-32.000027
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:40 binlog-32.000028
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:47 binlog-32.000029
-rw-rw----  1 mysql mysql 1,1G 19 oct.  20:56 binlog-32.000030
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:05 binlog-32.000031
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:15 binlog-32.000032
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:25 binlog-32.000033
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:36 binlog-32.000034
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:46 binlog-32.000035
-rw-rw----  1 mysql mysql 1,1G 19 oct.  21:48 binlog-32.000036
-rw-rw----  1 mysql mysql 254M 20 oct.  09:34 binlog-32.000037
-rw-rw----  1 mysql mysql  143 20 oct.  09:34 binlog-32.000038
-rw-rw----  1 mysql mysql  143 20 oct.  09:34 binlog-32.000039
-rw-rw----  1 mysql mysql  143 20 oct.  09:34 binlog-32.000040
-rw-rw----  1 mysql mysql  120 20 oct.  09:34 binlog-32.000041
-rw-rw----  1 mysql mysql 1,2K 20 oct.  09:34 binlog-32.index

看起来，用户在许多连接上进行了相当多的选择和更新的脚本。然而，令我惊讶的是，他如何设法DoS服务器。这是一个合理的原因，还是可能是其他原因，也许是某种错误配置？

Answer 1

您的用户似乎有相当高的工作量。

SELECTs没有写在二进制日志中，但UPDATEs是(以及所有其他数据更改)。

影响二进制日志大小的设置是：

• binlog_format：出于性能原因，我建议将其设置为ROW，但如果UPDATEs和DELETEs影响到许多行，则可能会导致您的文件占用日志空间。
• binlog_row_image：当事件以行格式登录时，此变量与UPDATE以及DELETE和REPLACE相关:它确定是否将旧值写入到binlog (通常是不必要的，但某些读取绑定日志的工具可能需要它)。
• binlog_row_metadata：是否记录列和主键元数据。
• binlog_row_value_options：修改JSON的一部分是否会导致在binlog中写入所有文档。
• 二进制日志事务压缩

Answer 2

在复制拓扑中的每个服务器上检查server-id in my.cnf。可能有个复制品。服务器ids必须不同。