mysql AB复制搭建以及常见故障排查

mysqlAB复制搭建以及常见故障排查MySQL主从复制(Master-Slave)也叫AB复制，Mysql作为目前世界上使用最广泛的免费数据库，相信所..

常见故障总结以及处理方法

1.可能是/usr/local/mysql/data/***.pid文件没有写的权限
解决方法 ：给予权限，执行 “chown -R mysql:mysql /var/data” “chmod -R 755 /usr/local/mysql/data”  然后重新启动mysqld！

2.可能进程里已经存在mysql进程
解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9  进程号”杀死，然后重新启动mysqld！

3.可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。
解决方法：去mysql的数据目录/data看看，如果存在mysql-bin.index，就赶快把它删除掉吧，它就是罪魁祸首了。本人就是使用第三条方法解决的 ！?p=186

4.mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]节下有没有指定数据目录(datadir)。
解决方法：请在[mysqld]下设置这一行：datadir = /usr/local/mysql/data

5.skip-federated字段问题
解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。
###
主要是从服务器会出现错误
由于一些错误操作或者中途改变了master，而导致CHANGE MASTER命令后SLAVE服务无法启动,系统报错如下:
Could not initialize master info structure; more error messages can be found in the MySQL error log.
无法初始化master info结构;MySQL错误日志记录了更详细的错误信息.
两种解决方法:
第一种：
1.查看MySQL错误日志,查看原因.
如:同步的上一个Position是多少.
很多情况下无法启动服务是由于mysql识别的同步始终停留在上一个Position上.
2.查看master.info和relay-log.info
master.info 记录MASTER相关信息
mysql-bin.000030
391156558
192.168.1.1
user_rep
rep123
3306
60
0
relay-log.info 记录当前同步日志信息
235
mysql-bin.000030
391156558
3.停止myslq服务,删除master.info和relay-log.info
# service mysql stop
/data/datafile/ # rm master.info
/data/datafile/ # rm relay-log.info
4.启动mysql服务
# service mysql start
5.重新CHANGE MASTER,重新启动SLAVE服务.
问题应该就可以解决了.
第二种方法比较简单，也常用
mysql> slave stop;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> reset slave;
Query OK, 0 rows affected,(0.00 sec)
#############
主从mysql不同步首先在Master上用
show processlist;   查看下进程是否Sleep太多。发现很正常。
show master status; 也正常。
再跑到Slave上查看
show slave status;
错误提示：
Error 'Duplicate entry '1' for key 1' on query. Default database: 'movivi1'. Query: 'INSERT INTO `v1vid0_user_samename` VALUES(null,1,'123','11','4545','123')'
Slave_SQL_Running 为 NO
Seconds_Behind_Master 为 (null)
可见是Slave不同步
解决：
stop slave;
set global sql_slave_skip_counter =1 ;
start slave;

########
1.网络的延迟
由于mysql主从复制是基于binlog的一种异步复制，通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
2.主从两台机器的负载不一致
由于mysql主从复制是主上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。
3.max_allowed_packet设置不一致
主上面设置的max_allowed_packet比从大，当一个大的sql语句，能在主上面执行完毕，从上面设置过小，无法执行，导致的主从不一致。
4.key自增键开始的键值跟自增步长设置不一致引起的主从不一致。
5.mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。
6.mysql本身的bug引起的主从不同步。
7.版本不一致，特别是高版本是主，低版本为从的情况下，主上面支持的功能，从上面不支持该功能。
以上是我遇到的一些主从不同步的情况。或许还有其他的一些不同步的情况，请说出你所遇到的主从不一致的情况。
基于以上情况，先保证max_allowed_packet，自增键开始点和增长点设置一致，再者牺牲部分性能在主上面sync开启_binlog，对于采用innodb的库，推荐配置下面的内容
1.innodb_flush_logs_at_trx_commit = 1
2.innodb-support_xa = 1 # Mysql 5.0 以上
3.innodb_safe_binlog      # Mysql 4.0
同时在从上面推荐加入下面两个参数
1.skip_slave_start
2.read_only
重新CHANGE MASTER,重新启动SLAVE服务.这样就搞定了O(∩_∩)O

本文出自 “windy丶寒” 博客，请务必保留此出处