《MySQL 容器化部署实践》 演讲者／王晓波 背景 ■ 同程旅游早期的数据库都以单库的MySQL。 ■ MySQL的单库，导致TPS最终还是会成为一个瓶颈。 ■ MySQL+DB中间件解决水平拆分问题。 ■ MySQL水平拆分的引入会使数据库实例数量大幅上升,传统运维手段维护成本高,交付能力差。 MySQL数据库为何要Docker化 1.MySQL数据库迅速爆炸式增长后，服务器规模不断增大，快速部署是个问题。 大量数据量小的数据库系统也单独部署在物理机，浪费问题突出。 4.DBA的数据库自动化标准化运维的需求。 5.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 7的MGR复制集群是我们自己写的一套 高可用组件配合DB中间，实现无感知的高可用切 换。 兼容mysql协议 支持SELECT/INSERT/UPDATE/DELETE语句 支持单DB实例上的inner join 支持单DB实例上的事务 支持聚合函数：max、min、sum、avg、count 支持：distinct、order by、group by、limit、 top:definition

 切换需要 1s 左右的时间。 2.4 方案实战 2.4.1 适用场景 这个方案适用于只有两台数据库服务器并且还没有实现数据库的读写 分离的情况，读和写都配置 VIP。这个方案能够便于单台数据库的管理 维护以及切换工作。比如进行大表的表结构更改、数据库的升级等都是 非常方便的。 2.4.2 实战环境介绍 服务器名 IP VIP 系统 Mysql Master 10 在启动或者恢复后会立即替换掉定义的 sorry_server，因此如果要实现指 定条件替换或者不替换需要通过其他方式实现，比如：临时更改 mysql 的端口等。  安装配置比单写入稍微复杂，需要另外一个 VIP。管理比单写入复杂。  主切换后从需要手工切换。  切换需要 1s 左右的时间。 3.4 适用场景 这个方案适用于只有两台数据库服务器（后端有多个从服务器也是可以的， 换）并且还能实现数据库的读写分离的情况，这样 backup 机器也能用起来，提 高系统资源的利用率，减少 master 端的负载。应用中读数据库配置读 VIP，写数 据库配置写 VIP。这个方案也能够很方便的进行单台数据库的管理维护以及切换 工作。比如进行大表的表结构更改、数据库的升级等都是非常方便的。 3.5 方案实战 3.5.1 实战环境介绍 服务器名 IP VIP 系统 Mysql

故障类型： 高可用性： 单服务器故障， 网络分区 灾难恢复： 整个区域/网络故障 人为错误： 个别表问题 10 / 55 业务需求 概念 - RTO & RPO RTO ：恢复时间目标 从单个故障中恢复需要多长时间 RPO ：恢复点目标 发生故障时可能丢失多少数据 Copyright @ 2021 Oracle and/or its affiliates. 高可用性 - 单区域 MySQL 路由器实例将跟从主（ 取决于目标模式） 49 / 55 MySQL InnoDB ClusterSet -限制 • 需要服务器、路由器和Shell 版本 8.0.27 或更高 • InnoDB 集群仅支持单主模式 • 集群之间使用异步复制，而不是半同步（如果要求 RPO=0 ，则使用跨区域分布的单个 集群） Copyright @ 2021 Oracle and/or its affiliates

master 为 sts 最后一个 pod operator 执行 sts 扩缩容 判断 调用 mha 切主 否 是 pod 都正常运行？ 重新调度 mha MGR 高可用简介 • 多主和单主两种工作模式 • MGR 只支持 InnoDB 引擎 • 开启 GTID，ROW 模式 binlog • 每张表必须有检测冲突的主键 • 目前最多只支持 9 个节点 • loose-group_replication_