MYSQL M-S主从架构

小编因重新迷恋文玩佛珠，拖更数日，今日献上纯干货mysql M-S架构（异步复制）以赎我偷懒玩心之罪。

M-S是mysql当中最基础，使用最多的架构。其增加了数据库的健壮性，防止了单点故障的发生，并且可以在程序端控制连接，提供进行读写分离的必备条件。mysql的架构变化多端。横向扩展能力极强，M-S基础架构为之后强大架构提供了基础，我们这里讲的是异步复制。

原理结构

mysql M-S架构体系图如下

MYSQL M-S在主服务器有一个工作线程：IO thread

在从服务器有两个工作线程：IO thread 和SQL thread

MYSQL同步是通过将MASTER服务器的binlog日志通过主服务器的IO thread发送到SLAVE服务器。SLAVE服务器通过IO thread将传来的binlog日志应用到Relay log（中继日志）当中。而SQL thread将读取中继日志将其应用到数据库当中，应用完成之后中继日志将会自动删除。

实验搭建

设备信息：

192.168.1.99 master

192.168.1.20 slave

MYSQL 版本均为 5.6.16

Slave端是master端的完全复制，这里我一定强调，因为会在后面因此无法同步成功。

master：

首先我们创建一个同步使用的用户，这是一个连接账户，该账户 的创建规则和其他账户有所区别

grant replication slave on *.* to 'connect'@'192.168.1.20' identified by 'mysql';

这里一定要刷新权限flush privileges;

在master端插入几条数据。

为了初始化slave端数据库，此时我们将主库通过mysqldump做一次全备，这里使用master-data=2的原因是，注释掉导出的文件中包含的change master to的语句，我们希望在slave端配置初始化是由我们自己手动去做，所以使用master-data=2,而master-data=1是默认的，默认导出文件包含change master to 语句

打开这个备份文件，我们记录下这条备份文件的信息。

将其发送到slave端

slave:

在slave端我们将传来的全备恢复到slave database当中，我们查到这个表的数据已经到了slave当中，之后进入数据库配置slave同步信息，这里要配置的信息一定要和我们同步的日志相匹配：

我们对slave端database开启slave模式，这个动作将会触发slave端创建IO thread 和 sql thread ,IO thread 要求master向slave推binlog。

这里我提前说一下，虽然开启了slave状态，前面的初始化工作也已经完成，但是，现在同步一定是没有成功的，因为我在之前说过，我的slave是由master复制而来，他们俩的参数文件使用的是一样的，我们可以查看一下slave端状态。

slave的SQL thread已经能够开启，但是io thread没有开启，我们查看下报错原因。

这个报错是因为我们两端参数文件使用的是一样的，然而两端的server id也相同，这样就没有办法识别谁是主，谁是从。将slave端的参数文件中server id 修改成2

重启slave，查看状态。

io thread 和 sql thread 全都正常开启。我们在master插入一条数据，看能否在slave端看到。

MASTER

SLAVE

好的，同步成功~~~~

THAT'S ALL

BY CUI PEACE