Ho un master che ha 298 file bin di inoltro recenti come oggi, che risale a ben 298 giorni.

Non ci sono definizioni di log di inoltro nel file .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              |
+---------------------------------+----------------+

Reset slave li cancella, ma poi iniziano a rigenerarsi.

Qualche idea di cosa sta causando questo? Come fermarlo?

MODIFICHE SU RICHIESTA

Le critiche generali del CNF sono benvenute, ma teniamo presente l'argomento 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)

Se un Master ha registri di inoltro, anche il Master deve essere uno Slave nel mezzo di una topologia di replica (ad esempio, Master / Master, Replica a catena)

Cosa potrebbe causare la crescita dei log dei relay in questo modo?

REPLICAZIONE ROTTA

La replica di MySQL si interrompe quando il thread IO o il thread SQL muore sotto questi SCENARI:

• SCENARIO # 1 : quando il thread IO e il thread SQL sono disattivati, una delle due cose è avvenuta
  • MySQL è stato avviato con skip-slave-startabilitato
  • Qualcuno / qualcosa ha funzionato STOP SLAVE;
• SCENARIO # 2 : quando il thread IO muore
  • nulla può accumulare i registri dei relè
  • Il thread SQL elabora tutti i comandi SQL nei log di inoltro o fino a quando si verifica un errore SQL
• SCENARIO # 3 : quando il thread SQL muore
  • Si è verificato un errore SQL durante l'elaborazione di un comando SQL
  • La corsa SHOW SLAVE STATUS\Gti mostra il Last_ErrnoeLast Error
  • IO Thread ha continuato a raccogliere i comandi SQL dal Master, facendo crescere i log di inoltro

È la SITUAZIONE # 3 che è il problema. Quando il thread SQL muore a causa di un errore SQL, non esiste alcun meccanismo incorporato nella replica MySQL che innesca la disconnessione del thread IO .

RACCOMANDAZIONE

L'unico modo decente per controllare la crescita dei registri di inoltro è di impostarne il limite

[mysqld]
relay_log_space_limit=4G

L'impostazione di relay_log_space_limit posiziona un limite di 4G.

Quando un registro di inoltro è completamente elaborato

• è ruotato fuori
• il thread SQL inizia a lavorare sul registro di inoltro successivo
• il thread I / O inizia a caricare SQL dal Master dall'ultima posizione da cui è rimasto, purché ci sia abbastanza spazio libero sul disco

EPILOGO

Se il Master era uno Slave e non deve più esserlo, disabilitalo semplicemente.

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

Se il master è uno slave, vai a correggere l'errore SQL.

Vorrei suggerire questo se l'errore SQL è di ostacolo:

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

quindi esegui SHOW SLAVE STATUS\Gogni minuto per vedere se i log dei relè vengono elaborati e ruotati.

Senza vedere my.cnf, è impossibile rispondere a questa domanda, ma suggerirei anche di pubblicare il tuo output SHOW SLAVE STATUS \ G - è possibile che il tuo slave sia incredibilmente molto indietro? Ciò manterrebbe i log dei relè in giro. Il thread slave SQL è in esecuzione?

È possibile che il file my.cnf sia configurato in modo errato e che i registri binari master siano denominati registri di inoltro?

O forse il tuo master ha impostazioni di replica codificate nel file my.cnf, che vengono raccolte al riavvio dell'istanza di MySQL.

EDIT: hai mascherato il nome del file binlog effettivo show master statusnell'output? Lo sto chiedendo perché l'impostazione in my.cnf non corrisponde al nome binlog. In tal caso, potresti fornire il nome file effettivo e l'output di show slave statuscome Aaron menzionato? Finora diverso dalla mancata corrispondenza dei nomi per bin-log, nulla si distingue nel tuo file my.cnf.

Eseguire il comando RESET SLAVE. Pulirà i registri dei relè e ne rigenererà uno nuovo. Ma non utilizzerà quello nuovo. È possibile verificare eseguendo in seguito il comando FLUSH LOGS, il server non creerà un secondo log di inoltro.