突然海量的binlog文件

我已經看到在 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

似乎一個使用者使用了一個腳本，該腳本在許多連接上執行了相當多的 SELECT 和 UPDATE。然而，令我驚訝的是他是如何設法對伺服器進行 DoS 攻擊的。這是一個合理的原因，還是可能是其他原因，也許是一些錯誤配置？

您的使用者似乎造成了相當高的工作量。

SELECTs 沒有寫入 binlog，但UPDATEs 是（以及所有其他數據更改）。

影響二進制日誌大小的設置是：

• binlog_format：出於性能原因，我建議將其設置為，但是如果s 和s 影響許多行ROW，這可能會導致您的文件佔用日誌空間。UPDATE``DELETE
• binlog_row_image: 當事件以 ROW 格式記錄時，此變數與UPDATE, 以及DELETE和相關REPLACE：它決定是否將舊值寫入 binlog（通常不需要，但某些讀取 binlog 的工具可能需要它）。
• binlog_row_metadata：是否記錄列和主鍵元數據。
• binlog_row_value_options: 修改 JSON 文件的一部分是否會導致所有文件寫入 binlog。
• 二進制日誌事務壓縮

簽入複製拓撲server-id中my.cnf的每台伺服器。可能有重複。伺服器 ID必須不同。

引用自：https://dba.stackexchange.com/questions/118610