J'ai un maître qui a 298 fichiers bin de relais aussi récents qu'aujourd'hui, remontant bien 298 jours.

Il n'y a pas de définitions de journal de relais dans le .cnf

et

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

Réinitialiser l'esclave les efface, mais ensuite ils commencent juste à se régénérer.

Une idée de ce qui cause ça? Comment l'arrêter?

MODIFICATION DES DEMANDES

Les critiques générales du CNF sont les bienvenues, mais gardons le sujet OP à l'esprit.

---- 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 maître a des journaux de relais, le maître doit également être un esclave au milieu d'une topologie de réplication (c.-à-d. Maître / maître, réplication en chaîne)

Qu'est-ce qui pourrait faire croître les journaux de relais comme ceci?

RÉPLICATION CASSÉE

La réplication MySQL est interrompue lorsque le thread IO ou le thread SQL meurt sous ces SCÉNARIOS:

• SCÉNARIO # 1 : Lorsque le thread IO et le thread SQL sont désactivés, l'une des deux choses s'est produite
  • MySQL a été démarré avec skip-slave-startactivé
  • Quelqu'un / quelque chose a couru STOP SLAVE;
• SCÉNARIO # 2 : Quand le thread IO meurt
  • rien ne peut empiler les journaux de relais
  • Le thread SQL traite toutes les commandes SQL dans les journaux de relais ou jusqu'à ce qu'une erreur SQL se produise
• SCÉNARIO # 3 : Lorsque le thread SQL meurt
  • Une erreur SQL s'est produite lors du traitement d'une commande SQL
  • La course SHOW SLAVE STATUS\Gvous montre le Last_ErrnoetLast Error
  • IO Thread a continué de collecter les commandes SQL du maître, ce qui a fait grandir les journaux de relais

C'est la SITUATION # 3 qui est le problème. Lorsque le thread SQL meurt en raison d'une erreur SQL, il n'y a pas de mécanisme intégré dans la réplication MySQL qui déclenche la déconnexion du thread IO .

RECOMMANDATION

La seule façon décente de contrôler la croissance des journaux de relais est de définir la limite

[mysqld]
relay_log_space_limit=4G

La définition de relay_log_space_limit place un plafond de 4G.

Lorsqu'un journal de relais est complètement traité

• il est tourné
• le thread SQL commence à travailler sur le prochain journal de relais
• le thread d'E / S commence à charger SQL à partir du maître à partir du dernier endroit d'où il est resté, tant qu'il y a suffisamment d'espace libre sur le disque

ÉPILOGUE

Si le maître était un esclave et qu'il n'a plus besoin de l'être, désactivez-le simplement.

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

Si le maître est un esclave, corrigez l'erreur SQL.

Je suggérerais ceci si l'erreur SQL gêne:

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

puis exécutez SHOW SLAVE STATUS\Gtoutes les minutes pour voir si les journaux de relais sont traités et tournés.

Sans voir votre my.cnf, il est impossible de répondre à cette question, mais je suggérerais également de publier votre sortie SHOW SLAVE STATUS \ G - est-il possible que votre esclave soit réellement très loin derrière? Cela garderait les journaux de relais autour. Le thread SQL Slave est-il en cours d'exécution?

Se pourrait-il que le fichier my.cnf soit mal configuré et que les journaux binaires principaux soient nommés journaux de relais?

Ou peut-être que votre maître a des paramètres de réplication codés en dur dans le fichier my.cnf, qui sont récupérés au redémarrage de l'instance MySQL.

EDIT: Avez-vous masqué le nom de fichier binlog réel en show master statussortie? Je demande parce que le paramètre dans my.cnf ne correspond pas au nom binlog. Si oui, pourriez-vous fournir le nom de fichier réel et la sortie de show slave statuscomme Aaron l'a mentionné? Jusqu'à présent, à part la différence de nom pour le journal de connexion, rien ne se distingue dans votre fichier my.cnf.

Exécutez la commande RESET SLAVE. Il nettoiera les journaux des relais et en régénérera un nouveau. Mais, il n'utilisera pas le nouveau. Vous pouvez vérifier en exécutant plus tard la commande FLUSH LOGS, le serveur ne créera pas de deuxième journal de relais.