While using replication, you might experience corrupted or incomplete binlog files on the master when the disk they get stored on becomes full. In older versions, the file would be started and when the disk became full in the middle of an event being written, this partial data would be replicated and cause errors on the slaves.
Versions 5.0 and up handle an out-of-space situation more gracefully, as they do not write partial statements to the binlog and try harder to keep the table data and the binlog in sync. However, you still need to be aware that there is no 100-percent sure way of preventing problems on the slaves because under certain circumstances you can end up with the last statement having executed in the database, but not recorded in the binlog.
The master server will log this fact into its logfile, so your monitoring system might pick this up with lines like:
The binary log <name> is shorter than its expected size.
but still the problem remains.
The MySQL manual has more details about this in chapters 5.2.4 at http://dev.mysql.com/doc/refman/5.1/en/binary-log.html and B.1.4.3 on disk-full problems at http://dev.mysql.com/doc/refman/5.1/en/full-disk.html.
Note
The bottom line about this, however, is that even with the most conservative settings—--sync_binlog=1 and --innodb_support_xa=1, leading to reduced performance due to more disk syncs—you can still end up with incomplete binlogs, be it on MySQL's part or the operating system's, requiring you to reset the replication and manually re-sync the slaves from a fresh dump.
Considering the performance penalties, the options MySQL offers to limit the risks of damaging the binlogs and the fact that they do not guarantee problem-free operations anyway, we recommend investing your resources in a reliable system-monitoring solution that will keep you informed about critical conditions regarding disk space and allow you to prevent these problems in the first place.