大厂都在用的MySQL主从复制、读写分离及高可用方案(下)-阿里云开发者社区

开发者社区> javaedge> 正文

大厂都在用的MySQL主从复制、读写分离及高可用方案(下)

简介: 大厂都在用的MySQL主从复制、读写分离及高可用方案(下)
+关注继续查看

3 主从复制的缺点及解决方案

3.1 主从延迟

  • 只能数据分片,把数据量做小

主从同步适用场景

推荐在读 >> 写,且读时对数据时效性要求不高时采用。所以可以考虑用MySQL的并行复制,但问题是那是库级别的并行,所以有时作用不是很大。

主从延迟严重解决方案

分库 : 将一个主库拆分,每个主库的写并发就降低了,主从延迟即可忽略不计


打开MySQL支持的并行复制,多个库并行复制,若某个库的写入并发特别高,写并发达到了2000/s,并行复制还是没意义。二八法则,很多时候比如说,就是少数的几个订单表,写入了2000/s,其他几十个表10/s。

从库开启多线程,并行读取relay log中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。


重构代码 : 重构代码,插入数据后,直接更新,不查询


若确实存在必须先插入,立马要求查询,然后立马就反过来执行一些操作,对这个查询设置直连主库(不推荐,这会导致读写分离失去意义)

3.2 应用侧需要配合读写分离框架

读写分离

借助于主从复制,我们现在有了多个 MySQL 服务器示例。

如果借助这个新的集群,改进我们的业务系统数据处理能力?

最简单的就是配置多个数据源,实现读写分离


动态切换数据源

  1. 基于 Spring/Spring Boot,配置多个数据源(例如2个,master 和 slave)
  2. 根据具体的 Service 方法是否会操作数据,注入不同的数据源,1.0版本

优化:

1.1:基于操作 AbstractRoutingDataSource 和自定义注解 readOnly 之类的,简化自动切换数据源

1.2:支持配置多个从库

1.3:支持多个从库的负载均衡

image.png

框架

“动态切换数据源”版问题:

  • 代码侵入性强
  • 降低侵入性会导致”写后立即读”不一致问题
    写时(还没同步到从库),立马读(从库),导致你 insert 数据后去查却查不到!

改进方式,ShardingSphere-jdbc 的 Master-Slave 功能

1)SQL 解析和事务管理,自动实现读写分离

2)解决”写完读”不一致的问题

只要一个事务中解析到有写,所有读都读主库,而无需我们业务代码处理。


数据库中间件

“框架版本”的问题?

  • 对业务系统还是有侵入
  • 对已存在的旧系统改造不友好


优化方案:MyCat/ShardingSphere-Proxy 的 Master-Slave 功能

  • 需要部署一个中间件,规则配置在中间件
  • 模拟一个 MySQL 服务器,对业务系统无侵入


但是该方案需要单独部署中间件,需要运维成本和领导审批,所以一般开发人员使用框架方案。


3.3 无法高可用

3.3.1 为什么要高可用

1、读写分离,提升读的处理能力

2、故障转移,提供 failover 能力


加上业务侧连接池的心跳重试,实现断线重连,业务不间断,降低RTO和RPO。

高可用意味着,更少的不可服务时间。一般用SLA/SLO衡量。


1年 = 365天 = 8760小时
99 = 8760 * 1% = 8760 * 0.01 = 87.6小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

3.3.2 failover,故障转移,灾难恢复

容灾:热备与冷备

对于主从来说,就是主挂了,某一个从,变成主,整个集群来看,正常对外提供服务。

常见的一些策略:

  • 多个实例不在一个主机/机架上
  • 跨机房和可用区部署
  • 两地三中心容灾高可用方案


3.3.3 高可用方案

3.3.3.1 主从手动切换

若主节点宕机,将某个从改成主;重新配置其他从节点。修改应用数据源配置。

缺点:

  1. 可能数据不一致
  2. 需要人工干预
  3. 代码和配置的侵入性

3.3.3.2 主从自动切换

用 LVS+Keepalived 实现多个节点的探活+请求路由。

配置 VIP 或 DNS 实现配置不变更。

缺点:

  • 手工处理主从切换
  • 大量的配置和脚本定义


只能算半自动。

3.3.3.2 MHA

MHA,Master High Availability,目前在 MySQL 高可用方面是一个相对成熟的解决方案,它由日本 DeNA 公司的 youshimaton(现就职于 Facebook)开发,是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。

image.png

基于 Perl 语言开发,一般能在30s内实现主从切换。

切换时,直接通过 SSH 复制主节点的日志。

缺点:

  • 需要配置 SSH 信息
  • 至少3台

3.3.3.2 MGR

不借助外部力量,只使用 MySQL 本身。如果主节点挂掉,将自动选择某个从改成主;无需人工干预,基于组复制,保证数据一致性。

image.png

缺点:

  • 外部获得状态变更需要读取数据库
  • 外部需要使用 LVS/VIP 配置

特点:

  • 高一致性
    基于分布式Paxos协议实现组复制,保证数据一致性
  • 高容错性
    自动检测机制,只要不是大多数节点都宕机就可继续工作,内置防脑裂保护机制
  • 高扩展性
    节点的增加与移除会自动更新组成员信息,新节点加入后,自动从其他节点同步增量数据,直到与其他节点数据一致
  • 高灵活性
    提供单主模式和多主模式,单主模式在主库宕机后能够自动选主,所有写入都在主节点进行,多主模式支持多节点写入


适用场景:

  • 弹性复制
    需要非常流畅的复制基础架构的环境,其中服务器的数量必须动态地增长或缩减,而最少尽可能的痛苦。

image.png

高可用分片

Sharding is a popular approach to achieve write scale-out. Users can use MySQL Group Replication to implement highly available shards. Each shard

can map into a Replication Group.

分片是实现写横向扩展的一种流行方法。用户可以使用MySQL组复制来实现高度可用的分片。每个分片可以映射到副本组。


image.png

3.3.3.4 MySQL Cluster

完整的数据库层高可用解决方案。

MySQL InnoDB Cluster是一个高可用的框架,构成组件:


MySQL Group Replication

提供DB的扩展、自动故障转移


MySQL Router

轻量级中间件,提供应用程序连接目标的故障转移。MySQL Router是一个轻量级的中间件,可以提供负载均衡和应用连接的故障转移。它是MySQL团队为MGR量身打造的,通过使用Router和Shell,用户可以利用MGR实现完整的数据库层的解决方案。如果您在使用MGR,请一定配合使用Router和Shell,可以理解为它们是为MGR而生的,会配合MySQl 的开发路线图发展的工具。


MySQL Shell

新的MySQL客户端,多种接口模式。可以设置群组复制及Router。MySQL Shell是MySQL团队打造的一个统一的客户端, 它可以对MySQL执行数据操作和管理。它支持通过JavaScript,Python,SQL对关系型数据模式和文档型数据模式进行操作。使用它可以轻松配置管理InnoDB Cluster。

1.png

3.3.3.5 Orchestrator

如果主节点挂掉,将某个从改成主。

一款MySQL高可用和复制拓扑管理工具,支持复制拓扑结构的调整,自动故障转移和手动主从切换等。后端数据库用MySQL或SQLite存储元数据,并提供Web界面展示MySQl 复制的拓扑关系及状态,通过Web可更改MySQL实例的复制关系和部分配置信息,同时也提供命令行和API接口,方便运维管理。

特点:

  1. 自动发现MySQL的复 制拓扑,并且在web.上展示;
  2. 重构复制关系, 可以在web进行拖图来进行复制关系变更;
  3. 检测主异常,并可以自动或手动恢复,通过Hooks进行自定义脚本;
  4. 支持命令行和web界面管理复制。


基于 Go 语言开发,实现了中间件本身的高可用。

两种部署方式

orchestrator/raft:

  1. 数据一致性由orchestrator的raft协议保证
  2. 数据库之间不通信
    orchestrator/[galera | xtradb cluster | innodb cluster]:
  3. 数据一致性由数据库集群保证
  4. 数据库结点之间通信


如果不部署client

  1. 使用HTTP (/api/leader-check)查询并路由到主节点


优势:

能直接在 UI 界面

拖拽改变主从关系

image.png

参考

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Mysql +MHA+LVS+KEEPALIVED高可用,读写分离,负载均衡 搭建(学习笔记十八)
IP 主机名 角色 MHA 角色 172.16.54.226 MySQL-15.11 MySQL Master 主 Masterha-node 172.16.
1006 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
10839 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
13154 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
11493 0
+关注
javaedge
关注公众号:JavaEdge,后台回复面试,领取更多大厂求职资源。曾在百度、携程、华为等大厂搬砖,专注Java生态各种中间件原理、框架源码、微服务、中台等架构设计及落地实战,只生产硬核干货!
2317
文章
1
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载