今天做对公司的阿里云的服务器进行做了一主多从配置.

如何配置请参考  一主多从服务器配置

配置好后我直接对主服务器进行了，导数据，主服务器的数据库导入操作完毕，但是从服务器的操作还没有完成，当时我以为是假死，或者说数据源丢失，或者因为内存不足造成的，后来我优化了linux的自动释放内存机制，仍然不行，cache的量增加的还是很快，一会2G的内存就跑满了，后来我用shell 定时释放服务器内存，这才控制住内存，不过在4G的内存里面跑，还是有些挑战的，虽然内存降下来，但是问题没有解决，在最后我给一个同事处理问题的时候，我发现原本不对称的数据竟然一点点的在同步，这个时候我明白了。原来Mysql 的主从同步原理是 一个长连接，并通过日志文件进行同步. 如果主服务器操作完成后，即使断电、断网只要主服务器恢复正常后仍然会自动同步，这点还是比较强大的，当然前提是你发现你的slave服务器的运行和IO仍然是YES.

这里有几个特殊情况造成mysql主从同步因断电产生的不能同步问题：

1、MYSQL镜像服务器因错误停止的恢复

从服务器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377

看一下主服务器：mysqlhxmaster.000007 | 84450528 |
已经过后很多了，确实没跟上。

show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No

操作方法：

先stop slave，然后执行了一下提示的语句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，从服务器也在几分钟内把堆积的log处理完了，两边又同步了：)

从MYSQL服务器Slave_IO_Running: No的解决2

mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log 'mysqlmaster.000079' at position 183913228, relay log './hx-relay-bin.002934' position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master 'replicuser@192.168.1.21:3306', replication started in log 'mysqlmaster.000079' at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log 'mysqlmaster.000079', position 183913228

这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。

查看一下这个Log的最后几行：
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.

尝试从损坏之前的位置开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000079', MASTER_LOG_POS=183913220;
SLAVE START;
无效！
只好从新的日志开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE='mysqlcncnmaster.000080', MASTER_LOG_POS=0;
SLAVE START;
此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。

另外，出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据。

 

当然纯粹的主从还是性能的高可用的价值还是体现不出来的，架构上 MHA会更安全，在一台从服务器上架构就好，不过这台从服务器不要再充当Mastsr 服务器了。

 

 

上一篇:MySQL高可用系列之MHA（一）
下一篇:Thinkphp + PHPExcel + Jquery 实现导数据特效