1、简介
写这篇文章是网上找到的相关主从同步的都不够完全，本人第一次搭建主从同步，完全看着网上的文章来搭建的，结果你懂的，踩了很多坑。所以特地把踩到的坑写出来，新手切勿直接布置到正式环境，请于测试环境测试完成再布置与正式环境。本文仅供自己或者有需要的参考，仅供参考。
2、环境说明
为了更贴切于实际环境，本人直接采用的真机，壕吧，这里不采用真实IP。下文全部采用IPXXX代替。
一台阿里云ECS（1G1核）：IPC193
一台阿里云轻量应用服务器（2G1核）： IPC248
系统全装的CentOS 7.4 64位
3、数据库版本
安装包下载地址：http://cdn.mysql.com/archives/mysql-5.6/mysql-5.6.26-linux-glibc2.5-x86_64.tar.gz
4、数据库的安装就不再本文说了，开始搞事情吧。
4.1 安装
安装数据库，我这里是安装在/usr/local/mysql的
4.2 配置
注意：二进制日志必须开启，因为数据的同步实质上就是其他的MySQL数据库服务器将这个数据变更的二进制日志在本机上再执行一遍。
vim /usr/local/mysql/my.cnf
在页面最下方添加 log-bin=mysql-bin 开启二进制日志
C248 为主数据库服务器
C129 为从数据库服务器
4.3 开始搭建主从复制
主数据库C248需要做的操作
在主数据库创建一个从数据库能够登录的账号
#创建具有复制权限的用户
mysql>GRANT REPLICATION SLAVE ON *.* TO '账号名'@'从服务器IP地址' IDENTIFIED BY '密码';
#mysql 新设置用户或更改密码后需用flush privileges刷新MySQL的系统权限相关表，否则会出现拒绝访问
mysql>FLUSH PRIVILEGES;
创建测试账号：c193slave ，测试密码是c193slave@123456
查看主数据库保存的二进制文件名与位置
mysql>SHOW MASTER STATUS;
上图显示的File 对应的binlog.000004 跟Position对应的102219就是从服务器需要用到的，
我这个数据库并不是新数据库，所以Position不是从0开始的，默认File是从000001开始。
从数据库C129需要做的操作
#####CHANGE MASTER TO MASTER_HOST='主数据库IP地址',
MASTER_USER='刚才在主数据库添加的账号',
MASTER_PASSWORD='数据库密码',
MASTER_LOG_FILE='上图对应的File下面的文件名字',
MASTER_LOG_POS=上图图片对应的Position下面数字;
mysql>CHANGE MASTER TO MASTER_HOST='C248',
MASTER_USER='c193slave',
MASTER_PASSWORD='c193slave@123456',
MASTER_LOG_FILE='binlog.000004',
MASTER_LOG_POS=102219;
mysql>START SLAVE; #开启复制
mysql>SHOW SLAVE STATUSG #查看主从复制是否配置成功
如上图的主数据库IP，账号，等等如果都对应着说明配置成功
5、查看主从复制执行进程
（从服务器）mysql> show processlist; #查看正在执行中的进程，如果出现下图两条则说明从数据库正常
（主服务器）mysql> show processlist; #查看正在执行中的进程，如果出现下图一条则说明主服务器正常
主从复制到此就完成了。
6、在这说一下遇到的坑
白天主从是正常的，但是第二天发现从服务器的position与主服务器并不一致，手动修改了下主服务器数据库，发现从服务器并没有更新，说明主从不正常了。
使用show processlist;查看从数据库线程时，从数据库线程还在，查看主数据库线程时，进程已丢失。反正不知道啥原因丢失了。
经检查，知道了一个叫心跳的东西
在 MySQL 主从复制时，有时候会碰到这样的故障：
在 Slave 上 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes，
Slave_SQL_Running_State 显示 Slave has read all relay log; waiting for the slave I/O thread to update it ，看起来状态都正常，但实际却滞后于主，Master_Log_File 和 Read_Master_Log_Pos 也不是实际主上最新的位置。
一种可能是 Master 上的 binlog dump 线程挂了（我就是线程挂了）。但有时候，在 Master 上检查也是完全正常的。那 Slave 的延误又是怎么造成的呢？
在 MySQL 的复制协议里，由 Slave 发送一个 COM_BINLOG_DUMP 命令后，就完全由 Master 来推送数据，Master、Slave 之间不再需要交互。如果 Master 没有更新，也就不会有数据流，Slave 就不会收到任何数据包。但是如果由于某种原因造成 Master 无法把数据发送到 Slave ，比如发生过网络故障或其他原因导致 Master 上的 TCP 连接丢失，由于 TCP 协议的特性，Slave 没有机会得到通知，所以也没法知道收不到数据是因为 Master 本来就没有更新呢还是由于出了故障。
好在 MySQL 5.5 开始增加了一个复制心跳的功能。
（C129）mysql> stop slave; #关闭主从
（C129）mysql> change master to master_heartbeat_period = 10; #修改心跳为10秒一次
（C129）mysql> set global slave_net_timeout = 25; #修改超时时间
（C129）mysql> start slave; #再次开启主从复制
（C129）mysql> show status like 'slave%';
再次测试主从，数据同步在正常。