共计 3742 个字符，预计需要花费 10 分钟才能阅读完成。
这篇文章主要讲解了“Mysql 主从复制搭建过程”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“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 主从复制搭建过程这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
