Eu tenho um mestre que possui 298 arquivos de bin de retransmissão tão recentes quanto hoje, voltando há 298 dias.

Não há definições de relay-log no arquivo .cnf

e

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              |
+---------------------------------+----------------+

O reset slave os limpa, mas eles começam a se regenerar.

Alguma idéia do que está causando isso? Como parar isso?

EDITAS A PEDIDOS

Críticas gerais ao cnf são bem-vindas, mas vamos manter o tópico do OP em mente.

---- 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)

Se um mestre tiver logs de retransmissão, ele também deverá ser um escravo no meio de alguma topologia de replicação (ou seja, mestre / mestre, replicação em cadeia)

O que poderia fazer com que os logs de retransmissão crescessem assim?

REPLICAÇÃO QUEBRADA

A replicação do MySQL é interrompida quando o segmento IO ou segmento SQL morre sob estes CENÁRIOS:

• CENÁRIO 1 : Quando o encadeamento IO e o encadeamento SQL estão desativados, uma das duas coisas aconteceu
  • O MySQL foi iniciado com skip-slave-startativado
  • Alguém / alguma coisa correu STOP SLAVE;
• CENÁRIO 2 : Quando o thread de E / S morre
  • nada pode empilhar os logs do relé
  • O encadeamento SQL processa todos os comandos SQL nos logs de retransmissão ou até que ocorra um erro SQL
• CENÁRIO # 3 : Quando o encadeamento SQL morre
  • Ocorreu um erro de SQL ao processar um comando SQL
  • A execução SHOW SLAVE STATUS\Gmostra Last_ErrnoeLast Error
  • O thread de E / S continuou coletando comandos SQL do mestre, fazendo os logs de retransmissão crescerem

É a SITUAÇÃO # 3 que é o problema. Quando o encadeamento SQL morre devido a um erro do SQL, não há mecanismo interno no MySQL Replication que aciona o encadeamento IO para desconectar .

RECOMENDAÇÃO

A única maneira decente de controlar o crescimento dos logs de retransmissão é definir o limite

[mysqld]
relay_log_space_limit=4G

Definir relay_log_space_limit coloca um limite de 4G.

Quando um log de retransmissão é completamente processado

• é girado para fora
• o encadeamento SQL começa a trabalhar no próximo log de retransmissão
• o encadeamento de E / S começa a carregar SQL do Master a partir do último local em que ele saiu, desde que haja espaço livre suficiente no disco

EPÍLOGO

Se o Mestre costumava ser Escravo e não precisa mais ser, desative-o.

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

Se o mestre for escravo, corrija o erro SQL.

Eu sugeriria isso se o erro SQL estiver no caminho:

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

depois, execute SHOW SLAVE STATUS\Gcada minuto para ver se os logs de retransmissão são processados ​​e girados.

Sem ver seu my.cnf, é impossível responder a essa pergunta, mas eu também sugeriria postar sua saída SHOW SLAVE STATUS \ G - é possível que seu escravo esteja realmente incrivelmente atrasado? Isso manteria os registros do relé por perto. O segmento SQL Slave está em execução?

Será que o arquivo my.cnf está configurado incorretamente e os logs binários principais são nomeados como logs de retransmissão?

Ou talvez o seu mestre tenha configurações de replicação codificadas no arquivo my.cnf, que são selecionadas na reinicialização da instância do MySQL.

Edição: Você mascarou o nome do arquivo binlog real na show master statussaída? Estou perguntando porque a configuração em my.cnf não corresponde ao nome do binlog. Se sim, você poderia fornecer o nome do arquivo real e a saída de show slave statusAaron mencionada? Até agora, exceto a incompatibilidade de nomes para o bin-log, nada se destaca no seu arquivo my.cnf.

Execute o comando RESET SLAVE. Ele limpa os logs dos relés e gera novamente um novo. Mas, ele não usará o novo. Você pode verificar executando mais tarde o comando FLUSH LOGS, o servidor não criará um segundo log de retransmissão.