Kubernetes Operator 实践 —— MySQL 容器化 刘林 搜狗资深工程师 关于我 搜狗商业平台研发部 资深开发工程师 l 主要从事商业平台研发工作，在构建高性能、高可用大规模 系统方面有丰富的实践经验 l 目前专注于云计算、DevOps 等相关领域，负责搜狗商业云 平台的设计研发工作 刘林 1. 背景介绍 2. Operator 的基本原理 3. MySQL Cluster2 Node Node Node Node 商业云平台 BizCloud • 弹性伸缩能力不足 • 机器资源利用率不高 • 服务管理复杂 问题 有状态服务的需求越来越多 有状态服务容器化 1. 背景介绍 2. Operator 的基本原理 3. MySQL Operator 设计实践 4. 小结 无状态服务 服务调度 有状态服务集群 服务调度 状态保存 集群管理 MySQL Operator 设计实践 4. 小结 MySQL 容器化目标 • 快速部署 MySQL 主从集群 • 支持 MySQL 集群高可用 • 支持 MySQL 集群弹性伸缩 • 支持 MySQL 5.5 & 5.7 Master Slave1 Slave2 MySQL 集群：1 主 2 从 MySQL 容器化系统架构 REST CLI Kubernetes Master

Greenplum on Kubernetes 容器化MPP数据库 AGENDA 云数据库背景 云数据库实现方案 Greenplum on Kubernetes Greenplum Operator 总结 云数据库背景 云数据库背景 ● 资源变化 ○ 本地资源 → 云 ○ 静态资源 → 弹性需求 ● 数据变化 ○ 内部数据 → 多数据源 ○ 数据规模 → 不易预测 ○ 数据格式 网络传输 ○ 权限控制 ● 跨云 ○ 公有云 ○ 私有云 云数据库实现方案 ● 全新数据库 ○ Snowflake ● 原有数据库架构升级 ○ Vertica Eon Mode ● 容器化数据库+Kubernetes ○ Apache Spark ○ CockroachDB ○ Apache HAWQ 云数据库存储方案 ● 块存储 ○ 文件系统接口 ● 对象存储 ○ Segment Instance Segment 5 (Mirror) 容器化Greenplum ? + = 容器化Greenplum ● 容器粒度 ○ Segment主机 VS. Segment实例 ● 容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络 ○ 跨机网络 ● 容器化Greenplum部署策略 ○ Master部署策略 ○ Primary

《MySQL 容器化部署实践》 演讲者／王晓波 背景 ■ 同程旅游早期的数据库都以单库的MySQL。 ■ MySQL的单库，导致TPS最终还是会成为一个瓶颈。 ■ MySQL+DB中间件解决水平拆分问题。 ■ MySQL水平拆分的引入会使数据库实例数量大幅上升,传统运维手段维护成本高,交付能力差。 MySQL数据库为何要Docker化 1.MySQL数据库迅速爆炸式增长后，服务器规模不断增大，快速部署是个问题。 Docker在同程的大规模使用，应用部署环境100%容器化，有Docker丰富的经验 。 让数据库的部署点单化开启 2核4G 4核4G 4核8G 8核8G 8核16G 16核16G 16核64G 32核64G 32核128G 一主一从 分片集群 一主多从 SATA-SSD PCIE-SSD 大容量磁盘SAS 配置 DB架构 硬件选型 机房 A机房 B机房 C机房 D机房 容器化之后的MySQL就是一个私有DB云 数据校验 实例迁移 秒级监控诊断 慢日志分析 资源池调度 调度规则 容器调度 资源池 容器及实例创建 应用交付 资源申请 IO类型 配置 为了保证MySQL的高可用，需要在Docker容器分配时如何保障主从不在同一宿主机上。我们通过自研 Docker容器调度平台管理所有宿主机和容器,自定义Docker容器的分配算法。实现了MySQL的高密度,隔离 化,高可用化部署。 调度规则： 1

MANAGED | 自定义 JDBC：使用了 JDBC 的提交和回滚设置，依赖于从数据源得到的连接来管理事务 范 围。 JdbcTransactionFactory MANAGED：不提交或回滚一个连接、让容器来管理事务的整个生命周期（比如 JEE 应用服务器的上下文）。 ManagedTransactionFactory 自定义：实现 TransactionFactory 接口，type=全类名/别名 UNPOOLED：不使用连接池， UnpooledDataSourceFactory POOLED：使用连接池， PooledDataSourceFactory JNDI： 在 EJB 或应用服务器这类容器中查找指定的数据源 自定义：实现 DataSourceFactory 接口，定义数据源的获取方式。 7) 实际开发中我们使用 Spring 管理数据源，并进行事务控制的配置来覆盖上述配置 JAVAEE 命名参数 为参数使用@Param 起一个名字，MyBatis 就会将这些参数封装进 map 中，key 就是我 们自己指定的名字 4) POJO 当这些参数属于我们业务 POJO 时，我们直接传递 POJO 5) Map 我们也可以封装多个参数为 map，直接传递 6) Collection/Array 会被 MyBatis 封装成一个 map 传入, Collection 对应的 key 是 collection

........................................................................................... 11 利用容器实现安全分析 ............................................................................................ 功能，策略配置淘汰的冷内存交换到用户态存储，用户无感知，性能 优于内核态 swap。 2. 夯实云化基座 容器操作系统 KubeOS：云原生场景，实现 OS 容器化部署、运维，提供与业务容器一致的基于 K8S 的管理体验。 • 安全容器方案：iSulad+shimv2+StratoVirt 安全容器方案，相比传统 docker+qemu 方案，底噪和启动时间 优化 40%。 • 双平面部署工具 特性，运行符合 ANSI 标准 的 SQL，可以让服务器群集能够以单一数据超级计算机的方式运行，且性能比传统数据库或其他同类平台高出数十甚 至数百倍。其多种分析扩展功能支持 ANSI SQL，并通过封装扩展提供多种内置语言和附加功能。Greenplum 能够 管理各种规模的数据容量，数据量从数 GB 到数 PB 不等。 Greenplum 环境适用性强与其开放性、真正开源、社区活跃有密不可分的关系，一方面

(SQLException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } 上边使用 jdbc 的原始方法（未经封装）实现了查询数据库表记录的操作。 1.1.2 jdbc 编程步骤： 1、 加载数据库驱动 2、 创建并获取数据库链接 3、 创建 jdbc statement 对象 4、 设置 sql 语句 where 条件不 一定，可能多也可能少，修改 sql 还要修改代码，系统不易维护。 4、 对结果集解析存在硬编码（查询列名），sql 变化导致解析代码变化，系统不易维护，如 果能将数据库记录封装成 pojo 对象解析比较方便。 1.2 MyBatis 介绍 MyBatis 本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundation foundation 迁移到了google code，并且改名为MyBatis，实质上Mybatis对ibatis进行一些 改进。 MyBatis是一个优秀的持久层框架，它对jdbc的操作数据库的过程进行封装，使开发者 只需要关注 SQL 本身，而不需要花费精力去处理例如注册驱动、创建connection、创建 statement、手动设置参数、结果集检索等jdbc繁杂的过程代码。 Mybatis通过xm

Simple、Dataflow 这两种基于 class 的作业类型，并提供 Script、HTTP 这两种基于 type 的作业类型，用户可通过实现 SPI 接口自行扩展作业类型。 简单作业 意为简单实现，未经任何封装的类型。需实现 SimpleJob 接口。该接口仅提供单一方法用于覆盖，此方法 将定时执行。与 Quartz 原生接口相似，但提供了弹性扩缩容和分片等功能。 public class MyElasticJob 现核心作业逻辑并辅以少量配置，即可利用轻量、无中心化的 ElasticJob 解决分布式调度问题。 作业配置 实现作业逻辑 作业逻辑实现与 ElasticJob 的其他使用方式并没有较大的区别，只需将当前作业注册为 Spring 容器中的 bean。 线程安全问题 Bean 默认是单例的，如果该作业实现会在同一个进程内被创建出多个 JobBootstrap 的实例，可以考 虑设置 Scope 为 prototype。 @Component 为作业名称，value 为作业类型与配置。Starter 会根据该配置自 动创建 OneOffJobBootstrap 或 ScheduleJobBootstrap 的实例并注册到 Spring 容器中。 配置参考： elasticjob: regCenter: serverLists: localhost:6181 namespace: elasticjob-springboot jobs:

MySQL，PostgreSQL，Oracle，SQLServer 以及任何 可使用 JDBC 访问的数据库。 1.1.2 ShardingSphere-Proxy 定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支 持。目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使 用任何兼容 3.1.2 ShardingSphere-Proxy ShardingSphere‐Proxy 是 Apache ShardingSphere 的第二个产品。它定位为透明化的数据库代理端，提 供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前提供 MySQL 和 PostgreSQL （兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 ds2.username=root spring.shardingsphere.datasource.ds2.password= 使用 JNDI 数据源 如果计划使用 JNDI 配置数据库，在应用容器（如 Tomcat）中使用 ShardingSphere‐JDBC 时，可使 用 spring.shardingsphere.datasource.${datasourceName}.jndiName

MySQL，Oracle，SQLServer，PostgreSQL 以及任何 遵循 SQL92 标准的数据库。 1.1.2 ShardingSphere-Proxy 定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支 持。目前提供 MySQL 和 PostgreSQL（兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使 用任何兼容 3.1.2 ShardingSphere-Proxy ShardingSphere‐Proxy 是 Apache ShardingSphere 的第二个产品。它定位为透明化的数据库代理端，提 供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前提供 MySQL 和 PostgreSQL （兼容 openGauss 等基于 PostgreSQL 的数据库）版本，它可以使用任何兼容 table_inline.props. algorithm-expression=t_order_${order_id % 2} 使用 JNDI 数据源 如果计划使用 JNDI 配置数据库，在应用容器（如 Tomcat）中使用 ShardingSphere‐JDBC 时，可使 用 spring.shardingsphere.datasource.${datasourceName}.jndiName

MySQL，Oracle，SQLServer，PostgreSQL 以及任何 遵循 SQL92 标准的数据库。 1.1.2 ShardingSphere-Proxy 定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支 持。目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL/PostgreSQL 协议的访问客户端 (如：MySQL =, >, <, >=, <=, IN 和 BETWEEN AND 的分片操作支持。ComplexShardingStrategy 支持多分片键，由于多分片键之间的关系复杂，因此并 未进行过多的封装，而是直接将分片键值组合以及分片操作符透传至分片算法，完全由应用开发者实现， 提供最大的灵活度。 • Hint 分片策略 对应 HintShardingStrategy。通过 Hint 指定分片值而非从 数据库原生的返回结果集的方式最为契合。遍历、排序以及流式分组都属于流式归并的一种。 内存归并则是需要将结果集的所有数据都遍历并存储在内存中，再通过统一的分组、排序以及聚合等计 算之后，再将其封装成为逐条访问的数据结果集返回。 装饰者归并是对所有的结果集归并进行统一的功能增强，目前装饰者归并有分页归并和聚合归并这 2 种 类型。 3.1. 数据分片 41 Apache ShardingSphere