MySQL主从复制（实现项目的读写分离）

gzu_01

已于 2022-08-12 09:44:15 修改

阅读量516

点赞数

于 2022-08-11 19:23:36 首次发布

本文链接：https://blog.csdn.net/gzu_01/article/details/126290717

版权

3.1首先需要有两台虚拟机（我的环境是Linux--centos7，如果实体Linux服务器或者云服务器也可）

3.2主库配置

3.3从库配置（在第二台虚拟机orlinux服务器操作）

1.前言

读写分离：

1.1原理：

让主数据库（master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操作。

1.2诞生原理

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，仅仅接收来自第一台服务器的备份数据（注意，不同数据库产品，第一台数据库服务器，向第二台数据库服务器发送备份数据的方式不同）。当第一台数据库崩溃后，第二台数据库服务器，可以立即上线来代替第一台数据库服务器，并且，在第一台数据库服务器崩溃后，宝贵的数据，依然会存在于第二台数据库服务器里（根据目前业界的备份数据发送方式来看，当第一台数据库崩溃后，第一台数据库里的仍然会有少量的新数据，没能来得及被发送到第二台数据库服务器，所以，这部分数据就丢失了）

一般来说，为了配置方便，以及稳定性，这两台数据库服务器，都用的是相同的配置（思考一下，如果两台服务器的配置不同，会导致什么结果）。

从数据库的基本业务来看，数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作，如果是双机热备的环境中做，一台机器做了这三个操作的某一个之后，需要立即将这个操作，同步到另一台服务器上。单向的同步，不复杂。但如果两台机器都需要向对方进行同步，那逻辑就非常复杂，而且还会大大降低性能。（从保证ACID特性的角度，思考一下为什么双向同步会非常复杂且低性能？而单向同步却不会？）出于这个原因，第二台备用的服务器，就只做了查询操作。进一步，为了降低第一台服务器的压力，干脆就把查询操作全部丢给第二台数据库服务器去做，第一台数据库服务器就只做增删改了

到这一步，就实现了所谓的读写分离。这样做，缺点也非常明显了。本来第二台数据库服务器，是用来做热备的，它就应该在一个压力非常小的环境下，保证运行的稳定性。而读写分离，却增加了它的压力，也就增加了不稳定性。因此，读写分离，实质上是一个在资金比较缺乏，但又需要保证数据安全的需求下，在双机热备方案上，做出的一种折中的扩展方案。

1.3MySQL的主从复制--简介

mysql主从复制是一个异步过程，底层基于mysql二进制日志功能。即slave从库从另一台 master 主库进行日志的复制，然后再解析日志并应用到自身。最终实现，从库数据与主库数据保持一致 mysql主从复制是自带功能，无需借助第三方工具。

1.4MySQL的主从复制--原理

MySQL支持的复制类型
（1）基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。但是必须开启二进制日志功能；
（2）基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍；
（3）混合类型的复制：默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制；

复制的工作过程

MySQL复制的工作过程详细介绍：
1.在每个事物更新数据完成之前，Master在二进制日志记录这些变化。写入二进制日志完成后，Master通知存储引擎提交事务；
2.Slave将Master的Binary log（二进制日志）复制到其Relay log（中继日志）。首先Slave开始一个工作进程——I/O线程，I/O线程在Master上打开一个普通的连接，然后开始Binlog dump process（二进制日志转储过程）。Binlog dump process从Master的二进制日志中读取事件，如果已经跟上Master，它就会睡眠并等待Master产生新的事件。I/O线程将这些时间写入中继日志；
3.SQL slave thread（SQL从线程）处理该过程的最后一步。SQL线程从中继日志中读取事件，并重放其中的事件而更新Slave的数据，使其与Master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小；

复制过程有一个很重要的限制，即复制在Slave上是串行化的，也就是说Master上的并行更新操作不能在Slave上并行操作。

原文链接：https://blog.csdn.net/qxdbb/article/details/124054324

在这里插入图片描述

2.MySQL主从复制的实现

2.1基本步骤

1.master将改变记录到二进制日志

2.slave将master的binary log拷贝到自己的中继日志 relay log

3.slave重做中继日志的事件将改变应用到自己的数据库中

3.配置主库master与从库slave

3.1首先需要有两台虚拟机（我的环境是Linux--centos7，如果实体Linux服务器或者云服务器也可）

主库（ip：192.168.193.150）

从库（ip：192.168.193.151）

3.2主库配置

1.修改mysql数据库的配置文件配置服务器id（唯一）

vim /etc/my.cnf

2.重启mysql服务

systemctl restart mysqld

3.主库创建用户

mysql>grant replication slave on . to 'zc'@'%' identified by 'Zc@123456';

4.登录MySQL 执行查询master信息

mysql>show master status;

注意：本sql语句查看的是master的状态执行完后无需执行任何操作

3.3从库配置（在第二台虚拟机orlinux服务器操作）

1.修改配置文件配置服务器id（唯一）

[root@localhost ~]# vim /etc/my.cnf

2.重启mysql服务

systemctl restart mysqld

3.在mysql中执行以下sql

file 与pos值都从其中而来

change master to master_host='192.168.193.150',master_user='zc',master_password='Zc@123456',master_log_file='mysql-bin.000001',master_log_pos=435;

start slave;

4.查看从库状态

show slave status;

4.可能遇到的问题

4.1克隆的虚拟机需要修改数据库uuid

如果是使用虚拟机对cento7克隆的话，除了需要修改虚拟机本身的id外，还需要修改数据库的uuid，因为克隆还会将数据库的所有配置都克隆

1.使用uuid函数生成一个新uuid

mysql> select uuid();

2.查看数据源位置

show variables like 'datadir';

3.修改配置文件

[root@localhost ~]# vim /var/lib/mysql/auto.cnf

修改前

修改后

4.重启服务

service mysqld restart

5.测试mysql主从复制

主库创建一个表

从库也出现了这个表（如果没出现可以刷新一下）

查询走的是从库

修改update走的是主库

6.总结

主从复制：
主从复制核心部分就是两个日志三个线程(高版本的mvsal以及异步复制、半同步复制、全同步复制三种模式)
二个日志:二进制日志和中继日志
三个线程:master的dump和slave的I/O、SQL
主要原理:master将数据保存在二进制日志中，I/O向dump发出同步请求，dump把数据发送给I/O线程，I/O写入本地的中继日志
SOL线程读取本地中继日志数据，同步到自己数据库中，完成同步
、半同步复制、全同步复制三种模式)
二个日志:二进制日志和中继日志
三个线程:master的dump和slave的I/O、SQL
主要原理:master将数据保存在二进制日志中，I/0向dump发出同步请求，dump把数据发送给I/0线程，I/O写入本地的中继日志
SOL线程读取本地中继日志数据，同步到自己数据库中，完成同步
原文链接：https://blog.csdn.net/qxdbb/article/details/124054324