Mysql:如果主或从服务器上出现磁盘满，而二进制日志没有空间，该怎么办？

Question

最近，我为我的产品配置了主从复制，而不考虑所有的用户情况。我开始在硬件级别上的所有可能的用例，以确保我们将准备好处理所有的失败。

对于下面的场景，我会看到任何更好的方法。

There is no space left on master to write binary logs
There is no space left on slave to write really logs

非常感谢你在这方面的帮助。你好，乌迪

Answer 1

基本上，你想要在它发生之前检测到它。

我使用莫尼特与文件系统检查一起发送电子邮件，并尝试一些基本步骤，如下所示；

 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上磁盘完整条件的结果在很大程度上取决于您如何配置MySQL和底层分区结构。CentOS打包版本的默认设置是编写以下内容

logs -> /var/log/mysqld.log
binlogs -> /var/lib/mysql/mysql-bin.00NNNN
data -> /var/lib/mysql/

但是，不幸的是，默认的文件系统布局是将/var/放在类似的单个分区上；

/dev/cciss/c0d0p2 on /var type ext3 (rw)

因此，磁盘满的结果通常是数据丢失的很好的sh*tty结果。

MySQL服务器处理磁盘完整状态的过程在这里的手册中描述；

http://dev.mysql.com/doc/refman/5.0/en/full-disk.html

根据文档，如果您释放足够的空间，它应该继续；

当出现磁盘满的情况时，MySQL执行以下操作:每分钟检查一次，以确定是否有足够的空间写入当前行。如果有足够的空间，就会继续下去，好像什么都没发生过一样。每隔10分钟，它就会将一个条目写入日志文件，并警告磁盘已满的情况。为了缓解这个问题，您可以采取以下操作:要继续，只需释放足够的磁盘空间来插入所有记录。

然而，我的经验是，到那时，太多的糟糕的事情已经发生了，而mysqld需要重新启动，失去了悬而未决的事务。

关于操作的顺序，版本5.1的mysql手册这是为了说明在写transacion或binlog失败时发生了什么事务；

二进制日志记录在语句完成后立即执行，但在释放任何锁或完成任何提交之前完成。这确保日志按执行顺序登录。对非事务性表的更新在执行后立即存储在二进制日志中。在MySQL 5.1.22和更早版本的MySQL 5.1中，使用修改非事务性表的存储函数的UPDATE语句在失败时不会被记录，并且插入.在重复键UPDATE语句中，遇到重复键约束但实际上没有更改任何数据的语句没有被记录。从MySQL 5.1.23开始，这两条语句都写入二进制日志。(Bug #23333)在未提交的事务中，所有更改事务性表(如InnoDB表)的更新(更新、删除或插入)都被缓存，直到服务器接收到COMMIT语句。此时，mysqld在执行提交之前将整个事务写入二进制日志。不能回滚对非事务性表的修改。如果回滚的事务包括对非事务性表的修改，则在结束时使用ROLLBACK语句记录整个事务，以确保对这些表的修改被复制。