I solved the problem by dumping a copy of another slave and following the instructions found here:



Specifically:


It is also possible to set up a slave by dumping an existing slave of the master. To do this, use the following procedure on the existing slave:Stop the slave's SQL thread and get its current status:mysql> STOP SLAVE SQL_THREAD;mysql> SHOW SLAVE STATUS;From the output of the SHOW SLAVE STATUS statement, the binary log coordinates of the master server from which the new slave should start replicating are the values of the Relay_Master_Log_File and Exec_Master_Log_Pos fields. Denote those values as file_name and file_pos.Dump the slave server:shell> mysqldump --master-data=2 --all-databases > dumpfileRestart the slave:mysql> START SLAVE;On the new slave, load the dump file:shell> mysql < dumpfileOn the new slave, set the replication coordinates to those of the master server obtained earlier:mysql> CHANGE MASTER TO -> MASTER_LOG_FILE = 'file_name', MASTER_LOG_POS = file_pos;The CHANGE MASTER TO statement might also need other parameters, such as MASTER_HOST to point the slave to the correct master server host. Add any such parameters as necessary.

This URL was also interesting (if you want to do it one db at a time with minimal downtime):

Yeah, reloading data was the only solution you could take in this case.

For the future I'd suggest you to look at the 'expire_logs_days' variable - maybe you have enough disk space to keep old binlogs longer.
Also any script monitoring replication status would save you a lot of time.

Btw. "show binary logs" and "purge binary logs to ..." commands are very handful in doing smart binlog rotating scripts )