先上Master库：mysql>show processlist; 查看下进程是否Sleep太多。发现很正常。show master status; 也正常。mysql> show master status;+-------------------+----------+--------------+-------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+-------------------+----------+--------------+-------------------------------+| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |+-------------------+----------+--------------+-------------------------------+1 row in set (0.00 sec)再到Slave上查看mysql> show slave status\GSlave_IO_Running: YesSlave_SQL_Running: No可见是Slave不同步下面介绍两种解决方法：
方法一：忽略错误后，继续同步该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况解决：stop slave;#表示跳过一步错误，后面的数字可变set global sql_slave_skip_counter =1;start slave;之后再用mysql> show slave status\G 查看：Slave_IO_Running: YesSlave_SQL_Running: Yesok，现在主从同步状态正常了。。。
方式二：指定跳过错误代码，继续同步主键冲突、表已存在等错误代码如1062,1032,1060等，可以在mysql主配置文件指定略过此类异常并继续下条sql同步，这样也可以避免很多主从同步的异常中断[mysqld]slave-skip-errors = 1062,1032,1060重新启动mysqlservice mysqld restart之后再用mysql> show slave status\G 查看： Slave_IO_Running: Yes Slave_SQL_Running: Yes方式三：重新做主从，完全同步该方法适用于主从库数据相差较大，或者要求数据完全统一的情况解决步骤如下：
1.先进入主库，进行锁表，防止数据写入使用命令：mysql> flush tables with read lock;注意：该处是锁定为只读状态，语句不区分大小写
2.进行数据备份#把数据备份到mysql.bak.sql文件[root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql这里注意一点：数据库备份一定要定期进行，可以用shell脚本或者python脚本，都比较方便，确保数据万无一失
3.查看master 状态mysql>show master status;+-------------------+----------+--------------+-------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+-------------------+----------+--------------+-------------------------------+| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |+-------------------+----------+--------------+-------------------------------+1 row in set (0.00 sec)
4.把mysql备份文件传到从库机器，进行数据恢复#使用scp命令[root@server01 mysql]# scp mysql.bak.sql root@192.168.128.101:/tmp/
5.停止从库的状态mysql> stop slave;
6.然后到从库执行mysql命令，导入数据备份mysql> source /tmp/mysql.bak.sql
7.设置从库同步，注意该处的同步点，就是主库show master status信息里的| File| Position两项change master to master_host = '192.168.128.100', master_user = 'rsync', master_port=3306, master_password='', master_log_file = 'mysqld-bin.000001', master_log_pos=3260;
8.重新开启从同步mysql> stop slave;
9.查看同步状态mysql> show slave status\G 查看：Slave_IO_Running: YesSlave_SQL_Running: Yes
一般在线增加从库有两种方式，一种是通过mysqldump备份主库，恢复到从库，mysqldump是逻辑备份，数据量大时，备份速度会很慢，锁表的时间也会很长。另一种是通过xtrabackup工具备份主库，恢复到从库，xtrabackup是物理备份，备份速度快，不锁表。为什么不锁表？因为自身会监控主库日志，如果有更新的数据，就会先写到一个文件中，然后再回归到备份文件中，从而保持数据一致性。
服务器信息：
主库：192.168.18.212(原有)
从库1：192.168.18.213(原有)
从库2：192.168.18.214(新增)
数据库版本：MySQL5.5
存储引擎：Innodb
测试库名：weibo
一、mysqldump方式
MySQL主从是基于binlog日志，所以在安装好数据库后就要开启binlog。这样好处是，一方面可以用binlog恢复数据库，另一方面可以为主从做准备。
原有主库配置参数如下：
1. 主库创建同步账号
mysql> grant all on *.* to'sync'@'192.168.18.%'identified by'sync';
2. 从库配置MySQL
3. 备份主库
# mysqldump -uroot -p123 --routines --single_transaction --master-data=2 --databases weibo > weibo.sql
参数说明：
--routines：导出存储过程和函数
--single_transaction：导出开始时设置事务隔离状态，并使用一致性快照开始事务，然后unlock tables;而lock-tables是锁住一张表不能写操作，直到dump完毕。
--master-data：默认等于1，将dump起始(change master to)binlog点和pos值写到结果中，等于2是将change master to写到结果中并注释。
4. 把备份库拷贝到从库
# scp weibo.sql root@192.168.18.214:/home/root
5. 在主库创建test_tb表，模拟数据库新增数据，weibo.sql是没有的
mysql> create table test_tb(idint,name varchar(30));
6. 从库导入备份库
7. 在备份文件weibo.sql查看binlog和pos值
8. 从库设置从这个日志点同步，并启动
可以看到IO和SQL线程均为YES，说明主从配置成功。
9. 从库查看weibo库里面的表
发现刚才模拟创建的test_tb表已经同步过来！
二、xtrabackup方式(推荐)
在上面配置基础上做实验，先删除掉从库配置：
此时，从库现在和新装的一样，继续前进！
1. 主库使用xtrabackup备份
# innobackupex --user=root --password=123 ./
生成一个以时间为命名的备份目录：2015-07-01_16-49-43
2. 把备份目录拷贝到从库上
# scp -r 2015-07-01_16-49-43 root@192.168.18.214:/home/root
3. 从库上把MySQL服务停掉，删除datadir目录，将备份目录重命名为datadir目录
4. 在主库创建test_tb2表，模拟数据库新增数据
mysql> create table test_tb2(idint,name varchar(30));
5. 从备份目录中xtrabackup_info文件获取到binlog和pos位置
6. 从库设置从这个日志点同步，并启动
可以看到IO和SQL线程均为YES，说明主从配置成功。
9. 从库查看weibo库里面的表
1783
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
