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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180426G0K3O400?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券