共计 3211 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章主要介绍“基于 Maxwell 的 MySQL 数据传输服务整体设计方法教程”，在日常操作中，相信很多人在基于 Maxwell 的 MySQL 数据传输服务整体设计方法教程问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”基于 Maxwell 的 MySQL 数据传输服务整体设计方法教程”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
1. 系统整体设计
系统的整体设计图如下：
其中 DTS 为平台前端，可以采用专业前端团队支持。
数据传输系统 DTS 为独立的业务系统，目前为重新构建，为实现初步初版，基线版本为数据库运维系统的当前版本，后续只维护 DTS 侧相关逻辑。
其中 DTS 为了考虑后续的扩展性和可维护性，会基于 reader,write,service 三个大体的模块来构建，reader,writer 可以根据具体的技术方向进行细分。
关联系统为数据库运维系统，任务系统，大数据管理系统，对于这些关联系统的元数据和部分逻辑功能会有相关调用。
整个数据传输服务流程中，一个基础的属性是 task_code, 这是在 DTS 任务新建，中端数据传输，后端服务集成中的共同属性，task_code 的含义即为 client_id, 格式为：dts_[idc]_[maxwell_ip]_[maxwell_code]，后端服务的 topic 会基于 client_id 附加数据库和表信息组合而成。
当在 DTS 前端页面中输入了基础信息 (如数据库 IP, 端口等) 后，会调用中端的服务接口生成相应的 client_id，后端服务会根据 DTS 任务列表中的 task_code 为基准进行任务管理，而中端服务会根据 client_id 进行相应的同步对象配置管理 / 服务启停等操作。
相关的数据传输流如下：
2. 中端管理设计
中端管理主要是基于 Maxwell 的部署管理，配置管理，同步对象列表变更，服务管理(启动，停止)，服务自管理和监控报警，目前的实现主要基于 API，初步实现本地前端。
2.1. 部署管理
部署管理主要是对 Maxwell 服务部署实现平台化管理，目前 Maxwell 应用服务器有 2 台，分别是 130.200 和 130.201，档案数据库为 Maxwell 服务基础配置数据和 Maxwell 启动初始化的数据库基础元数据。
通过平台化部署能够实现如下的几个功能：
1)能够实现自动寻址，为 Maxwell 新增同步任务匹配相应的应用服务器，在后续新增应用服务器的情况下能够快速调整和适配
2)如果已在服务器 A 上部署了实例 B 的 maxwell 服务，则新增数据同步任务时，需要复用已有的 maxwell 服务配置，不需要在新的服务器中重新配置。
3)服务配置的基础准备工作，如 Maxwell 相关的账号和防火墙开通等工作，需要通过脚本化管理方式支持，以 API 形式提供接入，目前统一的 maxwell 接入账户为：dba_maxwell_repl
① 数据库主库 Master 端开通防火墙权限，创建相应的数据库账户
② 数据库从库 Slave 端开通防火墙权限
4)MySQL 服务的拓扑管理基于数据库运维管理系统，需要封装相应的 API 得到 Slave 信息，同时需要在 Maxwell 配置列表中维护管理。
补充：
前置任务：
在 130.201 服务器上面部署 Maxwell 修正版服务
基于测试环境完成 Maxwell 的接入测试，producer 为 stdout
后续的开发可以参考如下的实现点：
① 完成 Maxwell 模板化配置
② 可以配置模板生成定制化配置，封装统一的启停脚本
③ Maxwell 自动寻址逻辑，同一个实例只能复用一个 Maxwell 进程服务
④ Client_id 生成逻辑
⑤ Maxwell code 生成逻辑
⑥ 基于运维系统封装 DTS 侧的接口，实现防火墙开通管理和新建复制用户功能，新建用户在 Master, 权限开通在 Master 和 Slave 端
⑦ 对于 stdout 和 Kafka 配置，实现互斥逻辑
2.2. 配置管理
配置管理包含 maxwell 基础的配置文件，如 config 配置，日志配置和监控配置。目录规划设计如下：
可以在这个基础上进行服务的相应扩展。
Maxwell 的基础配置依赖于 client_id
uuml; client_id 元数据命名
dts_[idc]_[maxwell_ip]_[maxwell_code]
如 Maxwell 部署在服务器 121.240，
Maxwell001 为业务编码，可以映射到相应的数据库服务(如 Slave)，为了方便标识和 解析，不允许包含特殊符号，如下划线等
命名示例则为：dts_xxxx_121_240_maxwell001
对于实现细节可以整理为如下的部分：
1)支持根据模板配置化生成相应的 maxwell 配置文件，配置文件命名以 client_id 元数据命名，格式为：dts_[idc]_[maxwell_ip]_[maxwell_code].properties, 配置文件部署在 app_config 目录下。
如 Maxwell 部署在服务器 130.200，
Maxwell001 为业务编码，可以映射到相应的数据库服务(如 Slave)，为了方便标识和 解析，不允许包含特殊符号，如下划线等
命名示例则为：dts_xxxx_130_200_maxwell001.properties
2)对于 Maxwell 基础信息的配置，因为基于 client_id，不便于显示源端的关联关系，该配置信息的管理需要统一在 maxwell 档案库中维护。
3)基础配置信息包括源端服务信息，源服务端口，复制账户信息，client_id，归属 maxwell 应用服务器，监控端口，过滤列表，bootstrap_type(sync,async), kafka 配置信息等
4)基础配置管理需要实现本地前端
补充：
完成 Maxwell 服务列表和服务配置的平台化管理，后端均为 API 实现
如果任务配置发生变更时，服务列表和详情列表为一对多的关系，即需要保留已有的配置文件记录，然后将原记录状态置为失效，使得在出现异常回退的时候，该任务依然可以保证服务可用。
2.3. 同步对象列表变更
同步对象列表为数据传输中的重点管理对象，需要实现如下的功能：
1)对已有的 maxwell 服务新增表时，需要在已有的 maxwell 服务下进行扩展，修改同步对象列表，列表的修改模式为追加，暂不支持修改，删除等其他模式。
2)修改同步列表后，需要对 maxwell 服务进行重新启动，需要保证启动过程相对是平滑可控。
3)如同步列表刷新失败，需要能够快速回退，快速恢复数据传输服务。
4)配置文件版本管理和归档，对象变更前，需要对配置文件先做备份，并规范备份文件命名。
补充：
主要实现同步对象的修改和管理，添加相应的正则配置，调用明细管理的方法 / 接口
2.4. 服务管理
能够实现 maxwell 的启停管理功能，包含三个子选项;start，stop，restart
通过 API 模式进行服务状态检查，目前可以复用已有的开放接口
2.5. 服务自启动
在传输链路中，如果因为源端服务异常，maxwell 侧异常或者后端传输服务异常，会导致 Maxwell 服务异常终止，需要通过探测的模式进行检查复核，确认后重新拉起服务，保证 maxwell 服务的持续性。
补充:
开发相应的脚本，能够进行服务状态检测，并复用已有监控的 API 进行数据传输状态的检测。
3.6. 监控报警
监控报警为 maxwell 基础保障功能，需要完成对 Maxwell 服务的数据传输监控，解析 binlog 的吞吐量，下推 Kafka 的吞吐量等，并对数据传输异常，服务异常等异常场景进行报警提示。
补充：
配置相应的报警明细项目，设定阈值，进行报警配置
到此，关于“基于 Maxwell 的 MySQL 数据传输服务整体设计方法教程”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
