这篇文章主要讲解了“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主从复制搭建过程这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
