MySQL8基于GTID以及VIP实现高可用主从架构

janyxe

于 2024-06-10 21:53:15 发布

阅读量982

点赞数 20

分类专栏： MySQL 分库分表分布式专题文章标签：架构

本文链接：https://blog.csdn.net/janyxe/article/details/139380690

版权

分布式专题同时被 3 个专栏收录

10 篇文章 0 订阅

订阅专栏

分库分表

6 篇文章 0 订阅

订阅专栏

MySQL

2 篇文章 0 订阅

订阅专栏

jdbc客户端配置高可用以及故障切换

jdbc客户端实现故障切换

MySQL Connector/J 支持服务器故障转移。当底层活动连接发生与连接相关的错误时，就会发生故障转移

参考官网地址
jdbc:mysql://[primary host][:port],[secondary host 1][:port]

jdbc客户端实现故障切换

Connector/J 长期以来一直提供一种有效方法，用于在集群或主从复制部署中跨多个 MySQL 服务器实例分配读/写负载
参考官网网站
jdbc:mysql:loadbalance://[host1][:port],[host2][:port]

服务端高可用架构

MySQL支持的复制方式

binlog复制方式【基于二进制日志binlog复制】
GTID复制方式【基于事务】

基于binlog主从复制原理

binlog主从复制原理

1、主库会生成多个 binlog 日志文件。
2、从库的 I/O 线程请求指定文件和指定位置的 binlog 日志文件（位点）。
3、主库 dump 线程获取指定位点的 binlog 日志。
4、主库按照从库发送给来的位点信息读取 binlog，然后推送 binlog 给从库。
5、从库将得到的 binlog 写到本地的 relay log (中继日志) 文件中。
6、从库的 SQL 线程读取和解析 relay log 文件。
7、从库的 SQL 线程重放 relay log 中的命令。

binlog 配置方式
主库上执行SHOW MASTER STATUS查看同步的文件以及偏移量

从库设置主库的地址以及指定同步的文件以及偏移量
change replication source to source_host='xxx', source_user='root', source_password='root', source_port=3306, source_log_file='mysql-bin.000003', source_log_pos=12, source_connect_retry=30;

binlog 复制缺点

1、首次开启主从复制步骤复杂

找到主库的 binlog 位点。
设置从库的 binlog 位点。
2、恢复主从复制的步骤负责
需要找到从库线程停止的位点

GTID 复制原理

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID，它由服务器ID以及事务ID组合而成

GTID 的优势

更简单的实现 failover，不用以前那样在需要找位点（log_file 和 log_pos）。
更简单的搭建主从复制。
比传统的复制更加安全。
GTID 是连续的没有空洞的，保证数据的一致性，零丢失。

GTID结构

GTID表示为一对坐标，由冒号(:)分隔，如下所示:
GTID = source_id:transaction_id

source_id标识source服务器，即源服务器唯一的server_uuid，由于GTID会传递到replica，所以也可以理解为源ID。
transaction_id是一个序列号，由事务在源上提交的顺序决定。序列号的上限是有符号64位整数（2^63-1）

GTID工作原理

主库计算主库 GTID 集合和从库 GTID 的集合的差集，主库推送差集 binlog 给从库。
当从库设置完同步参数后，主库 A 的 GTID 集合记为集合 x，从库 B 的 GTID 集合记为 y

GTID工作原理

从库 B 指定主库 A，基于主备协议建立连接。
从库 B 把集合 y 发给主库 A。
主库 A 计算出集合 x 和集合 y 的差集，也就是集合 x 中存在，集合 y 中不存在的 GTID 集合。比如集合 x 是 1~100，集合 y 是 1~90，那么这个差集就是 91~100。这里会判断集合 x 是不是包含有集合 y 的所有 GTID，如果不是则说明主库 A 删除了从库 B 需要的 binlog，主库 A 直接返回错误。
主库 A 从自己的 binlog 文件里面，找到第一个不在集合 y 中的事务 GTID，也就是找到了 91。
主库 A 从 GTID = 91 的事务开始，往后读 binlog 文件，按顺序取 binlog，然后发给 B。
从库 B 的 I/O 线程读取 binlog 文件生成 relay log，SQL 线程解析 relay log，然后执行 SQL 语句。

GTID以及VIP实现高可用

GTID以及VIP实现高可用
实现方案：
选择配置比较高的一台为主服务器，提供读写功能，另一台从服务器作为 BackUP 热备，同时通过复制与主服务器数据保持一致，二者均开启 bin-log 功能。Keepalived 自带服务监控功能，实现故障时 VIP 的无缝切换，当活跃节点出现故障时，通过 VIP＋keepalived脚本执行实现向另一台主数据库的切换，以此实现 MySQL 架构的高可用

从节点一般会设置为只读模式，线上一般通过keeplive实现高可用
可参考脚本，如果主节点宕机，将从节点的只读变成可读可写，使用高可用

   STATUS=$(mysqladmin -uroot -proot ping|grep -c alive)
  if [ $STATUS -eq 1 ];then
    mysql -uroot -proot -e 
    stop slave;
    set global super_read_only=0;
    set global read_only=0;"