大量的中继日志记录在一个主节点上

Question

我有一个拥有 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)

Answer 1

如果 Master 有中继日志，那么 Master 也必须是某些复制拓扑（即 Master/Master、菊花链复制）中的 Slave

什么会导致中继日志像这样增长？

损坏的复制

当 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 Thread不断从Master收集SQL命令，使得relay日志增长

问题在于情况#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

如果Master是Slave，去更正SQL错误。

如果 SQL 错误妨碍了我，我会建议这样做：

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

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

Answer 2

是否是 my.cnf 文件配置错误，主二进制日志被命名为中继日志？

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

编辑： 您是否掩盖了show master status输出中的实际二进制日志文件名？我这样问是因为 my.cnf 中的设置与 binlog 名称不匹配。如果是这样，您能否提供实际的文件名以及show slave status亚伦提到的输出？到目前为止，除了 bin-log 的名称不匹配之外，您的 my.cnf 文件中没有任何异常情况。