记录工作的点点滴滴：

    今天遇到case 1:

    在测试机上，start slave 出现“假死”现象，数据库能够连接，

    show processlist;显示：队列等待master

    从错误日志里面看到：

120831 16:20:59 [ERROR] /usr/local/mysql3307/libexec/mysqld: Disk is full writing './mysqld-relay-bin.~rec~' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)120831 16:20:59 [ERROR] /usr/local/mysql3307/libexec/mysqld: Retry in 60 secs. Message reprinted in 600 secs

    日志里面显示没有了磁盘空间，哎，这个着实不能让人接受。

    清理了磁盘，set  global SQL_SLAVE_SKIP_COUNTER=1;start slave;

    (SQL_SLAVE_SKIP_COUNTER 复制线程起来之后，该变量的值变为无)

   case 2：

   今天有人问了我一个问题，在主从复制模式下，master采用innodb，slave 采用myisam（这个是可以实现的，因为在binlog里面 是不传递engine=?这个参数的），当程序里面启用事物的时候，如果出现回滚，那么采用myisam 引擎的slave会不会造成和master数据的不一致。

    首先肯定的是，这个不会造成数据的不一致。

    其次：由于myisam不支持事务，对不支持事务的表执行start/commit 操作没有任何效果，在执行commit前已经提交，且不会报错。

    最后，在binlog里面如果发生rollback 语句的话，事务会执行反操作，清除库里面的数据，binlog里面响应的dml语句会响应的被清除，也不会有rollback语句的记录。所有master和slave上数据还是一致的。

    case 3:

    从其他数据表或者查询结果创建数据表

    create table ... like 语句将创建一个和原表一模一样的表，并且列的属性页会保持。 但是这个语句不能只利用其中原表的某列进行进行表的创建

     create table ... select 会根据select 语句的查询结构创建新的数据表，默认情况下，不会复制原来列的属性。但是可以根据原表的某列进行表的创建

本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/978741，如需转载请自行联系原作者