MySQL金融应用场景下跨数据中心的MGR架构方案（1）

GreatSQL社区 GreatSQL社区 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 1k累计阅读 1k平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄5年
关注
原创 最新推荐文章于 2026-04-20 18:13:18 发布 1k 阅读 AI 写同款· GEO 优化 ›
【MySQL高可用集群】MySQL的MGR搭建 如果属性 group_replication_single_primary_mode =ON，则其他后启动组复制服务的节点会以slave 节点的身份自动加入复制组 ，最终组成一主多从集群。属性 group_replication_bootstrap_group 配置是否引导组复制，如果某个节点设置此属性为ON，则先启动此节点创建一个组服务并成为 master 节点，接受其他后启动节点加入组复制集群。10.53.207.20 作为引导节点启动组复制服务，此节点将作为主节点接收其他节点加入集群。 阅读详情
  • GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

0. 内容提纲

    1. 运行环境
    1. 部署MGR A&B
    1. 部署MGR A、B之间的复制通道
    1. 几个注意事项

如何在多个数据中心部署多套MySQL MGR集群以便快速切换。

在金融应用场景下，经常会要求在同城多中心部署高可用数据库架构，以期实现在发生故障时能达到快速切换的目标。

在同一个数据中心内，可以部署MGR集群，就可以实现快速灵活切换。

而即便是在同城，跨数据中心时，网络条件好的话，延迟可能也在 1ms 之内。这种网络条件下，如果要在同城多中心部署MGR集群也是可以尝试的（如果业务并发量不是特别高的话），但考虑到多数据中心间有较大概率会出现光缆被挖断等风险，所以还是不建议这么做。

因此，最好还是在同一个数据中心内部署一套独立的MGR集群，再通过主从复制（replication）方式（可以是异步复制或半同步复制），把数据复制一份到另一个数据中心内的MGR集群里，这样一旦主机房出现异常时，就可以快速切换到备用机房了，并且不担心数据库的高可用保障等级。

file

上面该方案的架构示意图。

接下来一起来完成这个架构方案的实施。

1. 运行环境

本次采用3个节点部署这套架构，各节点用途说明见下

file

每个节点上都运行两个实例，分别是3306、4306端口，其中3306端口的实例构成MGR A集群，4306端口的实例构成MGR B集群。

除了MySQL官方社区版本外，如果想体验更可靠、稳定、高效的MGR，推荐使用GreatSQL版本。本文采用GreatSQL 8.0.22版本，关于这个版本的说明详见 GreatSQL，打造更好的MGR生态。

  1. 部署MGR A&B 按照常规方式部署MGR即可，下面是一份关键配置参考：
group_replication_single_primary_mode=ON
log_error_verbosity=3
group_replication_bootstrap_group=OFF 
group_replication_transaction_size_limit=<默认值150MB，但建议调低在20MB以内，不要使用大事务>
group_replication_communication_max_message_size=10M
group_replication_flow_control_mode=“DISABLED” #官方版本的流控机制不太合理，其实可以考虑关闭
group_replication_exit_state_action=READ_ONLY
group_replication_member_expel_timeout=5 #如果网络环境不好，可以适当调高

slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=128 #可以设置为逻辑CPU数量的2-4倍
binlog_transaction_dependency_tracking=writeset
transaction_write_set_extraction=XXHASH64
slave_checkpoint_period=2

更多关于MGR以及复制的配置参考这份指南：MGR最佳实践。

启动MGR A，确认工作正常：

[root@GreatSQL mgrA-1][(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 5499a6cb-91cb-11eb-966f-525400e802e2 |    mgrA-1   |        3306 | ONLINE       | PRIMARY     | 8.0.22         |
| group_replication_applier | ec2fcbeb-976c-11eb-a652-525400e2078a |    mgrA-2   |        3306 | ONLINE       | SECONDARY   | 8.0.22         |
| group_replication_applier | edfbdeda-91c8-11eb-a3c6-525400fb993a |    mgrA-3   |        3306 | ONLINE       | SECONDARY   | 8.0.22         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

[root@GreatSQL mgrA-1][(none)]> select @@global.group_replication_group_name;
+---------------------------------------+
| @@global.group_replication_group_name |
+---------------------------------------+
| f195537d-19ac-11eb-b29f-5254002eb6d6  |
+---------------------------------------+

用同样的方法，再部署MGR B，并确认工作正常：

[root@GreatSQL mgrB-1][(none)]> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 31f7accc-96ac-11eb-92f8-525400e802e2 |    mgrB-1   |        4306 | ONLINE       | PRIMARY     | 8.0.22         |
| group_replication_applier | b084f8a1-96a8-11eb-9a70-525400fb993a |    mgrB-2   |        4306 | ONLINE       | SECONDARY   | 8.0.22         |
| group_replication_applier | ed57ca6b-96a9-11eb-be28-525400e2078a |    mgrB-3   |        4306 | ONLINE       | SECONDARY   | 8.0.22         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

[root@GreatSQL mgrB-1][(none)]> select @@global.group_replication_group_name;
+---------------------------------------+
| @@global.group_replication_group_name |
+---------------------------------------+
| 476c0276-be03-11eb-bd34-525400e802e2  |
+---------------------------------------+

确认上述2个MGR集群以及各个节点的 server_uuid 都不一样。

3. 部署MGR A、B之间的复制通道

从MySQL 5.7开始，支持多源复制（Multi-Source Replication），因此我们可以很方便的利用多源复制，在两个MGR集群之间再构建一个复制通道。

这个复制通道，既可以选择 异步复制（Asynchronous Replication），也可以选择 半同步复制（Semisynchronous Replication），可以根据两个MGR集群之间的网络状况，以及实际业务需要评估决定。

本案选择半同步复制方案，这仅限于实验目的，不表示我们推荐大家也采用半同步方案。

相应地，下面也是一份半同步的参考配置，大家可根据实际情况适当调整：

rpl_semi_sync_master_timeout=2592000000
rpl_semi_sync_master_wait_for_slave_count=1
rpl_semi_sync_master_wait_point=AFTER_SYNC

在MGR B的Pirmary节点上创建半同步复制通道（记得设置通道名）：

[root@GreatSQL mgrB-1][(none)]> CHANGE MASTER TO
MASTER_HOST='172.16.16.10', MASTER_PORT=3306, 
MASTER_USER='repl', MASTER_PASSWORD='repl',
MASTER_AUTO_POSITION=1
FOR CHANNEL 'mgrA-to-mgrB-semisync' ;

确认半同步复制生效：

[root@GreatSQL mgrB-1][(none)]> SHOW REPLICA STATUS\G
             Replica_IO_State: Queueing master event to the relay log
                  Source_Host: 172.16.16.10
                  Source_User: repl
                  Source_Port: 3306
...
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
...
                  Source_UUID: 5499a6cb-91cb-11eb-966f-525400e802e2
...
    Replica_SQL_Running_State: waiting for handler commit
...
           Retrieved_Gtid_Set: f195537d-19ac-11eb-b29f-5254002eb6d6:17-36885051:36885053:36885057:36885059:36885064:36885067
            Executed_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:1-5,
f195537d-19ac-11eb-b29f-5254002eb6d6:1-36884719:36884727:36884729-36884732:36884734-36884737
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name: mgrA-to-mgrB-semisync
...

P.S，上面的信息是已经运行一段时间后截取出来的，所以GTID的值看起来比较大。

也可以用类似的方法构建传统的异步复制通道，以及双向复制通道，都是可以的。

4. 几个注意事项

  • 两个MGR集群各节点的 server_uuid 确保不重复。
  • 两个MGR集群的名字（group_replication_group_name）确保不重复。
  • 构建完复制通道后，MGR B里的Primary节点最好也要设置为只读（super_read_only=1），避免误操作写入数据。
  • 两个MGR集群之间也要定期校验数据一致性，不管是异步复制还是（增强）半同步复制，乃至MGR都还存在多个丢数据的BUG，不能盲目乐观相信用了增强版同步/MGR就能保证数据一致性了。

本文先介绍基于多数据中心、多套MGR的架构方案。下一次再进一步介绍当发生故障或其他异常需要进行高可用切换的方案。

Enjoy GreatSQL :)

文章推荐：

GreatSQL MGR FAQ https://mp.weixin.qq.com/s/J6wkUpGXw3YkyEUJXiZ9xA

万答#12，MGR整个集群挂掉后，如何才能自动选主，不用手动干预 https://mp.weixin.qq.com/s/07o1poO44zwQIvaJNKEoPA

『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实践》 https://mp.weixin.qq.com/s/u7k99y6i7riq7ScYs7ySnA

一条sql语句慢在哪之抓包分析 https://mp.weixin.qq.com/s/AYibbzl860D90rOeyjB6IQ

万答#15，都有哪些情况可能导致MGR服务无法启动 https://mp.weixin.qq.com/s/inSGpd0Q_XIl2Mb-VsvNsA

技术分享 | 为什么MGR一致性模式不推荐AFTER https://mp.weixin.qq.com/s/rNeq479RNsklY1BlfKOsYg

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。

Gitee: https://gitee.com/GreatSQL/GreatSQL

GitHub: https://github.com/GreatSQL/GreatSQL

Bilibili： https://space.bilibili.com/1363850082/video

微信&QQ群： 可搜索添加GreatSQL社区助手微信好友，发送验证信息“加群”加入GreatSQL/MGR交流微信群

QQ群：533341697 微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 发布！

标签
#mysql #greatsql #mgr
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
CentOS Stream 9 中部署 MySQL 8.0 MGR（MySQL Group Replication）一主两从高可用集群 本文详细介绍了MySQL 8.0中的高可用方案，包括主从复制、MySQL InnoDB Cluster、MHA、Galera Cluster和ProxySQL+MGR/主从等。每种方案都从原理、优点、缺点和适用场景进行了分析。主从复制适合读多写少的中小型网站，MGR适合需要强一致性和自动故障转移的核心系统，MHA适合传统企业系统，Galera Cluster适合跨地域写入需求，ProxySQL组合适合高并发多维读写系统。文章还提供了环境准备和高可用搭建的详细步骤，包括系统配置、MySQL安装、配置文件修改和 阅读详情

相关推荐

数据库容灾 | MySQL MGR与阿里云PolarDB-X Paxos的深度对比

经过深入的技术剖析与性能对比，PolarDB-X DN凭借其自研的X-Paxos协议和一系列优化设计，在性能、正确性、可用性及资源开销等方面展现出对MySQL MGR的多项优势，但MGR在MySQL生态体系内也占据重要地位，但需要考虑备库宕机抖动、跨机房容灾性能波动、稳定性等各种情况，因此如果想用好MGR，必须配备专业的技术和运维团队的支持。

openApsaraDB的博客 1326

mysql集群方案参考

集群的好处 高可用性：故障检测及迁移，多节点备份。 可伸缩性：新增数据库节点便利，方便扩容。 负载均衡：切换某服务访问某节点，分摊单个节点的数据库压力。 集群要考虑的风险 网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。 脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法修复，例如当两个数据库节点独立更新同一表上的同一行时。 @[toc] 一，mysql原厂出品 1，MySQL Replicatio

XiaoGong1688的博客 591

7、MGR（MySQL Group Replication）

单主模式（Single-Primary Mode）：只有master节点可读可写（称为 PRIMARY），其余slave节点只读（称为SECONDARY）多主模式（Multi-Primary Mode）：所有节点都可读可写。

IT大白的博客 1216

MySQL集群方案总结与方案原理

在给自己做着玩的一个项目准备数据库集群，顺带自己大致系统复习并记录一下。

qq_37432174的博客 2395

Unity3D Pico VR 手势交互实战：基于MRTK3实现抓握与射线控制

本文针对Pico VR原生手势交互功能不足的问题，提供了基于MRTK3实现高级手势交互的实战解决方案。通过将MRTK3成熟的交互框架与Pico的手势追踪能力相结合，详细讲解了从环境配置、SDK导入、核心适配到真机调试的全流程，帮助开发者高效实现抓握与射线控制等复杂交互，有效提升Pico VR应用的开发效率与体验。

weixin_29011667的博客 391

Windows 10下Carla 0.9.15安装避坑指南：从下载到运行的全流程解析

本文详细解析了在Windows 10系统上安装和运行Carla 0.9.15自动驾驶仿真平台的全流程。内容涵盖从系统环境准备、资源下载、Python依赖安装，到首次启动验证及常见错误（如DLL缺失、显卡驱动问题）的深度解决方案，旨在帮助用户快速搭建稳定的开发环境，并运行第一个自动驾驶Python脚本。

alice7model的博客 546

MySQL跨机房集群方案_Mysql跨机房同步方案

随着用户量的不断累积，Mysql从单实例单节点发展到多实例多节点的主备，再到一个机房几十台Myql实例，但是现在，一个机房也开始慢慢无法承受庞大的数据吞吐，多机房的理念开始构建。假设现有两个机房，需要做到数据同步。以下是架构图(实际架构图根据现有机房架构和实际会比下图复杂，但整体思路不变)： Mycat、Canal、Otter是关键的三项技术：Mycat：数据库分库分表中间件，可以管理一个mysq...

weixin_34288514的博客 756

求助：有没有基于pscad的锂电池仿真模型

求助：有没有基于pscad的锂电池仿真模型 欢迎使用Markdown编辑器 你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。 新的改变没有 我们对Markdown编辑器进行了一些功能拓展与语法支持，除了标准的Markdown编辑器功能，我们增加了如下几点新功能，帮助你用它写...

qq_38922523的博客 1222

MySQL金融应用场景下跨数据中心的MGR架构方案（2）

GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 如何在多个数据中心部署多套MGR集群，并实现故障快速切换。 上篇文章介绍了如何在多数据中心部署多套MGR集群，并构建集群间的复制通道。这样一旦主AZ不可用时，在校验完数据后，就可以切换到备用AZ的MGR集群，非常方便。 本文我们继续深入介绍如何利用 Async Replication Auto failover 实现故障自动转移的。 1、什么是Async Replication Auto failover 从MySQL 8.

GreatSQL2021的博客 771

SAP 批量修改 工艺路线 和 BOM

1、在运维的过程中经常会遇到用户需要批量更改组件，或者是批量更改数量，还是组件里面的一些标识，当处理这些批量数据处理的业务时，BOM的批量更改一个想到的就是CS20，但是CS20当BOM需要替换的时候就不是很适用。当前工作区域：选择 SAP_ITEM 对BOM行项目进行变更，工艺路线也是可以批量更改的，根据实际的业务进行选择，我这里选择的就是BOM的组件变更。5、本博客将使用新的一种方式进行BOM的批量变更，标准的事务代码：CEWB对BOM进行批量更改。3、使用LSMW的方式进行BOM的批量更改。

我小时候很黑的博客 4097

基于投影法实现扫描文件的光学字符分割——Matlab实现

投影法是指将原图像沿着某个特定的方向进行投影，得到投影线上的像素点的个数或像素值总和，从而可以得到该方向上物体的轮廓信息。对于字符分割，我们可以将图像进行水平和垂直两个方向的投影，从而得到字符之间的分割线。在OCR技术中，字符分割是非常重要的一步骤，因为字符之间的分割对字符识别的准确性有很大的影响。通过对投影值的判断，可以求出字符之间的分割线，这里我们根据垂直方向上的投影值进行判断，选取一个阈值进行筛选即可。使用sum()函数分别计算出水平和垂直方向上的投影值，得到每一行和每一列的投影值。

TechGlide的博客 582

金融应用场景下跨数据中心的MGR架构方案（1）

本文来源：原创投稿* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。0. 内容提纲1. 运行环境2. 部署MGR A&B3. 部署MGR A、B之间的...

老叶茶馆 442

手把手教你学Simulink——基于Simulink的前馈解耦SVPWM整流器仿真

本文详细介绍了基于Simulink的前馈解耦SVPWM整流器仿真方法。针对三相PWM整流器存在的dq轴交叉耦合问题，提出前馈解耦控制方案，通过在电流环中引入耦合电压补偿项，显著提升系统性能。文章包含完整的系统架构、核心算法、Simulink建模步骤及参数设置，仿真结果显示：电流跟踪误差<2%、动态响应时间<0.05s、THD<3%、功率因数>0.999。同时提供了可直接复用的MATLAB代码和工程优化建议，为电力电子工程师实现高精度AC/DC转换提供了实用解决方案。

MHD0815的博客 108

金融应用场景下跨数据中心的MGR架构方案（2）

本文来源：原创投稿* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。内容提纲1、什么是Async Replication Auto failover2、基于M...

老叶茶馆 574

[Dify实战] 项目复盘助手：自动拉数据、生成复盘报告

本文介绍如何利用Dify平台构建自动化项目复盘助手，解决传统人工复盘效率低、易遗漏等问题。系统通过自动拉取Git/Jira等数据源，计算关键指标后，由LLM生成结构化复盘报告。文章详细讲解了数据采集、指标计算、Prompt设计等核心模块的实现，并分享了完整Workflow搭建步骤。实践表明，该系统能将复盘耗时从4小时缩短至10分钟，显著提升数据准确率和执行频率。最后总结了数据一致性、输出质量等常见问题的解决方案，强调Dify+LLM组合可实现复盘流程的自动化流水线。

技术小甜甜：传播可落地技术，帮助个人和企业降低解决真实场景问题的成本 118

Python爬虫实战：逆向解析腾讯视频API，高效获取结构化视频信息

首先，我们定义期望获取的数据结构，这有助于数据验证和代码清晰度。python"""腾讯视频信息数据模型"""title: str = Field(..., description="视频标题")vid: str = Field(..., description="视频唯一ID")play_count: Optional[int] = Field(None, description="播放量")

2201_76125261的博客 2379

万字详解 MySQL MGR 高可用集群搭建

MGR（MySQL Group Replication）是MySQL 5.7.17版本诞生的，是MySQL自带的一个插件，可以灵活部署。保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入。集群是多个MySQL Server节点共同组成的分布式集群，每个Server都有完整的副本，它是基于ROW格式的二进制日志文件和GTID特性。在单主模式下, 组复制具有自动选主功能，每次只有一个 server成员可以作为主节点。单主模式 group 内只有一台节点可写可读，其他节点只可以读。

保持学习 9302

Camera2Demo

在Camera2 的基础上进行封装，使得Camera2一堆初始化逻辑与Activity分离，降低耦合度，完成预览拍照并保存的操作

mysql mgr应用场景_悄悄告诉你 MySQL MGR 牛在哪?

大家听过 MySQL MGR 技术吗？MySQL 是目前最流行的开源关系型数据库，国内金融行业也开始全面使用，其中MySQL 5.7.17 提出的 MGR(MySQL Group Replication)既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入，MGR 是一项被普遍看好的技术。本文给大家介绍一下 MySQL MGR 技术演变过程、事务生命周期及事务冲突检测机制。先...

weixin_32112641的博客 643

老版QQ原生表情gif动态

这是老版的QQ表情，不过全是动态的的，Windows照片查看器是不会动的，可以右击用浏览器打开查看，再说一遍是老版的，只是分享给宁愿用老版也要动态的人。

温度PID控制PLC程序

温度PID稳定控制程序，适用于欧姆龙PLC，对其他PLC也具有很大参考价值

Mysql - MGR高可用

从MySQL5.6开始增加了强大的GTID（Global Transaction ID，全局事务ID）这个特性，用来强化数据库的主备一致性， 故障恢复， 以及容错能力。用于取代过去传统的主从复制（即：基于binlog和position的异步复制）。GTID 出现之前，在一主多从的复制拓扑中，如果主库宕机，需要从多个从库选择之一作为新主库，这个过程比较复杂。没有一种直接了当的方法找到其它从库对应的新主库二进制日志坐标。

lsh0411的博客 1096

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术，以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索，主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式，计算机控制系统的数学描述与基本分析方法，以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

面向金融级 MGR 应用场景优化--叶金荣 | 3306π上海站专访

01会议议程02嘉宾介绍叶金荣公司：万里数据库主题：面向金融及MGR应用场景优化03采访明细1.叶老师作为MySQL这些年的布道者，培养了非常多，非常优秀的MySQL人才，也分享了很多有价...

老叶茶馆 476

金融级数据库架构实战：MySQL Router + MGR 深度指南

本文通过在RHEL 8环境下部署与集群，深度实战了金融级数据库的高可用架构。架构解耦与透明化： 通过 MySQL Router 的机制，应用层不再需要维护复杂的 VIP 或硬编码多个数据库 IP。业务只需连接 Router 提供的固定端口（6446/6447），即可实现读写请求的自动路由与拓扑感知。集群纳管与自治： 实战证明，利用对原生 MGR 进行“收编”（Adopt），是实现 Router 自动感知的先决条件。这一步将散装的数据库实例转变为具备“自我意识”的体系，为自动故障转移奠定了元数据基础。

m0_50180963的博客 702

mysql mgr工作原理_Mysql重磅推出金融级分布式数据库MGR大揭秘

MGR简介MySQL Group Replication，简称MGR，它是MySQL官方推出的基于paxos分布式一致性协议的状态机复制，实现了分布式下数据的最终一致性。同时MGR提供了高可用、高扩展、高可靠的MySQL集群解决方案，它也是金融级分布式数据库之一。MGR适用场景MGR天生就是为金融场景设计的，例如：支付，证券交易，保险，银行等等。因为这些场景要求数据必须做到零丢失，数据库可用性在4...

weixin_39735012的博客 1219

mysql的MGR集群

MySQL 是目前最流行的开源关系型数据库，国内金融行业也开始全面使用，其中MySQL 5.7.17 提出的 MGR(MySQL Group Replication)既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入，MGR 是一项被普遍看好的技术。本文给大家介绍一下 MySQL MGR 技术演变过程、事务生命周期及事务冲突检测机制。 先介绍 MGR 技术演进 传统的 MySQL 主从复制架构是 MySQL 保持数据一致性的最基本架构，如下图1 所示，一主一从架构，从库给主...

XiaoGong1688的博客 869

MySQL的MGR高可用

在决定是否采用 MGR 之前，必须清楚其局限性。

2301_80335585的博客 771
上一篇： 技术分享 | MySQL Group Replication集群对IP地址的限制导致的一些问题与解决办法
下一篇： MySQL金融应用场景下跨数据中心的MGR架构方案（2）
点赞 0
评论 0
书签 书签 1
GreatSQL社区
GreatSQL社区
博客等级 码龄5年 1210粉丝 390原创
+ 关注
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值