mysql 数据库主从同步

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%';

　　再次测试主从，数据同步在正常。