MySQL金融应用场景下跨数据中心的MGR架构方案(2)
- GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
如何在多个数据中心部署多套MGR集群,并实现故障快速切换。
上篇文章介绍了如何在多数据中心部署多套MGR集群,并构建集群间的复制通道。这样一旦主AZ不可用时,在校验完数据后,就可以切换到备用AZ的MGR集群,非常方便。
本文我们继续深入介绍如何利用 Async Replication Auto failover 实现故障自动转移的。
1、什么是Async Replication Auto failover
从MySQL 8.0.22开始,推出一个新特性"Async Replication Auto failover",当MGR集群发生故障时,其从库可以更方便的实现快速自动切主。直译过来是“异步复制自动故障转移”,但实际上它也是支持半同步复制场景的。
You can use MySQL Server's new asynchronous connection failover mechanism to automatically establish an asynchronous (source to replica) replication connection to a new source after the existing connection from a replica to its source fails. The connection fails over if the replication I/O thread stops due to the source stopping or due to a network failure. The asynchronous connection failover mechanism can be used to keep a replica synchronized with multiple MySQL servers or groups of servers that share data. To activate asynchronous connection failover for a replication channel set SOURCE_CONNECTION_AUTO_FAILOVER=1 on the CHANGE MASTER TO statement for the channel, and set up a source list for the channel using the asynchronous_connection_failover_add_source and asynchronous_connection_failover_delete_source functions.
详细介绍见官方文档 17.4.9 Switching Sources with Asynchronous Connection Failover
2、基于MGR的两地三中心数据库架构方案
在两地三中心架构下,可以采用下面这个部署方案
在这个架构方案里,MGR-B可以采用 异步复制 或 增强半同步复制 通道从MGR-A复制数据,这要取决于两个AZ之间的网络状况。
在金融应用场景下,这个网络条件一般可以得到保障,因此优先采用增强版同步方式。
而跨城异地AZ里的MGR C则因为网络延迟较大,大概率会采用异步复制方式。
在上述方案中,不管是MGR-B还是C,都面临一个问题:那就是复制源指向的主机实例,发生故障不可用之后,如何快速切换,实现自动故障转移。
在以往,只能靠第三方工具实现切换。
在MySQL 8.0.22新增"Async Replication Auto failover"特性后,就没这个烦恼了。
其工作机制是 在一个复制通道上设置多个复制源(source),它还支持对多个源设置不同权重。当发现主复制源发生故障异常中断后(会先尝试重连几次),即可实现自动切换到新的复制源。当原来的复制源恢复后,如果其权重更高,还会再切换回去。
3、配置Async Replication Auto failover
部署的过程很简单,几条命令就搞定了。
3.1、创建复制通道
按照常规方式,在从实例上(本案以MGR-B为例)创建一个复制通道
[root@GreatSQL 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秒
确认添加的复制通道生效了:
[root@GreatSQL mgrB-1][(none)]> SELECT * FROM performance_schema.replication_applier_status\G
*************************** 1. row ***************************
CHANNEL_NAME: mgr-a
SERVICE_STATE: ON
REMAINING_DELAY: NULL
COUNT_TRANSACTIONS_RETRIES: 0
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
SERVICE_STATE: ON
REMAINING_DELAY: NULL
COUNT_TRANSACTIONS_RETRIES: 0
3.2、对复制通道添加多个复制源
接下来再对这个复制通道添加多个复制源(多次调用该UDF即可):
[root@GreatSQL mgrB-1][(none)]> SELECT asynchronous_connection_failover_add_source('MGR-A','172.16.16.10',3306,null,60);
[root@GreatSQL mgrB-1][(none)]> SELECT asynchronous_connection_failover_add_source('MGR-A','172.16.16.11',3306,null,60);
[root@GreatSQL 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 #表示该复制源的权重,上面我们介绍了不同权重的作用,值越大越有机会抢到成为复制源
确认多个复制源生效:
[root@GreatSQL mgrB-1][(none)]> SELECT * FROM performance_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 | |
+--------------+--------------+------+-------------------+--------+--------------+
启动该复制通道:
[root@GreatSQL mgrB-1][(none)]> START REPLICA FOR CHANNEL 'MGR-A';
确认复制通道和MGR的状态都正常:
[root@GreatSQL mgrB-1][(none)]> SELECT * FROM performance_schema.replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME: mgr-a
GROUP_NAME:
SOURCE_UUID: b084f8a1-96a8-11eb-9a70-525400fb993a
THREAD_ID: 3084
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 5974
LAST_HEARTBEAT_TIMESTAMP: 2021-05-29 18:53:13.879720
RECEIVED_TRANSACTION_SET: 476c0276-be03-11eb-bd34-525400e802e2:21-31:1000016-1000017
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION: 476c0276-be03-11eb-bd34-525400e802e2:31
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 2021-05-27 17:19:43.201000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2021-05-27 17:19:43.203315
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2021-05-27 17:19:43.203349
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
GROUP_NAME: f195537d-19ac-11eb-b29f-5254002eb6d6
SOURCE_UUID: f195537d-19ac-11eb-b29f-5254002eb6d6
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
RECEIVED_TRANSACTION_SET: 476c0276-be03-11eb-bd34-525400e802e2:1-31:1000015-1000017,
f195537d-19ac-11eb-b29f-5254002eb6d6:1-18
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION: f195537d-19ac-11eb-b29f-5254002eb6d6:18
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2021-05-27 17:04:03.407281
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2021-05-27 17:04:03.407317
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
执行 SHOW REPLICA STATUS 查看状态:
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: 172.16.16.10
Source_User: repl
Source_Port: 3306
Connect_Retry: 10
...
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
...
Source_UUID: 5499a6cb-91cb-11eb-966f-525400e802e2
...
Source_Retry_Count: 3
...
Retrieved_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:21-31:1000016-1000017
Executed_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:1-31:1000015-1000017,
f195537d-19ac-11eb-b29f-5254002eb6d6:1-18
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name: mgr-a
...
先记住上面输出结果中的 Source_Host 和 Source_UUID 等信息,下面模拟一次复制源服务器宕机后,自动切换复制源的场景。
4、模拟故障,确认可自动切换
在当前复制源服务器上,执行 kill -9 杀掉 mysqld 进程,然后就能看到从服务器上有类似如下日志:
# 先尝试3次(每次间隔10秒)重连旧的复制源服务器
[ERROR] [MY-010584] [Repl] Slave I/O for channel 'mgr-a': error connecting to master 'repl@172.16.16.10:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '172.16.16.10:3306' (111), Error_code: MY-002003
#重试失败,停止复制I/O线程
[Note] [MY-010563] [Repl] Slave I/O thread for channel 'mgr-a' killed while connecting to master
[Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
# 再次启动复制I/O线程,连接到新的复制源服务器
[System] [MY-010562] [Repl] Slave I/O thread for channel 'mgr-a': connected to master 'repl@172.16.16.11:3306',replication started in log 'FIRST' at position 8598
# 告知UUID发生切换了
[Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was ec2fcbeb-976c-11eb-a652-525400e2078a.
再次执行 SHOW REPLICA STATUS 确认复制源切换了:
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: 172.16.16.11
Source_User: repl
Source_Port: 3306
Connect_Retry: 10
...
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
...
Source_UUID: ec2fcbeb-976c-11eb-a652-525400e2078a
...
Source_Retry_Count: 3
...
Retrieved_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:21-32:1000016-1000017
Executed_Gtid_Set: 476c0276-be03-11eb-bd34-525400e802e2:1-32:1000015-1000017,
f195537d-19ac-11eb-b29f-5254002eb6d6:1-18
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name: mgr-a
...
因为3个复制源的权重设置为一样,所以当原来的复制源服务器宕机恢复后,不会再切换回去。而如果旧的复制源服务器权重设置较高的话,当他恢复后,会再次发生切换,切回原来的源:
#没有任何尝试重连的行为,直接发起切换
[Note] [MY-011026] [Repl] Slave I/O thread killed while reading event for channel 'mgr-a'.
[Note] [MY-010570] [Repl] Slave I/O thread exiting for channel 'mgr-a', read up to log 'FIRST', position 8871
[Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[System] [MY-010562] [Repl] Slave I/O thread for channel 'mgr-a': connected to master 'repl@172.16.16.10:3306',replication started in log 'FIRST' at position 8871
[Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 5499a6cb-91cb-11eb-966f-525400e802e2. -- 再次切回原来的主
这就很方便的可以实现自动故障转移了。
现在,我们利用MGR + 增强半同步复制 + 自动故障转移 构建了一套金融级应用场景下的两地多中心数据库架构方案。推荐选用可靠性、稳定性更高的GreatSQL,可以更放心的使用MGR(GreatSQL,打造更好的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金融应用场景下跨数据中心的MGR架构方案(2)的更多相关文章
- MySQL金融应用场景下跨数据中心的MGR架构方案(1)
GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源. 0. 内容提纲 运行环境 部署MGR A&B 部署MGR A.B之间的复制通道 几个注意事项 如何在多个数据中心部 ...
- Cassandra 如何处理跨数据中心的数据库延时问题
分布式系统的可靠.延时.一致性等问题是一般性问题,不局限于数据库,而Cassandra提供了一个很好的解决思路. Cassandra号称能做到跨数据中心的数据库访问的高效访问,它的实现方式其实是把延时 ...
- 原生Redis跨数据中心双向同步优化实践
一.背景 公司基于业务发展以及战略部署,需要实现在多个数据中心单元化部署,一方面可以实现多数据中心容灾,另外可以提升用户请求访问速度.需要保证多数据中心容灾或者实现用户就近访问的话,需要各个数据中心拥 ...
- SQL Azure (17) SQL Azure V12 - 跨数据中心标准地域复制(Standard Geo-Replication)
<Windows Azure Platform 系列文章目录> 熟悉Microsoft Azure平台的读者都了解,Azure SQL Database提供不同等级的,跨数据中心的异地冗余 ...
- Azure SQL Database (24) 使用新管理界面,创建跨数据中心标准地域复制(Standard Geo-Replication)
<Windows Azure Platform 系列文章目录> 文本是对:SQL Azure (17) SQL Azure V12 - 跨数据中心标准地域复制(Standard Geo-R ...
- Windows Azure Virtual Network (13) 跨数据中心之间的虚拟网络点对点连接VNet Peering
<Windows Azure Platform 系列文章目录> 今天是大年初二,首先祝大家新年快乐,万事如意. 在笔者之前的文章中:Windows Azure Virtual Networ ...
- Uber如何搭建一个基于Kafka的跨数据中心复制平台 原创: 徐宏亮 AI前线 今天
Uber如何搭建一个基于Kafka的跨数据中心复制平台 原创: 徐宏亮 AI前线 今天
- 大规模SDN云计算数据中心组网的架构设计
本文首先分析了在大规模SDN数据中心组网中遇到的问题.一方面Underlay底层组网规模受限于设备实际的转发能力和端口密度,单一Spine-leaf的Fabric架构无法满足大规模组网的需求:另一方面 ...
- [转]漫谈数据中心CLOS网络架构
http://djt.qq.com/article/view/238 1.数据中心网络架构挑战 随着技术的发展,数据中心的规模越来越大,一个数据中心的服务器容量从几年前的几千台服务器发展到今天的几万甚 ...
随机推荐
- unity---UI管理模块
UI管理器 任务: 1.所有面板的父类,2.UIMgr 所有UI控件都继承UIBehaviour 面板基类 找到相应空间 简化后 也存在问题:一个物体可以同时挂载两个组件 导致键相同,而值不同, 将值 ...
- jQuery基础入门+购物车案例详解
jQuery是一个快速.简洁的JavaScript代码库(或JavaScript框架).jQuery设计的宗旨是"write Less,Do More",即倡导写更少的代码,做更多 ...
- CF1601F Two Sorts
CF1601F Two Sorts 给定 \(n\),将 \(1\sim n\) 按照字典序排序,\(a_i\) 表示第 \(i\) 小的数,求: \[\left(\sum_{i=1}^{n} ((i ...
- PostgreSQL Array 数组类型与 FreeSql 打出一套【组合拳】
前言 PostgreSQL 是世界公认的功能最强大的开源数据库,除了基础数据类型 int4/int8/varchar/numeric/timestamp 等数据类型,还支持 int4[]/int8[] ...
- 深入C++05:运算符重载
运算符重载 1.复数类 运算符重载目的:使对象运算表现得和编译器内置类型一样: 复数类例子 #include<iostream> using namespace std; class CC ...
- Camunda如何适配国产数据库达梦
前言 camunda流程引擎官方支持的数据库有:MySQL .MariaDB .Oracle .DB2 .PostgreSQL .SQL Server.H2.对于其他类型的数据库如何支持,尤其是国产数 ...
- SpringBoot2.x整合Prometheus+Grafana【附源码+视频】
图文并茂,新手入门教程,建议收藏 SpringBoot2.x整合Prometheus+Grafana[附源码+视频] 附源码+视频 目录 工程简介 简介 Prometheus grafana Spri ...
- C语言学习之我见-memchr()内存查找字符函数
memchr()内存查找字符函数:主要用于从内存中查找自己需要的字符位置. (1)函数原型: void *memchr(const void *_Buf ,int _Val,size_t _MaxCo ...
- 使用c++爬取股市数据,获取最新行情
最近自己动手写个小软件(界面原生态,还没来得及加样式哈).每天看看潜力股懒人做法,不介意推荐.资源有限,只能观察一下低价股,分析一下运动规律,什么时候拉升,惯性如何 主要功能:读取网络数据:保存本地数 ...
- 安装pystaller
安装命令 # -i指定下载地址,此处采用清华大学镜像 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple some-package pyin ...