mysql 主从复制 乱码_MySQL的主从复制步骤详解及常见错误解决方法

mysql主从复制(replication同步)现在企业用的比较多,也很成熟.它有以下优点:

1.降低主服务器压力,可在从库上执行查询工作.

2.在从库上进行备份,避免影响主服务器服务.

3.当主库出现问题时,可以切换到从库上.

不过,用它做备份时就会也有弊端,如果主库有误操作的话,从库也会收到命令.

下面直接进入操作.这里使用的是debian5操作系统,mysql5.0,默认引擎innodb

10.1.1.45 主库

10.1.1.43 从库

1.设置主库

1)修改主库my.cnf,这里主要是server-id一定主从不要设置成一样的.打开binlog日志

2)在主服务器上建立同步账号

注意:mysql的权限系统在实现上比较简单,相关权限信息主要存储在几个系统表中:mysql.user,mysql.db,mysql.host,mysql.table_priv,mysql.columm_priv.由于权限信息的数据量比较小,访问又非常频繁,所以mysql在启动的时候,就会将所有的权限信息都加载到内存中,并保存在几个特定的结构里.这就使得每次手动修改了相关权限表之后,都需要执行flush privileges，通知mysql重新加载mysql的权限信息.当然,如果通过grants,revoke或drop user 命令来修改相关权限，则不需要手动执行flush privileges命令.

3)在主服务器上导出数据库当时的快照,传给从库上.

root@10.1.1.45:mysql# mysqldump -uroot -p --single-transaction --flush-logs --master-data --all-databases > all.sql

--single-transaction:这个选项能够让innoDB和Falcon数据表在备份过程中保持不变.这一做法的关键在于它是在同一个事务里来导入各有关数据表的.mysqldump使用repeatable read事务隔离层来生成一份稳定一致的转储文件,同时不会阻塞其他客户(对于非事务性表,转储过程可能有变化),它不能与--lock-all-tables选项一起使用.

--flush-logs:在导出工作开始之前先清空mysql服务器的日志文件.这样更容易恢复操作,知道在检查点时间之后创建的二进制日志文件是在备份给定数据库之后完成的.结合使用--lock-all-tables或--master-data,只有在所有数据表都锁定之后才清除日志.这个选项需要具备reload权限.

--master-data:使用后mysqldump会在dump文件中产生changer master to命令,里面记录了dump时刻所对应的详细的log position信息.

2.设置从库

1).修改从库my.cnf

2)将主库的快照灌入从库

3)在从库上设置同步.查看从库状态.

测试OK

当然这只是最简单的配置

还有很多参数可根据环境需求变化.

比如

replicate-do-db=test    过滤拉主日志到从只需要这个库和下面的表

replicate-wild-do-table=test.dave

replicate-wild-do-table=test.davehe

mysql数据库同步跳过临时错误

Slave_IO_Running: No错误

由于主库的主机192.168.1.1宕机,再次启来后，从库192.168.71.1连接主库发现报错. Slave_IO_Running: No

查看错误日志

根据错误位置,查找主库上log ‘99.000302' 对应的位置 165112917

结果发现主库上位置最后是165111351 比165112917要小. 也就是从库同步找的位置比主库要大，故同步不成功

为什么会这样,这是因为这个在sync_binlog=0的情况，很容易出现。

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让系统自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

这里由于mysql是默认配置所以该报错原因是： sync_binlog=0时 ，master binlog文件的flush log buffer(这个buffer是由于binlog文件的os buffer)  到disk是依赖于OS本身的，但Slave IO 线程在读取master dump 线程的位置，一般是直接读取log buffer的,这个位置，可能远远大于binlog文件实际大小。 所以当主机宕机后，binlog buffer未刷盘，当Master主机再次启动后，此时从库的binlog pos 165112917  已经比实际的binlog位置大小165111351 还大了。

解决方法:

直接做change master to到当下一个binlog。