searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

MGR高可用

2023-05-11 07:46:03
30
0

背景

虚拟币⼀般是公司基础的⽤⼾虚拟币账⼾体系,集成充值、消费、余额查询、转账、账务等核⼼功能,因此须保证其⾼可⽤性(多机房容灾)。

痛点

Mysql单点:主库实例或者机器宕机,不能确保主从数据⼀致,不敢切;即使强切,需⼈⼯进⾏数据恢复,过程⻓且复杂。

Redis单点:多机房部署,导致redis跨机房读写,⽹络抖动经常导致超时失败。Redis实例或者机器宕机,需⼈⼯⼲预切换到slave,主从

⼀致性也⽆法保证。

MGR(MySQL Group Replication)是⼀个MySQL Server插件,可⽤于创建弹性,⾼可⽤MySQL集群⽅案。有⼀个内置的组成员服务,在任何给定的时间点,保持组的视图

⼀致并可供所有服务器使⽤。服务器可以离开并加⼊组,视图也会相应更新。当成员离开组,故障检测机制会检测到此情况并通知组视图已更改

1.1传统的数据主从复制

1.1.1主从复制

传统的数据主从辅助属于异步复制,从库起IO线程连接主库,获取主库二进制日志写到本地中继日志,并更新master-info文件(存放主库相关信息),从库再利用SQL线程执行中继日志。
1.1.2半同步复制
半同步复制是建立在基本的主从复制基础上,利用插件完成半同步复制,传统的主从复制,不管从库是否正确获取到二进制日志,主库不断更新,半同步复制则当确认了从库把二进制日志写入中继日志才会允许提交,如果从库迟迟不返回ack,主库会自动将半同步复制状态取消,进入最基本的主从复制模式。
1.2 组复制
组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的server集群。复制组由多个server成员组成,如上图的master1,master2,master3,所有成员独立完成各自的事务。当客户端先发起一个更新事务,该事务先在本地执行,执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去,复制到其他成员。如果冲突检测成功,组内决定该事务可以提交,其他成员可以应用,否则就回滚。最终,这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改,保证组内数据强一致性。
 
MySQL高可用方案 – 业内方案比较
 
 
MGR主要优点:高一致性,高容错性,高扩展性,高灵活性缺点:只支持InnoDB引擎,业界使用较少,至少三个节点网络带宽消耗大
 
 
MGR部署
IP 主机名 数据库版本信息 server-id
xxx MGR_NODE1 MySQL-5.7.25 203
xxx MGR_NODE2 MySQL-5.7.25 204
xxx MGR_NODE3 MySQL-5.7.25 205
2.2 环境准备
关闭防火墙以及selinux(所有机器执行)
 
关闭防火墙
systemctl stop firewalld
临时关闭selinux
setenforce 0
配置主机名,按照先前规划,填写/etc/hosts文件
 
[root@localhost data]# cat /etc/hosts
xxx mgr_node1
xxx mgr_node2
xxx mgr_node3
 
参数讲解:
 
基本参数 描述
user 启动进程的user
port 数据库使用的端口
datadir 数据库的数据目录位置
log-error 数据库的错误日志位置
pid-file 数据库的pid文件位置
socket 数据库的sock文件位置
symbolic-links 禁用符号链接以防止出现各种安全风险
MGR要求的相关参数 描述
server_id 不同实例必须保证此server_id不同,如果启用了二进制日志记录,则必须指定该选项,否则不允许服务器启动
gtid_mode 使用全局事务标识符(GTID)来标识事务。将此选项设置为–gtid-mode=ON 要求 enforce-gtid-consistency设置为ON
enforce_gtid_consistency ON:不允许任何事务违反GTID一致性 OFF:允许事务违反GTID一致性。WARN:允许所有事务违反GTID一致性,但在这种情况下会生成警告
master_info_repository 设置从站将主状态和连接信息记录到 FILE(master.info)还是TABLE (mysql.slave_master_info)中
relay_log_info_repository 设置从站在中继日志中的位置是写入FILE (relay-log.info)还是 写入TABLE (mysql.slave_relay_log_info)中
binlog_checksum 启用后,此变量会使主服务器为二进制日志中的每个事件写入校验和,当binlog_checksum禁用(值 NONE)时,服务器通过编写和检查每个事件的事件长度(而不是校验和)来验证它是否只将完整事件写入二进制日志
log_slave_updates 设置从主服务器接受的更新是否写入二进制日志中
log_bin 设置二进制日志的位置
binlog_format 二进制日志格式,有行模式,语句模式,混合模式,使用MGR必须使用行模式
组复制相关参数 描述
transaction_write_set_extraction 定义用于生成标识与事务关联的写入的哈希的算法,哈希值将用于分布式冲突检测和处理
loose-group_replication_group_name 通知插件它正在加入或创建的组,需要使用SELECT UUID()生成一个UUID
loose-group_replication_start_on_boot 指示插件在服务器启动时不自动引导组操作
loose-group_replication_local_address 诉插件使用哪个ip:port与组中的其他成员进行内部通信。这里的ip与端口不能与MySQL提供的ip:port 相同,如果使用相同ip则port必须不相同
loose-group_replication_group_seeds 设置组成员的主机名和端口
loose-group_replication_bootstrap_group 插件是否引导组,此选项只能在任何时候在一个服务器实例上使用,通常是第一次引导组时(或者在整个组关闭并重新备份的情况下)。如果多次引导组,例如当多个服务器实例设置了此选项时,则可以创建一个人工分裂脑情景,其中存在两个具有相同名称的不同组。
loose-group_replication_single_primary_mode 单主模式设置为ON,多主模式设置为OFF
loose-group_replication_enforce_update_everywhere_checks 在所有节点启用多主数据更新的严格一致性检查
0条评论
0 / 1000
l****n
11文章数
0粉丝数
l****n
11 文章 | 0 粉丝
原创

MGR高可用

2023-05-11 07:46:03
30
0

背景

虚拟币⼀般是公司基础的⽤⼾虚拟币账⼾体系,集成充值、消费、余额查询、转账、账务等核⼼功能,因此须保证其⾼可⽤性(多机房容灾)。

痛点

Mysql单点:主库实例或者机器宕机,不能确保主从数据⼀致,不敢切;即使强切,需⼈⼯进⾏数据恢复,过程⻓且复杂。

Redis单点:多机房部署,导致redis跨机房读写,⽹络抖动经常导致超时失败。Redis实例或者机器宕机,需⼈⼯⼲预切换到slave,主从

⼀致性也⽆法保证。

MGR(MySQL Group Replication)是⼀个MySQL Server插件,可⽤于创建弹性,⾼可⽤MySQL集群⽅案。有⼀个内置的组成员服务,在任何给定的时间点,保持组的视图

⼀致并可供所有服务器使⽤。服务器可以离开并加⼊组,视图也会相应更新。当成员离开组,故障检测机制会检测到此情况并通知组视图已更改

1.1传统的数据主从复制

1.1.1主从复制

传统的数据主从辅助属于异步复制,从库起IO线程连接主库,获取主库二进制日志写到本地中继日志,并更新master-info文件(存放主库相关信息),从库再利用SQL线程执行中继日志。
1.1.2半同步复制
半同步复制是建立在基本的主从复制基础上,利用插件完成半同步复制,传统的主从复制,不管从库是否正确获取到二进制日志,主库不断更新,半同步复制则当确认了从库把二进制日志写入中继日志才会允许提交,如果从库迟迟不返回ack,主库会自动将半同步复制状态取消,进入最基本的主从复制模式。
1.2 组复制
组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的server集群。复制组由多个server成员组成,如上图的master1,master2,master3,所有成员独立完成各自的事务。当客户端先发起一个更新事务,该事务先在本地执行,执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去,复制到其他成员。如果冲突检测成功,组内决定该事务可以提交,其他成员可以应用,否则就回滚。最终,这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改,保证组内数据强一致性。
 
MySQL高可用方案 – 业内方案比较
 
 
MGR主要优点:高一致性,高容错性,高扩展性,高灵活性缺点:只支持InnoDB引擎,业界使用较少,至少三个节点网络带宽消耗大
 
 
MGR部署
IP 主机名 数据库版本信息 server-id
xxx MGR_NODE1 MySQL-5.7.25 203
xxx MGR_NODE2 MySQL-5.7.25 204
xxx MGR_NODE3 MySQL-5.7.25 205
2.2 环境准备
关闭防火墙以及selinux(所有机器执行)
 
关闭防火墙
systemctl stop firewalld
临时关闭selinux
setenforce 0
配置主机名,按照先前规划,填写/etc/hosts文件
 
[root@localhost data]# cat /etc/hosts
xxx mgr_node1
xxx mgr_node2
xxx mgr_node3
 
参数讲解:
 
基本参数 描述
user 启动进程的user
port 数据库使用的端口
datadir 数据库的数据目录位置
log-error 数据库的错误日志位置
pid-file 数据库的pid文件位置
socket 数据库的sock文件位置
symbolic-links 禁用符号链接以防止出现各种安全风险
MGR要求的相关参数 描述
server_id 不同实例必须保证此server_id不同,如果启用了二进制日志记录,则必须指定该选项,否则不允许服务器启动
gtid_mode 使用全局事务标识符(GTID)来标识事务。将此选项设置为–gtid-mode=ON 要求 enforce-gtid-consistency设置为ON
enforce_gtid_consistency ON:不允许任何事务违反GTID一致性 OFF:允许事务违反GTID一致性。WARN:允许所有事务违反GTID一致性,但在这种情况下会生成警告
master_info_repository 设置从站将主状态和连接信息记录到 FILE(master.info)还是TABLE (mysql.slave_master_info)中
relay_log_info_repository 设置从站在中继日志中的位置是写入FILE (relay-log.info)还是 写入TABLE (mysql.slave_relay_log_info)中
binlog_checksum 启用后,此变量会使主服务器为二进制日志中的每个事件写入校验和,当binlog_checksum禁用(值 NONE)时,服务器通过编写和检查每个事件的事件长度(而不是校验和)来验证它是否只将完整事件写入二进制日志
log_slave_updates 设置从主服务器接受的更新是否写入二进制日志中
log_bin 设置二进制日志的位置
binlog_format 二进制日志格式,有行模式,语句模式,混合模式,使用MGR必须使用行模式
组复制相关参数 描述
transaction_write_set_extraction 定义用于生成标识与事务关联的写入的哈希的算法,哈希值将用于分布式冲突检测和处理
loose-group_replication_group_name 通知插件它正在加入或创建的组,需要使用SELECT UUID()生成一个UUID
loose-group_replication_start_on_boot 指示插件在服务器启动时不自动引导组操作
loose-group_replication_local_address 诉插件使用哪个ip:port与组中的其他成员进行内部通信。这里的ip与端口不能与MySQL提供的ip:port 相同,如果使用相同ip则port必须不相同
loose-group_replication_group_seeds 设置组成员的主机名和端口
loose-group_replication_bootstrap_group 插件是否引导组,此选项只能在任何时候在一个服务器实例上使用,通常是第一次引导组时(或者在整个组关闭并重新备份的情况下)。如果多次引导组,例如当多个服务器实例设置了此选项时,则可以创建一个人工分裂脑情景,其中存在两个具有相同名称的不同组。
loose-group_replication_single_primary_mode 单主模式设置为ON,多主模式设置为OFF
loose-group_replication_enforce_update_everywhere_checks 在所有节点启用多主数据更新的严格一致性检查
文章来自个人专栏
MGR高可用
9 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0