原创力文档- 1、本文档共6页，可阅读全部内容。
- 2、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。
- 3、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 5、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 6、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
?
?
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最重要的任务是维持集群正常运行，对于这些运维操作在设计时采用了一个稳妥的方案：
所有的运维操作必须基于维护流程判断集群状态正常（有且仅有一个主节点，其余节点均运行正常且为从节点）的情况下才可进行
在状态转换流程中设置操作的优先级，先进行优先级高的操作，如新
文档评论（0）