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 STATUS\G #查看主從復制是否配置成功
如上圖的主數據庫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%';
再次測試主從，數據同步在正常。