到目前为止，我有一个拥有298个中继bin文件的主文件，可以追溯到298天。

.cnf中没有中继日志定义

和

mysql> show variables like '%relay%';
+---------------------------------+----------------+
| Variable_name                   | Value          |
+---------------------------------+----------------+
| innodb_overwrite_relay_log_info | OFF            |
| max_relay_log_size              | 0              |
| relay_log                       |                |
| relay_log_index                 |                |
| relay_log_info_file             | relay-log.info |
| relay_log_purge                 | ON             |
| relay_log_space_limit           | 0              |
+---------------------------------+----------------+

重置从站将其清除，但随后它们才开始重新生成。

知道是什么原因造成的吗？如何停止呢？

要求编辑

欢迎对cnf进行一般性的批评，但让我们牢记OP主题。

---- cnf request

[mysqld]
character_set_server = utf8

max_connections=200
max_user_connections=160
max_connect_errors=10000

userstat_running = 1

log_warnings
slow_query_log=1
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2


innodb_file_per_table

innodb_open_files=2048

innodb_additional_mem_pool_size=1M

innodb_buffer_pool_size=512M

innodb_log_buffer_size=1M

innodb_log_file_size=128M

innodb_autoextend_increment=16


innodb_flush_method=O_DIRECT


datadir=/var/lib/mysql/


tmpdir=/var/lib/mysql_ramdisk


server-id=2

log-bin = /var/log/mysql/mysql-bin
log-bin-index = /var/log/mysql/mysql.index

key_buffer_size = 800M

preload_buffer_size = 256K

max_allowed_packet = 8M
table_cache = 512
sort_buffer_size = 8M
join_buffer_size = 8M

read_buffer_size = 2M
read_rnd_buffer_size = 2M
thread_cache_size = 32
query_cache_size = 32M
query_cache_limit = 16M


myisam_sort_buffer_size = 2000M


tmp_table_size = 64M
max_heap_table_size = 64M

---- now for the cli requests

mysql> show slave status\G
Empty set (0.00 sec)

mysql> show master status;
+---------------------+----------+--------------+------------------+
| File                | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+--------------+------------------+
| awesome-bin.xxxxxxx | yyyyyyyy |              |                  |
+---------------------+----------+--------------+------------------+
1 row in set (0.00 sec)



---- version


mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.1.47-rel11.1-log |
+--------------------+
1 row in set (0.00 sec)

如果主服务器具有中继日志，则该主服务器还必须是某些复制拓扑（例如，主服务器/主服务器，菊花链复制）中的从服务器。

是什么导致中继日志如此增长？

残缺的复制

当这些SCENARIOS下的IO线程或SQL线程死亡时，MySQL复制会中断：

• 场景1：当IO线程和SQL线程关闭时，发生了以下两种情况之一
  • MySQL已skip-slave-start启用
  • 有人/某事跑了STOP SLAVE；
• 场景2：IO线程死亡时
  • 没有什么可以堆积中继日志
  • SQL线程处理中继日志中的所有SQL命令，或者直到发生SQL错误为止
• 场景3：SQL线程死亡时
  • 处理SQL命令时发生SQL错误
  • 运行SHOW SLAVE STATUS\G向您显示Last_Errno和Last Error
  • IO线程继续从主服务器收集SQL命令，从而使中继日志增长

问题是第3种情况。当SQL线程由于SQL错误而终止时，MySQL Replication中没有内置机制可触发IO线程断开连接。

建议

控制中继日志增长的唯一合适方法是对其设置限制

[mysqld]
relay_log_space_limit=4G

设置relay_log_space_limit设置上限为4G。

中继日志完全处理后

• 它被旋转出去
• SQL线程开始在下一个中继日志上工作
• 只要磁盘上有足够的可用空间，I / O线程就会从它的最后一个位置开始从Master加载SQL。

结语

如果Master曾经是Slave，并且不再需要，则只需禁用它即可。

mysql -e"STOP SLAVE; CHANGE MASTER TO MASTER_HOST='';"
rm -f /var/lib/mysql/master.info

如果主服务器是从服务器，请更正SQL错误。

如果出现SQL错误，我建议这样做：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE SQL_THREAD;

然后SHOW SLAVE STATUS\G每分钟运行一次，以查看中继日志是否得到处理和轮换。

如果没有看到my.cnf，就不可能回答这个问题，但是我还建议发布您的SHOW SLAVE STATUS \ G输出-您的奴隶是否真的遥不可及？这样可以保持中继日志。SQL Slave线程正在运行吗？

可能是my.cnf文件配置错误并且主二进制日志被命名为中继日志吗？

或者，您的主服务器在my.cnf文件中具有硬编码的复制设置，这些设置在MySQL实例重启时获取。

编辑： 您是否掩盖了show master status输出中的实际binlog文件名？我问是因为my.cnf中的设置与binlog名称不匹配。如果是这样，您能否提供实际的文件名以及show slave status提到的类似Aaron 的输出？到目前为止，除了bin-log的名称不匹配之外，您的my.cnf文件中没有其他任何内容。

执行RESET SLAVE命令。它将清除中继日志并重新生成一个新的日志。但是，它不会使用新的。您可以通过稍后运行FLUSH LOGS命令进行检查，服务器将不会创建第二个中继日志。