MySQL 日常整理

st0627

　　记录工作的点点滴滴：
　　今天遇到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 语句的查询结构创建新的数据表，默认情况下，不会复制原来列的属性。但是可以根据原表的某列进行表的创建