最近，我考虑了所有的用户案例，为我的生产configuration了主从复制。 我再次启动硬件级别的所有可能的用例，以确保我们将准备好处理所有的故障。
对于下面的情况，我可以看到更好的方法。
There is no space left on master to write binary logs There is no space left on slave to write really logs 非常感谢你的帮助。 问候，乌代
基本上你想在它发生之前检测到这一点。
我使用monit和文件系统检查来发送电子邮件，并尝试一些基本步骤。
check filesystem rootfs with path /dev/hda1 IF SPACE USAGE > 90 % THEN alert IF SPACE USAGE > 95 % THEN EXEC '/run/script/with/logrotate/and/empty/tmp/dir/while/you/read/alert/email'
mysql上磁盘满状态的结果高度依赖于你如何configurationMySQL和底层的分区结构。 CentOS打包版本的默认设置是编写以下内容
logs -> /var/log/mysqld.log binlogs -> /var/lib/mysql/mysql-bin.00NNNN data -> /var/lib/mysql/
然而，不幸的是，默认的文件系统布局是把/ var /放在一个单独的parition上。
/dev/cciss/c0d0p2 on /var type ext3 (rw)
因此磁盘满的结果通常是一个相当丢失数据的结果。
处理磁盘已满情况的MySQL服务器程序在手册中描述;
http://dev.mysql.com/doc/refman/5.0/en/full-disk.html
根据文件，如果你释放足够的空间，它应该继续;
发生磁盘满情况时，MySQL会执行以下操作：
It checks once every minute to see whether there is足够的空间来写入当前行。 如果有足够的空间，就好像什么也没发生一样。
Every 10 minutes it writes an entry to the log file,警告有关磁盘已满的情况。
为了缓解这个问题，你可以采取以下措施：
To continue, you only have to free enough disk space to insert all records.
但是我的经验是，那时太多崩溃的东西已经发生，mysqld需要重新启动，同时丢失未决事务。
关于操作的顺序， 5.1版本的mysql手册有这样的说明，在写入transacion或binlog失败的时候，事务会发生什么;
二进制日志logging在语句完成后，但在任何锁释放或任何提交完成之前立即完成。 这确保了日志以执行顺序logging。
非事务表的更新在执行后立即存储在二进制日志中。 在MySQL 5.1.22和早期版本的MySQL 5.1中，使用存储函数修改非事务表的UPDATE语句在失败时不会被logging，而且会遇到重复键约束的INSERT … ON DUPLICATE KEY UPDATE语句，但实际上并没有改变任何数据 – 没有logging。 从MySQL 5.1.23开始，这两个语句都被写入二进制日志。 （错误＃23333）
在未提交的事务中，更改事务表（例如InnoDB表）的所有更新（UPDATE，DELETE或INSERT）都将被caching，直到服务器接收到COMMIT语句。 此时，mysqld在执行COMMIT之前将整个事务写入二进制日志。
对非事务表的修改无法回滚。 如果回滚的事务包括对非事务表的修改，则最后使用ROLLBACK语句logging整个事务，以确保对这些表的修改得到复制。