MySQL-Operator容器化方案概述_第1页
MySQL-Operator容器化方案概述_第2页
MySQL-Operator容器化方案概述_第3页
MySQL-Operator容器化方案概述_第4页
MySQL-Operator容器化方案概述_第5页
已阅读5页,还剩1页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

MySQLOperator容器化方案概述

【导读】与内存库的Redis数据库比起来,容器化MySQL有着更多的需求,本文介绍了MySQLOpreator容器化方案及设计思路。以前文章分享过RedisOperator容器化方案(点击标题可阅读:《RedisSentinelOperator容器化解读》,《RedisClusterOperator容器化方案》),本次介绍MySQLOperator容器化方案。与内存库的Redis数据库比起来,容器化MySQL有着更多的需求,主要有以下三个方面:MySQL对存储的要求很高MySQLPod的IP需要固定MySQL需要支持同城灾备MySQL容器化拓扑结构固定MySQLPodIP可以在K8S上使用Calico网络插件实现。存储方面使用高性能分布式存储或者直接挂载本地盘都可达到要求,这些不在本文做重点介绍。MySQL容器化有同城灾备需求。对于MySQL部分,我们使用MySQLMGR单主模式,将MGR节点分散在本地/同城运行,正常情况下主节点运行在本地,灾备切换时将主节点切换至同城。对于K8S集群部分,我行K8S集群没有进行跨本地/同城部署,所以MySQLMGR节点会分布在两个K8S集群运行。对于MySQL服务暴露部分,在每个K8S集群上为每个MGR集群各建立Read、WriteService,通过K8SService机制对外暴露MySQL服务。整体拓扑结构如下所示:MySQLOperator功能逻辑MySQLOperator的功能包括MGR集群创建、集群维护、CPU内存资源升级、MGR节点扩缩容、节点迁移等。由于MGR集群跨K8S部署,所以在Operator的逻辑上不能只管控本地资源,还需关注在同城运行的那一部分MGR节点的情况。MGR集群创建在MySQLMGR集群CR资源定义中包含以下三个字段:flag字段为primary标识MGR的主应该在本地ipList定义部署在本地K8S集群的MGRPod列表,以及具体的PodIP和所在K8S节点remoteList定义部署在同城K8S集群的MGRPod列表;本地Operator会通过该字段中的IP地址尝试连接同城MGR节点,以判断同城MGR节点是否连通以及角色是否正常spec:

flag:

"primary"

ipList:

-

ip:

""

nodeName:

"abc"

remoteList:

-

ip:

""

nodeName:

"abc"在MGR集群创建流程中,两边Operator均需确定ipList和remoteList中的PodIP地址均可连通,确定MGR集群所属的Pod均已启动后才能执行MGR集群的创建工作。创建的时候,flag为primary侧的Operator会在本K8S集群中选出一个MGRPod进行主节点的引导启动,其余本地Pod和flag为standby侧集群的Pod均启动为从节点。MGR集群维护集群维护功能是为了保证MGR集群按照预期运行,集成了各种异常场景下处理逻辑,主要包括以下几个部分:保证Service、PVC、Configmap等需要的K8S资源按照预期创建保证MySQLPod数量和运行状态正常保证MySQLPod的角色标签和实际的MGR角色一致维持Pod内的MySQLMGR进程启动判断MGR主节点是否切换,并进行切主后操作等除了Operator的集群维护功能,另一个保证服务持续可用的是MySQL自身的MGR机制。在整体设计中,我们对Operator和MGR两种机制管控范围的做了清晰的边界划分:即Operator只保证MGR运行所需的环境正常,如节点数、进程启动状态、配置等正常,但涉及到主节点切换等MGR机制内部的事情,Operator只做观察并把最新状态反映到CR的Status字段中而不去做干预。在Operator的设计中,只有三种情况会进行主节点干预:一是集群新建的情况;二是在确认所有集群节点都为从节点的情况,选出gtid最大的节点启动为主;三是收到灾备切换的请求,会将主切到flag=primary的一侧。MGR集群运维操作Operator支持对MGR集群进行一些常规的运维操作,包括本地/同城节点的上线、下线,Pod内存、CPU资源的扩缩容、Pod使用镜像的更换以及MySQL的配置文件更新等。Operator最重要的任务是维持集群正常运行,对于这些运维操作在设计时采用了一个稳妥的方案:所有的运维操作必须基于维护流程判断集群状态正常(有且仅有一个主节点,其余节点均运行正常且为从节点)的情况下才可进行在状态转换流程中设置操作的优先级,先进行优先级高的操作,如新加节点的优先级高于删除节点的优先级如果涉及到类似于多个节点添加的批量操作,Operator会将批量操作拆分为单个操作的顺序执行,每步操作完成后确认集群状态正常才能继续下一步操作整体流程如下图所示:MGR集群灾备切换灾备切换包含两部分:第一部分是MGR集群的主节点切换到同城集群;第二部分是客户端网络流量打到同城集群。对于第二部分的实现有手动改客户端访问地址、更改DNS指向、使用代理转发等多种方法,本文不做讨论。对于第一部分,Operator做了一个便捷化的实现,在检测到flag字段由standy变为primary的时候会主动发起一次切主操作,试图将主切换到现在的primary这边。要

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论