CN116910147A - 基于组复制的MySQL同城多中心的多活实现方法和系统 - Google Patents

基于组复制的MySQL同城多中心的多活实现方法和系统 Download PDF

Info

Publication number
CN116910147A
CN116910147A CN202310340370.9A CN202310340370A CN116910147A CN 116910147 A CN116910147 A CN 116910147A CN 202310340370 A CN202310340370 A CN 202310340370A CN 116910147 A CN116910147 A CN 116910147A
Authority
CN
China
Prior art keywords
group
replication
transactions
transaction
mysql
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310340370.9A
Other languages
English (en)
Inventor
魏子昂
窦尧
胡娟
何秉卫
周伟
何卓凡
李升�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial Bank Co Ltd
CIB Fintech Services Shanghai Co Ltd
Original Assignee
Industrial Bank Co Ltd
CIB Fintech Services Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Industrial Bank Co Ltd, CIB Fintech Services Shanghai Co Ltd filed Critical Industrial Bank Co Ltd
Priority to CN202310340370.9A priority Critical patent/CN116910147A/zh
Publication of CN116910147A publication Critical patent/CN116910147A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种基于组复制的MySQL同城多中心的多活实现方法和系统，包括：在数据中心A中部署一组带有组复制协议的MySQL集群A实例组，在数据中心B中部署一组带有组复制协议的MySQL集群B实例组，在流量控制区部署流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活。本发明在发生故障时可以保障数据不丢失以及业务强连续性，从而提高整体运维效率。

Description

基于组复制的MySQL同城多中心的多活实现方法和系统
技术领域
本发明涉及MySQL技术领域，具体地，涉及一种基于组复制的MySQL同城多中心的多活实现方法和系统。
背景技术
目前主流的同城多中心的多活方案，存在以下两种主流解决方案：
方案一：主流方案基本使用MySQL的半同步的主从复制模式，构建出双主的架构，实现双活方案；主主模式，复制链路非常脆弱，容易出现复制中断，导致双向复制失败；同时需要业务主动适配流量写入方向，对业务侵入性比较大，故障后，需要业务手工修改配置来实现流量的切换；
方案二：通过引入第三方的复制工具，构建双向复制，实现MySQL双机房之间的相互同步复制，由于引入外部工具，往往在协议解析上存在缺陷，容易造成双向复制失败；业务侧缺失流量控制，也会存在方案一带来的问题。
专利文献CN111708843A(申请号：CN202010560771.1)公开了一种基于MGR的跨数据中心MySQL多活实现方法，包括如下步骤：S1在同一个城市里要去选择三个数据中心，或者是自建数据中心，或者是租用运营商的数据中心，保证三个数据中心之间的距离在30公里以内；S2三个数据中心之间通过DWDM技术，使用裸光纤连接，确保网络延迟的2毫秒以内，网络带宽在10GB以上；S3数据库服务器采用物理主机，内存至少128G，CPU至少32核心，硬盘使用固态盘，保证数据库性能足够支撑相关业务。然而该专利无法解决目前存在的技术问题，也无法满足本发明的需求。
发明内容
针对现有技术中的缺陷，本发明的目的是提供一种基于组复制的MySQL同城多中心的多活实现方法和系统。
根据本发明提供的基于组复制的MySQL同城多中心的多活实现方法，包括：
在数据中心A中部署一组带有组复制协议的MySQL集群A实例组，在数据中心B中部署一组带有组复制协议的MySQL集群B实例组，在流量控制区部署流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活。
优选的，基于异步复制故障自动切换技术，在MySQL集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重，当主复制源发生故障异常中断后，先尝试重连几次，然后自动切换到新的复制源，当原来的复制源恢复后，如果其权重更高，则切换回去。
优选的，组复制中每个节点都有一份完整的数据副本，节点间通过GCS层进行交互；
通过能够相互通信的多个服务器节点组成复制组，每个服务器节点独立执行事务，所有读写事务在冲突检测成功后提交；
当读写事务准备提交前，向复制组发出一个原子广播，内容包括：该事务修改的数据，及其所对应的写集合；如果组中所有节点都接收该事务消息，则都按照与之前发送事务的相同顺序收到该广播消息，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。
优选的，若在多个节点上并行执行的事务产生冲突，则对比判断两个并行事务的写集合进行确认，判定全局顺序在前的事务成功，所有节点都提交该事务；全局顺序在后的事务失败回滚，各节点删除该事务；若事务产生冲突的频次超出预设阈值，则将该事务放在同一个节点上执行。
优选的，对于正在应用或外化的事务，在不破坏事务一致性和有效性的前提下，组复制允许它们不一定按照原有顺序执行；当流量超出预设阈值时，事务存在被外化而导致顺序不一致的可能性，若组复制的认证线程判定这个事务不会产生冲突则不处理。
根据本发明提供的基于组复制的MySQL同城多中心的多活实现系统，包括：
数据中心A：部署一组带有组复制协议的MySQL集群A实例组；
数据中心B：部署一组带有组复制协议的MySQL集群B实例组；
流量控制区：部署流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活。
优选的，基于异步复制故障自动切换技术，在MySQL集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重，当主复制源发生故障异常中断后，先尝试重连几次，然后自动切换到新的复制源，当原来的复制源恢复后，如果其权重更高，则切换回去。
优选的，组复制中每个节点都有一份完整的数据副本，节点间通过GCS层进行交互；
通过能够相互通信的多个服务器节点组成复制组，每个服务器节点独立执行事务，所有读写事务在冲突检测成功后提交；
当读写事务准备提交前，向复制组发出一个原子广播，内容包括：该事务修改的数据，及其所对应的写集合；如果组中所有节点都接收该事务消息，则都按照与之前发送事务的相同顺序收到该广播消息，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。
优选的，若在多个节点上并行执行的事务产生冲突，则对比判断两个并行事务的写集合进行确认，判定全局顺序在前的事务成功，所有节点都提交该事务；全局顺序在后的事务失败回滚，各节点删除该事务；若事务产生冲突的频次超出预设阈值，则将该事务放在同一个节点上执行。
优选的，对于正在应用或外化的事务，在不破坏事务一致性和有效性的前提下，组复制允许它们不一定按照原有顺序执行；当流量超出预设阈值时，事务存在被外化而导致顺序不一致的可能性，若组复制的认证线程判定这个事务不会产生冲突则不处理。
与现有技术相比，本发明具有如下的有益效果：
(1)本发明在多数据中心部署多套数据库集群，并构建集群间的复制通道，当主机房不可用时，在校验完数据后，就可以切换到备用机房的数据库集群，在发生故障时可以保障数据不丢失以及业务强连续性，从而提高整体运维效率；
(2)解决了业务与流量中间件模块通过代理方式访问数据库的难点，既需要对后侧数据库架构变化进行通信，又需要保障数据库发生故障切换时对业务应用层透明无感知；解决了两个数据中部署两套MGR集群，两个集群之间如何保障故障时数据自动同步和切换的技术难点；
(3)本发明通过采用组复制技术为同城双活提供了高一致性、高容错性、高扩展性的技术效果，具体如下：
高一致性：基于原生复制及pasxos协议的组复制技术，提供了一致性数据安全保障，确保组内数据最终一致性；
高容错性：确保组内高可用，只要不是大多数节点故障就可以继续工作，有自动检测机制，当不同节点资源争用冲突时，不会出现错误按照先到者优先原则处理，并内置自动化脑裂防护机制；
高扩展性：新节点的除节点都是自动的，新节点加入后，会自动与其它节点同步，直到新节点与其它节点一致，如果某个节点被移除，其它节点会自动更新组信息，自动维护新组信息。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1为系统框架结构图；
图2为组复制技术模块实现原理图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。
实施例：
如图1，本发明提供了一种基于组复制的MySQL同城多中心的多活实现方法，包括数据中心A和数据中心B，流量控制区；数据中心A中部署了一组带有组复制协议的MySQL集群A实例组，数据中心B中部署一套带有组复制协议的MySQL集群B实例组，流量控制区部署了流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活；同时又引入异步复制故障自动切换技术，在MySQL集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重。当发现主复制源发生故障异常中断后，会先尝试重连几次，然后自动切换到新的复制源。当原来的复制源恢复后，如果其权重更高，还会再切换回去。本发明能做到流量通过流量控制区中间件实现双写多活，同时数据中心内通过组复制方式实现集群内数据同步，数据中心间通过异步复制故障自动切换的方式来实现低延时高可靠的数据同步。
通过采用在数据中心发生故障产生切换动作时，将时间窗口内得不到正常处理的业务信息由数据中心A提供自动转换到数据库中心B提供，由同城双活方案组复制技术进行快速灵活切换，从而达成业务保障的目的。
本发明提供了一种基于组复制的MySQL同城多中心的多活实现系统，提供了组复制技术以及故障自动切换功能。数据中心A和B分别部署一套MGR集群，集群之间通过双向复制进行数据同步。具体包括如下模块：
组复制技术模块：组复制MGR技术是一种高可用系统的技术，其中复制组是由能够相互通信的多个服务器节点组成，在通信层则提供了原子消息和完全信息交互等保障机制，实现基于复制协议的多主更新。复制组由多个服务器组成，每个服务器成员可以独立的执行事务，但所有的读写事务只有在冲突检测成功后才会提交，只读事务则不需要冲突检测。因此，当一个读写事务准备提交的时候，会自动在组内进行原子性的广播，告知其它节点变更了什么内容、执行了什么事务。这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个组内保持了完全一致的状态，如图2。
异步复制故障自动切换模块：其工作机制是在一个复制通道上设置多个复制源，它还支持对多个源设置不同权重。当发现主复制源发生故障异常中断后(会先尝试重连几次)，即可实现自动切换到新的复制源。当原来的复制源恢复后，如果其权重更高，还会再切换回去。
1)业务通过组复制集群的VIP代理访问数据库，对后侧对数据库架构变化和故障切换无任何感知；
2)数据中心A中部署了一组带有组复制协议的MySQL集群A实例组，数据中心B中部署一套带有组复制协议的MySQL集群B实例组；
3)在MySQL Group集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重；当发现主复制源发生故障异常中断后(会先尝试重连几次)，即可实现自动切换到新的复制源；当原来的复制源恢复后，如果其权重更高，还会再切换回去。
组复制中每个节点都有一份完整的数据副本，节点间通过GCS进行交互。GCS层提供了节点间的全局消息及其有序性的保证。
组复制可以做到在任何节点、任何时间都能执行读写事务(不含只读事务)，不过读写事务要被整个复制组确认后才能提交。如果是只读事务则没有这个限制，任何节点都可以发起及提交。
当读写事务准备提交前，它会向复制组发出一个原子广播，内容包括：该事务修改的数据，及其所对应的写集合。复制组中所有节点要么接收该事务，要么都不接收。如果组中所有节点都接收该事务消息，那么它们都会按照与之前发送事务的相同顺序收到该广播消息。因此，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。
在多个节点上并行执行的事务是可能产生冲突的，这时候就需要对比判断两个并行事务的写集合来确认，这个过程称为事务认证，也叫做冲突检测。事务冲突检测是行级别的，也就是说两个并行的事务更新同一行时，则视为产生冲突。这时的做法是全局顺序在前面的事务可以成功，所有节点都提交该事务。而全局顺序在后面的事务会失败回滚，各节点会删除该事务。这实际上是个分布式的谁先提交谁先赢得事务的规则。建议：如果经常发生节点间的事务冲突，那最好将这些事务放在同一个节点上执行，这样它们在本地事务并发控制协调下可能都可以提交成功，而不至于由于组复制的冲突检测而导致某个事务总是被回滚。
对于正在应用或外化的事务，组复制允许它们不一定按照原有顺序执行，只要不破坏事务的一致性和有效性即可。组复制默认要求是最终一致性，也就是说当所有事务都应用完毕后，所有节点的数据是一致的。当流量巨大时，事务可能会被外化而导致顺序轻微不一致。例如在多主模式下，一个本地事务在通过认证后会被立即外化，尽管此时可能还有个比这更早全局顺序的远程事务还没被应用，只要组复制的认证线程认为这个事务不会产生冲突即可。在单主模式下，在主节点上的本地并发事务，在不产生冲突的情况下，其提交和外化的顺序可能和该事物的全局事务顺序有轻微不一致。在从节点上，由于没有写事务，因此它们的事务顺序和全局事务顺序是一致的。
部署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 A，确认工作正常：
[mgrA-1][(none)]>select*from performance_schema.replication_group_members；
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|ME MBER_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|+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
[mgrA-1][(none)]>select@@global.group_replication_group_name；+---------------------------------------+|@@global.group_replication_group_name|+---------------------------------------+|f195537d-19ac-11eb-b29f-5254002eb6d6|+---------------------------------------+
用同样的方法，再部署MGR B，并确认工作正常：
[mgrB-1][(none)]>select*from performance_schema.replication_group_members；
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+|CHANNEL_NAME|MEMBER_ID|MEMBER_HOST|ME MBER_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|+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+[mgrB-1][(none)]>select@@global.group_replication_group_name；+---------------------------------------+|
2、构建MGRA&B的复制通道
按照常规方式，在从实例上(本案以MGR-B为例)创建一个复制通道：
[mgrB-1][(none)]>CHANGE REPLICATION SOURCE TO
MASTER_HOST＝'172.16.16.10',MASTER_PORT＝3306,MASTER_USER＝'repl',
MASTER_PASSWORD＝'repl',MASTER_AUTO_POSITION＝1,
SOURCE_CONNECTION_AUTO_FAILOVER＝1,#这里是关键，表示开启自动故障转移
MASTER_RETRY_COUNT＝3#最多重试3次
MASTER_CONNECT_RETRY＝10#每次重试间隔10秒
FOR CHANNEL'MGR-A'；
-SOURCE_CONNECTION_AUTO_FAILOVER＝1#这里是关键，表示开启自动故障转移
-MASTER_RETRY_COUNT＝3#表示最多重试3次，默认是是86400次
-MASTER_CONNECT_RETRY＝10#表示每次重试间隔10秒，默认是60秒
接下来再对这个复制通道添加多个复制源(多次调用该UDF即可)：
[mgrB-1][(none)]>SELECT
asynchronous_connection_failover_add_source('MGR-A','172.16.16.10',3306,null,60)；
[mgrB-1][(none)]>SELECT
asynchronous_connection_failover_add_source('MGR-A','172.16.16.11',3306,null,60)；
[mgrB-1][(none)]>SELECT
asynchronous_connection_failover_add_source('MGR-A','172.16.16.12',3306,null,60)；
MGR-A#表示复制通道，和上面的复制通道同名
172.16.16.10#表示该复制源的IP
3306#表示该复制源的端口
null#表示network_namespace，未来的特性，现在先放空即可
60#表示该复制源的权重，上面我们介绍了不同权重的作用，值越大越有机会抢到成为复制源
确认多个复制源生效：
[mgrB-1][(none)]>SELECT*FROMperformance_schema.replication_asynchronous_connection_failover；
+--------------+--------------+------+-------------------+--------+--------------+
|CHANNEL_NAME|HOST|PORT|NETWORK_NAMESPACE|WEIGHT|MANAGED_NAME|
+--------------+--------------+------+-------------------+--------+--------------+
|mgr-a|172.16.16.10|3306||60||
|mgr-a|172.16.16.11|3306||60||
|mgr-a|172.16.16.12|3306||60||
+--------------+--------------+------+-------------------+--------+--------------+
本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。

Claims (10)

1.一种基于组复制的MySQL同城多中心的多活实现方法，其特征在于，包括：
在数据中心A中部署一组带有组复制协议的MySQL集群A实例组，在数据中心B中部署一组带有组复制协议的MySQL集群B实例组，在流量控制区部署流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活。
2.根据权利要求1所述的基于组复制的MySQL同城多中心的多活实现方法，其特征在于，基于异步复制故障自动切换技术，在MySQL集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重，当主复制源发生故障异常中断后，先尝试重连几次，然后自动切换到新的复制源，当原来的复制源恢复后，如果其权重更高，则切换回去。
3.根据权利要求1所述的基于组复制的MySQL同城多中心的多活实现方法，其特征在于，组复制中每个节点都有一份完整的数据副本，节点间通过GCS层进行交互；
通过能够相互通信的多个服务器节点组成复制组，每个服务器节点独立执行事务，所有读写事务在冲突检测成功后提交；
当读写事务准备提交前，向复制组发出一个原子广播，内容包括：该事务修改的数据，及其所对应的写集合；如果组中所有节点都接收该事务消息，则都按照与之前发送事务的相同顺序收到该广播消息，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。
4.根据权利要求1所述的基于组复制的MySQL同城多中心的多活实现方法，其特征在于，若在多个节点上并行执行的事务产生冲突，则对比判断两个并行事务的写集合进行确认，判定全局顺序在前的事务成功，所有节点都提交该事务；全局顺序在后的事务失败回滚，各节点删除该事务；若事务产生冲突的频次超出预设阈值，则将该事务放在同一个节点上执行。
5.根据权利要求1所述的基于组复制的MySQL同城多中心的多活实现方法，其特征在于，对于正在应用或外化的事务，在不破坏事务一致性和有效性的前提下，组复制允许它们不一定按照原有顺序执行；当流量超出预设阈值时，事务存在被外化而导致顺序不一致的可能性，若组复制的认证线程判定这个事务不会产生冲突则不处理。
6.一种基于组复制的MySQL同城多中心的多活实现系统，其特征在于，包括：
数据中心A：部署一组带有组复制协议的MySQL集群A实例组；
数据中心B：部署一组带有组复制协议的MySQL集群B实例组；
流量控制区：部署流量分发中间件，业务访问通过中间件分发给数据中心A和数据中心B，实现业务的双写多活。
7.根据权利要求6所述的基于组复制的MySQL同城多中心的多活实现系统，其特征在于，基于异步复制故障自动切换技术，在MySQL集群A实例组和MySQL集群B实例组构建双向复制通道，在每个复制通道上设置多个复制源和不同权重，当主复制源发生故障异常中断后，先尝试重连几次，然后自动切换到新的复制源，当原来的复制源恢复后，如果其权重更高，则切换回去。
8.根据权利要求6所述的基于组复制的MySQL同城多中心的多活实现系统，其特征在于，组复制中每个节点都有一份完整的数据副本，节点间通过GCS层进行交互；
通过能够相互通信的多个服务器节点组成复制组，每个服务器节点独立执行事务，所有读写事务在冲突检测成功后提交；
当读写事务准备提交前，向复制组发出一个原子广播，内容包括：该事务修改的数据，及其所对应的写集合；如果组中所有节点都接收该事务消息，则都按照与之前发送事务的相同顺序收到该广播消息，所有组成员都以相同的顺序接收事务的写集，并为事务建立全局顺序。
9.根据权利要求6所述的基于组复制的MySQL同城多中心的多活实现系统，其特征在于，若在多个节点上并行执行的事务产生冲突，则对比判断两个并行事务的写集合进行确认，判定全局顺序在前的事务成功，所有节点都提交该事务；全局顺序在后的事务失败回滚，各节点删除该事务；若事务产生冲突的频次超出预设阈值，则将该事务放在同一个节点上执行。
10.根据权利要求6所述的基于组复制的MySQL同城多中心的多活实现系统，其特征在于，对于正在应用或外化的事务，在不破坏事务一致性和有效性的前提下，组复制允许它们不一定按照原有顺序执行；当流量超出预设阈值时，事务存在被外化而导致顺序不一致的可能性，若组复制的认证线程判定这个事务不会产生冲突则不处理。
CN202310340370.9A 2023-03-31 2023-03-31 基于组复制的MySQL同城多中心的多活实现方法和系统 Pending CN116910147A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310340370.9A CN116910147A (zh) 2023-03-31 2023-03-31 基于组复制的MySQL同城多中心的多活实现方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310340370.9A CN116910147A (zh) 2023-03-31 2023-03-31 基于组复制的MySQL同城多中心的多活实现方法和系统

Publications (1)

Publication Number Publication Date
CN116910147A true CN116910147A (zh) 2023-10-20

Family

ID=88365551

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310340370.9A Pending CN116910147A (zh) 2023-03-31 2023-03-31 基于组复制的MySQL同城多中心的多活实现方法和系统

Country Status (1)

Country Link
CN (1) CN116910147A (zh)

Similar Documents

Publication Publication Date Title
CN109729129B (zh) 存储集群系统的配置修改方法、存储集群及计算机系统
US9983957B2 (en) Failover mechanism in a distributed computing system
EP2281240B1 (en) Maintaining data integrity in data servers across data centers
US9460183B2 (en) Split brain resistant failover in high availability clusters
US9984140B1 (en) Lease based leader election system
JP3822381B2 (ja) 分散データベースシステム障害回復方法
US20130110781A1 (en) Server replication and transaction commitment
CN113396407A (zh) 用于利用区块链技术扩充数据库应用的系统和方法
US9465650B2 (en) Executing distributed globally-ordered transactional workloads in replicated state machines
TW201514684A (zh) 使用群集資料庫中之儲存快照的推測性回復
CN115794499B (zh) 一种用于分布式块存储集群间双活复制数据的方法和系统
CN105915391B (zh) 基于单阶段提交并具备自恢复功能的分布式键值存储方法
WO2022134876A1 (zh) 数据同步方法、装置、电子设备、存储介质
Mendizabal et al. High performance recovery for parallel state machine replication
CN115098229A (zh) 事务处理方法、装置、节点设备及存储介质
US10728326B2 (en) Method and system for high availability topology for master-slave data systems with low write traffic
CN110489491B (zh) 一种适用于a/b网双集群的全量数据同步装置
CN111813606A (zh) 一种双节点虚拟机容错的方法、系统、设备及介质
CN116910147A (zh) 基于组复制的MySQL同城多中心的多活实现方法和系统
CN116303775A (zh) 日志处理方法、装置、电子设备及存储介质
CN115080661A (zh) 数据库同步方法、装置、管控平台和系统
Zhu et al. To vote before decide: A logless one-phase commit protocol for highly-available datastores
Garcia-Munoz et al. Recovery Protocols for Replicated Databases--A Survey
Siram Witness for Two-Site Enabled Coordination
CN114201473A (zh) 日志管理方法及服务器集群

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination