Tengo un maestro que tiene 298 archivos bin de retransmisión tan recientes como hoy, que datan de hace 298 días.

No hay definiciones de registro de retransmisión en el .cnf

y

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

Restablecer esclavo los borra, pero luego comienzan a regenerarse.

¿Alguna idea de lo que está causando esto? ¿Cómo detenerlo?

EDICIONES A SOLICITUDES

Las críticas generales de la CNF son bienvenidas, pero tengamos en cuenta el tema 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)

Si un maestro tiene registros de retransmisión, el maestro también debe ser un esclavo en medio de alguna topología de replicación (es decir, maestro / maestro, replicación en cadena)

¿Qué podría causar que los registros de retransmisión crezcan así?

REPLICACIÓN ROTA

La replicación MySQL se interrumpe cuando el subproceso IO o el subproceso SQL muere bajo estos ESCENARIOS:

• ESCENARIO # 1 : Cuando el subproceso IO y el subproceso SQL están desactivados, ocurre una de dos cosas
  • MySQL se inició con skip-slave-starthabilitado
  • Alguien / algo corrió STOP SLAVE;
• ESCENARIO # 2 : Cuando el hilo IO muere
  • nada puede apilar los registros de retransmisión
  • El hilo SQL procesa todos los comandos SQL en los registros de retransmisión o hasta que se produce un error SQL
• ESCENARIO # 3 : Cuando el hilo SQL muere
  • Se produjo un error de SQL al procesar un comando de SQL
  • Correr SHOW SLAVE STATUS\Gte muestra el Last_ErrnoyLast Error
  • IO Thread continuó recolectando comandos SQL del Maestro, haciendo crecer los registros de retransmisión

Es la SITUACIÓN # 3 ese es el problema. Cuando el hilo SQL muere debido a un error de SQL, no hay un mecanismo incorporado en MySQL Replication que active la desconexión del hilo IO .

RECOMENDACIÓN

La única forma decente de controlar el crecimiento de los registros de retransmisión es establecer el límite

[mysqld]
relay_log_space_limit=4G

La configuración de relay_log_space_limit coloca un límite de 4G.

Cuando un registro de retransmisión se procesa por completo

• está girado
• el hilo SQL comienza a funcionar en el siguiente registro de retransmisión
• el subproceso de E / S comienza a cargar SQL desde el maestro desde el último lugar desde el que queda, siempre que haya suficiente espacio libre en el disco

EPÍLOGO

Si el maestro solía ser un esclavo y ya no necesita serlo, simplemente desactívelo.

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

Si el maestro es un esclavo, vaya a corregir el error de SQL.

Sugeriría esto si el error de SQL está en el camino:

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

luego ejecute SHOW SLAVE STATUS\Gcada minuto para ver si los registros del relé se procesan y giran.

Sin ver su my.cnf, es imposible responder a esta pregunta, pero también sugeriría publicar su salida SHOW SLAVE STATUS \ G: ¿es posible que su esclavo esté realmente muy lejos? Eso mantendría los registros de relevos. ¿Se está ejecutando el subproceso SQL Slave?

¿Podría ser que el archivo my.cnf esté mal configurado y los registros binarios maestros se denominen registros de retransmisión?

O tal vez su maestro tiene configuraciones de replicación codificadas en el archivo my.cnf, que se recogen al reiniciar la instancia de MySQL.

EDITAR: ¿Enmascaró el nombre de archivo binlog real en la show master statussalida? Estoy preguntando porque la configuración en my.cnf no coincide con el nombre de binlog. Si es así, ¿podría proporcionar el nombre de archivo real y la salida de la show slave statusque Aaron mencionó? Hasta ahora, aparte de la falta de coincidencia de nombres para bin-log, nada se destaca en su archivo my.cnf.

Ejecute el comando RESET SLAVE. Limpiará los registros de los relés y regenerará uno nuevo. Pero, no usará el nuevo. Puede verificar ejecutando más tarde el comando FLUSH LOGS, el servidor no creará un segundo registro de retransmisión.