Linux下搭建Mysql主从复制详细步骤（Mysql版本5.7.28）

目录

前言

1.主从复制简介

2.主从复制的原理

3.主从复制作用以及优缺点

3.1 主要作用

3.2 主从复制优点

3.3 主从复制缺点

4.主从复制搭建

4.1服务器说明

4.2 master主库配置

4.2.1修改配置文件my.cnf

4.2.2 重启服务与查看是否生效

4.2.3 建立主从账号

4.2.4 查看主库信息

4.3 从库配置

4.3.1 修该配置文件

4.3.2 重启服务查看

4.3.3 配置从库参数

4.4 测试主从同步

前言

本本将跟大家一起搭建Mysql的主从复制，相信大家对主从复制这个词语都不会陌生，不过有很多小伙伴或许还未搭建一台属于自己的主从复制的MySQL数据库，希望本文可以带来一些帮助，如果你还来没有安装mysql，请看博主的这篇Mysql-5.7.28安装教程

1.主从复制简介

        在实际的生产中，为了解决Mysql的单点故障已经提高MySQL的整体服务性能，一般都会采用「主从复制」。

        比如：在复杂的业务系统中，有一句sql执行后导致锁表，并且这条sql的的执行时间有比较长，那么此sql执行的期间导致服务不可用，这样就会严重影响用户的体验度。

        主从复制中分为「主服务器（master）「和」从服务器（slave）」，「主服务器负责写，而从服务器负责读」，Mysql的主从复制的过程是一个「异步的过程」。

        这样读写分离的过程能够是整体的服务性能提高，即使写操作时间比较长，也不影响读操作的进行。

2.主从复制的原理

        放一张Mysql主从复制的原理图，总的来说Mysql的主从复制原理还是比较好理解的，原理非常的简单。

1. slave端的IO线程连接上master端，并请求从指定binlog日志文件的指定pos节点位置(或者从最开始的日志)开始复制之后的日志内容
2. master端在接收到来自slave端的IO线程请求后，通知负责复制进程的IO线程，根据slave端IO线程的请求信息，读取指定 binlog日志指定pos节点位置之后的日志信息，然后返回给slave端的IO线程。该返回信息中除了binlog日志所包含的信息之外，还包括本次返回的信息在master端的binlog文件名以及在该binlog日志中的pos节点位置。
3. slave端的IO线程在接收到master端IO返回的信息后，将接收到的binlog日志内容依次写入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的master端的binlog文件名和pos节点位置记录到master- info(该文件存在slave端)文件中，以便在下一次读取的时候能够清楚的告诉master，我需要从哪个binlog文件的哪个pos节点位置开 始，请把此节点以后的日志内容发给我。
4. slave端的SQL线程在检测到relaylog文件中新增内容后，会马上解析该log文件中的内容。然后还原成在master端真实执行的那些SQL语句，并在自身按顺序依次执行这些SQL语句。这样，实际上就是在master端和slave端执行了同样的SQL语句，所以master端和 slave端的数据是完全一样的。

以上mysql主从复制交互过程比较拗口，理解起来也比较麻烦，我简化了该交互过程。如下：

1. master在执行sql之后，记录二进制log文件(bin-log)。
2. slave连接master，并从master获取binlog，存于本地relay-log中，然后从上次记住的位置起执行SQL语句，一旦遇到错误则停止同步。

3.主从复制作用以及优缺点

3.1 主要作用

1、读写分离，使数据库能支撑更大的并发

        在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

2、发扬不同表引擎的优点

        目前Myisam表的查询速度比innodb略快，而写入并发innodb比myIsam要好。那么，我们可以使用innodb作为master，处理高并发写入，使用master作为slave，接受查询。或在myisam slave中建立全文索引，解决innodb无全文索引的弱点。

3、热备

        slave和master的数据“准实时”同步。

3.2 主从复制优点

1. 数据更安全：做了数据冗余，不会因为单台服务器的宕机而丢失数据
2. 性能大大提升：一主多从，不同用户从不同数据库读取，性能提升
3. 扩展性更优：流量增大时，可以方便的增加从服务器，不影响系统使用
4. 负载均衡：一主多从相当于分担了主机任务，做了负载均衡。

3.3 主从复制缺点

从以上mysql的Replication原理可以看出：

1. 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间主从数据不一致的情况。
2. 如果主从的网络断开，则从库会在网络恢复正常后，批量进行同步。
3. 如果对从库进行修改数据，那么如果此时从库正在在执行主库的bin-log时，则会出现错误而停止同步，这个是很危险的操作。所以一般情况下，我们要非常小心的修改从库上的数据。

注意：

1. 一个衍生的配置是双主、互为主从配置，只要双方的修改不冲突，则可以工作良好。

4.主从复制搭建

        本文的服务器是通过虚拟机安装两台CentOS7进行的测试，如何部署虚拟系统小伙伴们可以自行查询相关的方法，本文不做虚拟机的安装说明

4.1服务器说明

虚拟机IP	MySQL数据库版本	主从关系
192.168.10.104	5.7.28	master
192.168.10.105	5.7.28	slave

4.2 master主库配置

4.2.1修改配置文件my.cnf

[mysqld]
#配置唯一的服务器ID
server-id=104 # 可以修改为自己的id要求不能重复

4.2.2 重启服务与查看是否生效

# 两种方式根据自己配置进行选择其中一种方式即可
service mysql restart
systemctl restart mysql

# 登录mysql后进行查看
mysql> show variables like 'server_id';
mysql> show variables like 'log_bin';
#skip_networking默认是OFF关闭状态，启用后主从将无法通信
mysql> show variables like '%skip_networking%';

4.2.3 建立主从账号

mysql> GRANT REPLICATION SLAVE ON *.* TO admin@'%' identified by 'admin123';

mysql> flush privileges; # 刷新权限

4.2.4 查看主库信息

mysql> show master status;

说明： File 与Position 是配置从库所需，这时不要对主库进行任何操作，带配置完从库，启动后再进行主库的操作

4.3 从库配置

4.3.1 修该配置文件

 修改/etc/my.cnf 配置文件

[mysqld]
#配置唯一的服务器ID
server-id=105 # 可以修改为自己的id要求不能重复

4.3.2 重启服务查看

# 两种方式根据自己配置进行选择其中一种方式即可
service mysql restart
systemctl restart mysql

# 登录mysql后进行查看
mysql> show variables like 'server_id';
mysql> show variables like 'log_bin';
#skip_networking默认是OFF关闭状态，启用后主从将无法通信
mysql> show variables like '%skip_networking%';

4.3.3 配置从库参数

# 重启服务 登录mysql后执行
mysql> change master to
master_host='192.168.10.104',
master_port=3306,
master_user='admin' ,
master_password='admin123',
Master_log_file='mysql-bin.000007',
Master_log_pos=154;

4.3.4 查看与启动从库

mysql> show slave status\G
mysql> start slave;

4.4 测试主从同步

主库：                                                                                     

 从库：