MySQL主从复制的实现过程

一、什么是主从复制

　　将主数据库中的DDL和DML操作通过二进制日志传输到从数据库上，然后将这些日志重新执行（重做）；从而使得从数据库的数据与主数据库保持一致。

 

基本原理：

　　MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。

 

　　MySQL复制是基于主服务器在二进制日志中跟踪所有对数据库的更改。因此，要进行复制，必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器已经记录到日志的数据。

 

　　当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，并在本机上执行相同的更新。然后封锁并等待主服务器通知新的更新。从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新。

 

二、主从复制的作用

　　1、主数据库出现问题，可以切换到从数据库。

　　2、可以进行数据库层面的读写分离。

　　3、可以在从数据库上进行日常备份。

 三、复制过程

Binary log：主数据库的二进制日志。

Relay log：从服务器的中继日志。

第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。

第二步：salve开启一个I/O Thread，该线程在master打开一个普通连接，主要工作是binlog dump process。如果读取的进度已经跟上了master，就进入睡眠状态并等待master产生新的事件。I/O线程最终的目的是将这些事件写入到中继日志中。

第三步：SQL Thread会读取中继日志，并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。

四、主从复制的具体操作

我是在同一个windows上不同的路径下安装两个msyql实例。建议这里主从两个mysql的安装版本一致，尽管我自己的是不一致的。

 

1、分别修改主从数据库的配置文件my.ini

master

3306是mysql默认端口号，这里master实例中可以不用修改；server-id用来指定唯一id，不同的mysql实例不重复即可；binlog-do-db指定需要复制的数据库；log-bin用来开启二进制日志文件。

 

salve

 

由于主从数据库待会儿都是在通一台电脑上运行，所以端口需要设置成不一样，这里是3307

replicate-do-db：需要同步的数据库名称，与master上的配置保持一致。

2、在master上创建一个专门用于复制的账户：weidai/123456

这个新增的账户可以在表mysql.user中进行查询：

 

我第一次操作的时候，到这里就完成了这个账号的创建，但是到真正复制的时候，却发现复制没有成功，排查错误的时候发现master生成的binlong没有问题，然后查看slave的状态：

 

在结尾处有这样一行错误：

 

使用weidai这个账号无法连接到master，所以应该是没有获取到master的binlog，导致中继日志无法生成。

 

我反复检查了账号和密码都没有发现问题，然后查找相关资料，才发现是因为在master创建新用户的时候少了一步操作：

新设置用户或更改密码后需用flush privileges刷新MySQL的系统权限相关表，否则会出现拒绝访问。

 

这就是出现前面错误的原因。另外还有一种办法是重新启动mysql服务器，来使新设置生效。

 

 

3、获取主数据库中此刻数据的位置，主要用于从数据启动后，复制数据的起始位置，但是在获取这个状态值之前，主数据库就不能再有数据的修改操作，所以需要先设置读锁定有效

 

 

4、主库进行数据备份，备份的手段有很多种，这里不展开介绍，可以参考我上一篇文章，备份结束后可以释放读锁，主库就可以进行写操作

 

5、启动从数据库，对刚才备份的数据进行还原，这个时候主从数据库在备份那个时间点的数据是一致的。

 

6、在从数据库上进行复制行为的相关配置

 

7、这个时候配置完成，但是从数据库还不能进行同步，需要启动slave线程

 

8、在master中创建表和新增数据，在slave中观察：

可以看出，我在master中进行的操作，都能在slave中体现出来，这个时候slave就如同是master的镜子一样。

 

 

五、主从同步状态解读

在slave上使用命令进行查看：

 

由于排版太过于难看，我整理如下：

  • Slave_IO_STATE:Waiting for master to send event

  • Master_host:127.0.0.1

  • Master_user:weidai

  • Master_port:3306

  • connnect_retry:60

  • Master_log_file:mysql-bin.000005

  • Read_Master_log_pos:1662

  • Relay_log_file:AE6Z*****-relay-bin.000002

  • Relay_log_pos:1415

  • Slave_IO_Running:yes

  • Slave_SQL_Running:yes

     

 

Slave_IO_Running:yes

Slave_SQL_Running:yes

这两个线程前面有提到，是slave上参与复制过程中两个很重要的线程。YES表示正常，NO表示异常。

        Slave_IO线程主要是将master上的binlong日志内容复制到slave的中继日志中（Relay_log），一般出现问题的概率不大， 出现问题大多数是因为权限或者网络等问题，导致连接不上master。如同前面提到的那个错误。

        Slave_SQL线程负责将中继日志中的SQL执行一遍，相对来说出错的概率大些。如有人手动的在从库中插入一些记录，导致主从同步的时候出现主键冲突。

        Slave_IO_STATE:Waiting for master to send event—这个状态表示中继日志同步完成，等待master有新的事件产生。

 

转自：微信公众号-java知音

posted @ 2019-04-08 15:07  Co~Co  阅读(26462)  评论(0)  编辑  收藏  举报