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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

科技小能手 2017-11-14 18:04:00 浏览835
展开阅读全文

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

MySQL主从复制(Master-Slave)也叫AB复制,Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过。但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面。因此,一般来说都是通过主从复制(Master-Slave)的方式来同步数据,再通过读写分离(MySQL-Proxy)来提升数据库的并发负载能力这样的方案来进行部署与实施的。

如下图所示:

wKioL1MDErPyUeK1AAO22EHGl5I963.jpg

拓扑图画的不是很好,大家见谅哈;今天我们来学习下如何搭建mysql的AB复制,其实呢很简单,大家不要被它的表面所迷惑。

首先呢我先给大家描述下环境:

环境描述:

mysql主服务器:系统rhel5.5;192.168.1.10;mysql呢是我用本机yum源安装的,数据库里面什么东西都没有。

mysql从服务器:系统rhel5.5;192.168.1.11;这个机器的mysql跟上面的一样。

好了,环境描述完毕,下面给大家讲解下步骤。

一、在主服务器上操作

1.修改/etc/my.cnf

添加log-bin=mysql-bin     //启用二进制日志

server-id=1              //数据库ID号,1时表示为Master,其中master_id必须为1231之间的一个正整数值,每个同步服务器都必须设定一个唯一的编号,否则同步就不能正常运行了;

2.启动mysql服务

/etc/init.d/mysqld start

3.然后登录进去mysql数据库

mysql -u root

授权给从mysql数据库服务器192.168.1.11;

mysql> GRANT REPLICATION SLAVE ON *.* to 'ha'@'192.168.1.11'identified by ‘password’;

wKioL1MDFZ6ws-iiAABfJYJZBDY128.jpg

查询主数据库状态

wKiom1MDFgzQWWRrAACwwLtRwzA644.jpg

记录下 FILE  Position 的值,在后面进行从服务器操作的时候需要用到。

二、配置从服务器

跟上面一样也是先修改下/etc/my.cnf

添加log-bin=mysql-bin     //启用二进制日志

server-id=1              //数据库ID号,1时表示为Master,其中master_id必须为1231之间的一个正整数值,每个同步服务器都必须设定一个唯一的编号,否则同步就不能正常运行了;

2.启动mysql服务

/etc/init.d/mysqld start

3.然后登录进去mysql数据库

mysql -u root

4.执行同步sql语句然后启动slave同步进程

wKioL1MDFoyQGXQeAADOVbTNxS0635.jpg

5.主从同步检查

wKiom1MDFv7xzpWKAAJTgdF2njo445.jpg

其中Slave_IO_Running Slave_SQL_Running 的值都必须为YES,才表明状态正常。

如果主服务器已经存在应用数据,则在进行主从复制时,需要做以下处理:
(1)
主数据库进行锁表操作,不让数据再进行写入动作
mysql> FLUSH TABLES WITH READ LOCK;

(2)查看主数据库状态
mysql> show master status;

(3)记录下 FILE  Position 的值。
将主服务器的数据文件(整个/opt/mysql/data目录)复制到从服务器,建议通过tar归档压缩后再传到从服务器解压。

(4)取消主数据库锁定
mysql> UNLOCK TABLES

三、验证主从AB复制效果
在主服务器上创建一个库

wKiom1MDF_ezEZDrAABZ6YfWqLE188.jpg

在从服务器上查看下

wKiom1MDGDvDmZO8AACB_FAadXs797.jpg

由此,整个MySQL主从复制的过程就完成了,接下来,我们进行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,就赶快把它删除掉吧,它就是罪魁祸首了。本人就是使用第三条方法解决的 !http://blog.rekfan.com/?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


本文转自Devin 51CTO博客,原文链接:http://blog.51cto.com/devingeng/1360162


网友评论

登录后评论
0/500
评论
科技小能手
+ 关注