Mysql主从复制

最新推荐文章于 2024-03-07 16:16:21 发布

风逸云舒

最新推荐文章于 2024-03-07 16:16:21 发布

阅读量548

点赞数

分类专栏： # Mysql数据库

本文链接：https://blog.csdn.net/baidu_31572291/article/details/115352531

版权

Mysql数据库专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Mysql主从复制

4.2.1.在配置半同步之前需要查看have_dynamic_loading信息。

4.2.2.为主库安装rpl_semi_sync_master

4.2.3.修改semi参数

4.3.半同步复制（从库）

4.3.1.为从库安装rpl_semi_sync_slave

4.3.2.修改从库的semi参数

5.搭建的时候遇到的问题

5.1.从库查看状态，uuid相同

1.Mysql主从复制的原理

首先主从复制的原理图如下：

主从复制整体分为以下三个步骤。

主库将数据库的变更操作记录到Binlog日志文件中。
从库读取主库的Binlog日志文件信息写到从库恩当Relay Log中继日志中。
从库读取中继日志信息在从库中进行Replay，更新从库信息。

其中涉及了Master的BinlogDump Thread和Slave的I/O Thread、SQL Thread

Master服务器对数据库更改操作记录在Binlog中，BinlogDump Thread接到写入请求后，读取Binlog信息推送给Slave的I/O Thread。
Slave的I/O Thread将读取到的Binlog信息写入到本地Relay Log中。
Slave的SQL Thread检测到Relay Log的变更请求，解析relay log中内容在从库上执行

2.数据库主从复制配置（主）

2.1.主库进行配置

首先需要在my.cnf文件(my.cnf所在的位置是 /etc)进行修改。

打开文件在[mysqld]下进行内容的新增：

log_bin=mysql-bin // 开启binlog日志的功能
service-id= 1 // service-id 在下文中会进行详细的讲解
sync-bilog=1 //控制数据库的binlog刷到磁盘上去
binlog-ignore-db= xxx //表示不需要进行同步的数据库
binlog-do-db=xxx //表示需要同步的数据库

2.1.1.service-id讲解

server-id用于标识数据库实例，防止在链式主从、多主多从拓扑中导致SQL语句的无限循环：

标记binlog event的源实例
过滤主库binlog，当发现server-id相同时，跳过该event执行，避免无限循环执行。
如果设置了replicate-same-server-id=1，则执行所有event，但有可能导致无限循环执行SQL语句。

当主库和备库server-id重复时

由于默认情况replicate-same-server-id=0，因此备库会跳过所有主库同步的数据，导致主从数据的不一致。

当两个备库server-id重复时

会导致从库跟主库的连接时断时连，产生大量异常。根据MySQL的设计，主库和从库通过事件机制进行连接和同步，当新的连接到来时，如果发现server-id相同，主库会断开之前的连接并重新注册新连接。当A库连接上主库时，此时B库连接到来，会断开A库连接，A库再进行重连，周而复始导致大量异常信息。

2.1.2.sync-bilog讲解

MySQL提供一个sync_binlog参数来控制数据库的binlog刷到磁盘上去。

sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。

如果sync_binlog>0，表示每sync_binlog次事务提交，MySQL调用文件系统的刷新操作将缓存刷下去。最安全的就是sync_binlog=1了，表示每次事务提交，MySQL都会把binlog刷下去，是最安全但是性能损耗最大的设置。

2.2.在数据库进行配置

flush privileges; //刷新
grant replication slave on *.* to 'root'@'%' identified by '123456'; //创建slave的复制账号 给的是数据库的权限，使用的使账号密码 appuser
grant all privileges on *.* to 'root'@'%' identified by '123456';

2.3.启动Master并查看状态

SHOW MASTER STATUS;

3.数据库主从复制配置（从）

从库的my.cnf文件配置

注：不同的从库server-id是不一样的

在进行从库数据库配置的时候首先需要查看

show slave status \G;

如果存在数据就使用

//停止主同复制
stop slave;
reset slave all;

3.1.配置主库的连接信息

change master to 
master_host='192.168.0.180',  //主库的ip地址
master_port=3306,  //主库开放的端口
master_user='root',  // 主库的用户信息
master_password='123456',  //主库的授权密码
master_log_file='mysql-bin.000004', // 这两条信息实在主库的查看Master状态的时候查看到的 
master_log_pos=620; // 这两条信息实在主库的查看Master状态的时候查看到的

start slave;

3.2.从库的信息查看

show slave status \G;

查看如果没有存在问题的话主从的数据库就已经是搭建完成了。

4.半主从复制

4.1.半主从复制简介

搭建半主从复制之前，需要了解普通的主从复制和半主从复制的区别在哪里？

上图所示为主从复制的时序图。

主从复制存在的问题：

主库宕机后，数据可能丢失
从库只有一个SQL Thread，主库写压力大，复制很可能延时

解决方案：

半同步复制---解决数据丢失的问题
并行复制----解决从库复制延迟的问题（并行复制就是开通多个sql thread进行从数据库的写入）

并行复制的时序图如下所示：

MySQL让Master在某一个时间点等待Slave节点的 ACK（Acknowledgecharacter）消息，接收到ACK消息后才进行事务提交，这也是半同步复制的基础，MySQL从5.5版本开始引入了半同步复制机制来降低数据丢失的概率。

在说半同步复制的时候首先需要回顾主从复制的完整过程

InnoDB Redo File Write (Prepare Write)
Binlog File Flush & Sync to Binlog File
InnoDB Redo File Commit（Commit Write）
Send Binlog to Slave

当Master不需要关注Slave是否接受到Binlog Event时，即为传统的主从复制。

当Master需要在第三步等待Slave返回ACK时，即为 after-commit，半同步复制（MySQL 5.5引入）。

当Master需要在第二步等待 Slave 返回 ACK 时，即为 after-sync，增强半同步（MySQL 5.7引入）。