460-MySQL(主从复制原理)

你的名字 2022-09-07 09:13 209阅读 0赞

## MySQL集群 ##

在实际生产环境中，如果对mysql数据库的读和写都在一台数据库服务器中操作，无论是在安全性、高可用性，还是高并发等各个方面都是不能满足实际需求的，一般要通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。  
**1、数据备份 - 热备份&容灾&高可用  
2、读写分离，支持更大的并发（有了主从复制，才可以实现读写分离）**  
读写分离：我们读操作多，写操作少。主库专门写操作，数据的更新，通过binlog同步到从库，客户端的查询请求最终映射到从库上，从库读操作。1主2从。提高后端并发能力和高可用容灾。

**服务器中间件：消息队列，缓存，zk。  
MySQL中间件：Mycat读写分离配置**

## 主从复制 ##

读写分离就是基于主从复制来实现的。  
**原理介绍**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]  
**主从就是角色关系**。主库用来进行增删改查，从库用来数据的同步和备份。  
主库（master）从库(slave）  
**主库**对外提供数据的增删改查服务。主库中涉及到数据的修改都会写binary log。  
**从库**通过专门的线程从主库里面的binlog（二进制日志），跟数据权限，表结构相关的修改同步到从库里面。相当于就是后台在主库的所有修改通过主从复制机制体现在从库。好处是可以做一个数据的备份，通过mysql中间件mycat甚至是热备份，容灾，主库挂了，由中间件代理mycat自动把服务的请求映射到从库，进行对外提供服务，**这就是容灾，高可用。**

上图中的binlog，我们没有主从复制，也是会写binlog，只不过主从复制就是通过binlog来复制的，从库专门有一个I/O线程：专门读取接收主库发过来的binlog的内容，并写到中继日志relay log，**相当于做缓冲**。并不是把主库的binlog读过来直接执行，这样的不好之处是：主库的binlog的内容可能很多，而从库接收到binlog的内容执行起来比较慢，从库的更新速度和主库相差越来越大。  
从库还会写一个线程：SQL线程，专门从中继日志读取相应的操作，跟放电影一样，全部的SQL都执行一下，这样，从库的内容和主库的内容同步更新了。  
主库master服务器创建一个binlog转储线程，将二进制日志内容发送到从服务器。

**主从复制的流程**：

**两个日志（binlog二进制日志&relay log日志）和三个线程（master的一个线程和slave的二个线程）**

**1、主库的更新操作写入binlog二进制日志中。**  
主库要打开二进制日志。  
**2、master服务器创建一个binlog转储线程，将二进制日志内容发送到从服务器。**  
3、slave机器执行**START SLAVE**命令会在从服务器创建一个IO线程，接收master的binary log复制到其中继日志（内存上放着，内存放不了，会在磁盘上二级存储）。  
从线程相当于客户端，主动来连主库的。  
**首先slave开始一个工作线程（I/O线程），I/O线程在master上打开一个普通的连接**，然后开始 binlog dump process，binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志。  
**4、sql slave thread（sql从线程）处理该过程的最后一步**，sql线程从中继日志中读取事件，并重放其中的事件而更新slave机器的数据，使其与master的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。

## 我们先看一下结果再进行配置 ##

**linux作为一个主库。  
Windows上的mysql server作为从库。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]  
从配置主从复制之后，两个机器上的数据才是同步的。配置之前，就是什么都不变，都是原来的库表。  
**主往从同。**

**配置好之后**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]  
**现在我们在linux的mysql上对这个表插入数据**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]  
同步了哦！进行了主从复制。  
现在linux上的mysql（主）drop 表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]  
把更改的SQL都记录在binlog里面了。

主库产生binlog dump，专门把二进制的内容发送给从库  
在主库上查看  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 6]  
现在，主库上的binlog dump线程已经把主库上的所有二进制数据都发送到从库上了，阻塞睡眠状态，等待二进制日志的更新，把事件发送到从库。  
我们在从库上看看  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 7]  
增加了2个线程。1 是 I/O线程，等主库发送过来的更新的事件。  
1 和 2都在waiting，等待，已经读到最新了，等待 relay log的更新。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70]: /images/20220829/f29ad6a42c034c628f8221bf9798af1b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 1]: /images/20220829/8889f45bb40641bab8fe524b62a91289.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 2]: /images/20220829/62ca24b0e65b4dfc913ea86d6246da5a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 3]: /images/20220829/acb7d113730248be94263890dfc5b96e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 4]: /images/20220829/2d3614c51c174050bd12a5c2f89ad890.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 5]: /images/20220829/1d3f02cdaa3a41de8a5c5d1495890135.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 6]: /images/20220829/377404de9bf6474d90b63dddb6974e3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xJTlpFWVU2NjY_size_16_color_FFFFFF_t_70 7]: /images/20220829/7bd011b0bcec41c5b900ff6d21164e65.png