Mysql主从复制搭建过程
这篇文章主要讲解了“MySQL主从复制搭建过程”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Mysql主从复制搭建过程”吧!
创新互联公司-成都网站建设公司,专注网站设计、网站制作、网站营销推广,域名注册,网页空间,网站托管运营有关企业网站制作方案、改版、费用等问题,请联系创新互联公司。
一、相关概念
mysql主从复制的官方概念可自行百度,在这里谈一下个人理解以及它和DataGuard的区别(理解有误请指正)。
主库通过mysql引擎将master库中执行的所有sql语句转储到一个二进制log文件中(binlog),然后将这个binlog通过网络传输到slave端,然后解析binlog中的语句成sql语句,再在备库中执行,由此可见,mysql的主从复制功能是基于sql语句逻辑的传输方法,所以在配置mysql主从复制的过程中,参数一定要优化得当,否则就会出现由于参数限制的问题出现各种各样的报错。。。
-和DataGuard的比较
DataGuard(太懒,下面简称DG)中文名称叫做数据卫士,是oracle提供的一种容灾解决方案。DG一般称主库为primary(对应mysql中的master),备库叫standby(对应mysql中的slave),它有三种模式,分别是物理standby、逻辑standby和快照standby,我们一般采用物理standby的配置方法,优点是配置简单,不易出错,对参数方面优化较少,是通过将归档日志通过网络传输到备库,再通过block-to-block(块对块的复制)的方式在备库端进行应用(注意:这里区别于mysql的是,并不涉及sql语句,采用数据块复制的方法呈现的),优点是维护简单,不涉及sql语句的逻辑,适用于绝大多数生产环境。(mysql这方面和DG相比还是略逊一筹,好了废话不多说,下面开始配置)
二、试验环境(其实这是个真实的生产环境,已脱敏)
平台:Hyper-V
OS:CentOS 6.5
DB: Mysql 5.6
三、开始搭建
前提条件
-操作系统以及数据库安装完毕
-版本一致
-关闭iptables、selinux
修改master配置文件
-主库
vi /etc/my.cnf
[mysqld]
log-bin=mysql-bin //开启binlog功能
server-id=1 //service-id 主从要区别开
-从库
vi /etc/my.cnf
[mysqld]
log-bin=mysql-bin //开启binlog功能
server-id=2 //service-id 主从要区别开
建立同步账号并授权slave
mysql>GRANT REPLICATION SLAVE ON *.* to 'mysync'@'%' identified by 'mysync';
锁定主库
mysql>flush tables with read lock;
确定master库状态值
mysql>show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000039 | 308 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
注:执行完此步骤后不要再操作主服务器MYSQL,防止主服务器状态值变化
配置从库slave
mysql>change master to
master_host='xx.xx.xx.xx',master_user='mysync',master_password='mysync',master_log_file='mysql-bin.000089',master_log_pos=592700228;
Mysql>start slave; //启动从服务器复制功能
解锁主库
mysql>unlock
tables;
检查主从复制状态
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.9.40.70
Master_User: mysync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000089
Read_Master_Log_Pos: 182083231
Relay_Log_File: mysqld-relay-bin.000100
Relay_Log_Pos: 182083394
Relay_Master_Log_File: mysql-bin.000089
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
……………………………………………………
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
注:标红的IO和SQL状态均为yes,主从配置完成!
四、Troubleshooting
在实际环境过程中,可能会出现各种各样的异常,在这里就不模拟异常了(实在无法模拟),主要讨论处理方法。
一般主从出现异常之后通过show slave status\G可以看到是IO的问题还是SQL执行的问题,如果IO为NO,请检查主从之间的网络是否存在异常或者防火墙是否开启。
如果是SQL选项为NO,那就要具体问题具体分析了,在Last_SQL_Error中会提示哪个sql语句卡主,注意。。。这里的坑比较多,如果是参数问题导致卡sql,那么优化指定参数文件之后重启mysql服务应该就没有问题了,如果从库有写入导致不一致的情况只能跳过错误了。曾经在某项目遇到过执行一个表的update一直被卡,无论怎么跳过也不行,参数也没有问题,被坑了好久之后发现原来这个库连着一个备用的应急环境,里面的job会每隔一段时间进行更新,由于环境不同导致初始值不同所以update必然失败,但如果是block-to-block的复制方式就会屏蔽这个错误。解决方法:将这个库的应用服务停掉就ok了。
-处理主从报错的通用方法:
start slave;
set global
sql_slave_skip_counter=1;
start slave;
下面给大家贴一下主从复制报错然后自动发邮件提醒的脚本
#!/bin/bash
array=($(mysql -u root -pxxxx -e "show slave status\G"|grep "Running" |awk '{print $2}'))
if [ "${array[0]}" == "Yes" ] || [ "${array[1]}" == "Yes" ]
then
echo "slave is OK" >/var/lib/mysql/backup/script/sync_log.tmp
else
echo "mysql主从复制出错" >/var/lib/mysql/backup/script/sync_log.tmp
mailx -s "mysql_sync_check" tsl-baijin0829@tasly.com < /var/lib/mysql/backup/script/sync_log.tmp
fi
感谢各位的阅读,以上就是“Mysql主从复制搭建过程”的内容了,经过本文的学习后,相信大家对Mysql主从复制搭建过程这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
名称栏目:Mysql主从复制搭建过程
转载注明:http://myzitong.com/article/pjhgpc.html