Tons and tons of relay logs on a master
If a Master has relay logs, then the Master must also be a Slave in the midst of some Replication topology (i.e., Master/Master, Daisy-Chained Replication)

What could cause relay logs to grow like this?

BROKEN REPLICATION

MySQL Replication is broken when the IO Thread or SQL thread dies under these SCENARIOS:


SCENARIO #1 : When the IO Thread and SQL thread are off, one of two things happended

MySQL was started with skip-slave-start enabled
Someone/something ran STOP SLAVE;

SCENARIO #2 : When the IO thread dies

nothing can pile up the relay logs
The SQL thread processes all SQL commands in the relay logs or until a SQL error occurs

SCENARIO #3 : When the SQL thread dies

SQL error occurred processing a SQL command
Running SHOW SLAVE STATUS\G shows you the Last_Errno and Last Error
IO Thread continued collecting SQL commands from the Master, making relay logs grow



It is SITUATION #3 that's the problem. When the SQL thread dies due to a SQL error, there is no built-in mechanism in MySQL Replication that triggers the IO thread to disconnect.

RECOMMENDATION

The only decent way to control the growth of relay logs is to set the limit on it

[mysqld]
relay_log_space_limit=4G


Setting relay_log_space_limit places a cap of 4G.

When a relay log is completely processed


it is rotated out
the SQL thread starts working on the next relay log
the I/O thread starts loading SQL from the Master from the last place it left of from, as long as there is enough freespace on the disk


EPILOGUE

If the Master used to be a Slave and it does not need to be anymore, simple disable it.

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


If the Master is a Slave, go correct the SQL error.

I would suggest this if the SQL error is in the way:

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


then run SHOW SLAVE STATUS\G every minute to see if the relay logs get processed and rotated.