原创 MySQL架构演进-从主从复制到分库分表

发布时间:2021-08-03 00:06:19 浏览 572 来源:猿笔记 作者:threadxu

    单机的数据库已经无法满足互联网业务的发展,传统的将数据集中存储单一数据结节的方案。在容量、性能、可用性和可维护性方面已经难以满足互联网海量数据的场景,由于关系型数据库大多数采用B+树类型索引,这必然导致系统的存储压力都集中在数据库层面,当数据都集中在一个节点上时,数据备份和恢复的时间成本也随之数据量上升变得不可控,同时数据丢失导致影响的范围也会被放大。-主库将事务操作(除了查询以外的操作)记录到binlog,半同步复制是指只要一个salve节点返回ack,保证数据库至少有一个节点完成了数据的同步。-业务层保证系统核心功能可用。


    #主题列表:juejin,github,smartblue,cyanosis,channing-cyan,fancy,hydrogen,condensed-night-purple,greenwillow,v-green,vue-pro,healer-readable,mk-cute,jzman,geek-black,awesome-green,qklhk-chocolate

    #投稿主题:

    theme:juejin

    highlight:

    ###背景

    业务的快速发展导致数据规模的快速扩张,单机数据库已经不能满足互联网业务的发展。

    从容量、性能、可用性和可维护性来看,以集中方式存储单个数据结节的传统方案难以满足互联网上的海量数据场景。

    考虑到容量,单机数据库容量有限,难以扩展。

    在性能方面,由于大多数关系数据库使用B+树索引,当数据量超过一定阈值时,索引深度的增加会导致随机对磁盘IO次数的增加,从而导致性能问题。

    就可用性而言,服务通常被设计为无状态的,这不可避免地导致系统的存储压力集中在数据库级别,单个数据节点或简单的主从架构变得越来越难以承受。

    从运维角度来看,当数据集中在一个节点上时,随着数据量的增加,数据备份和恢复的时间成本变得不可控。同时,数据丢失造成的影响范围也会扩大。

    # # #主从复制

    -主库将事务操作(除查询之外的操作)记录到binlog

    -通过relaylog同步库中的数据,实现数据同步

    binlog日志格式

    -行记录详细记录数据库操作,包括在线信息等。,带有大文件。

    -statement记录事务相关的SQL文件。

    -mixed混合式,基于row和statement两种文件格式。

    # # # #异步复制

    2000年MySQL版本MySQL3.23.15引入了复制功能,采用异步复制。当网络或机器出现故障时,会导致数据不一致。

    # # # #半同步复制

    2010年,MySQL5.5版引入了半同步复制。半同步复制意味着只要一个从节点返回ack,主节点就可以提交事务,确保数据库中至少有一个节点完成了数据同步。

    # # # #组复制

    2016年,MysQL在5.7.17中引入InnoDBGroupReplication,该方案基于paxos协议实现组内复制,保证数据一致性,paxos协议核心在于过半选举。

    # # # #主从复制的问题

    -主从复制延迟,导致“读完”数据不一致。

    -从库中读取失败,然后又去主库执行SQL,造成性能问题。

    -业务层确保系统的核心功能可用,并将核心功能的CRUD操作路由到主库。即使非核心业务功能存在短期数据不一致,影响也不大。

    -路由问题,要求业务层根据SQL路由到不同的数据库。路由到SLAVE节点时,还需要保证系统负载平衡。

    -业务层是通过框架(比如分片-jdbc)或者手工实现的,对业务有侵害,现有的旧系统改造不友好。

    -通过数据库中间件(如mycat、sharding-proxy)实现,需要部署一个中间件(中间件实现SQL标准),规则配置在中间件中,在执行过程中会被网络再次转发。

    -不能保证系统高度可用

    -通过一系列高可用性解决方案确保数据库的高可用性

    # # #数据库高度可用

    # # # #什么是高可用性?

    高可用性意味着服务不可用的时间更少,这通常由服务级别协议来衡量。

    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分钟

    # # # #为什么要让它高度可用?

    通过故障转移,提供failover的能力,加上业务侧连接池的心跳重试,实现断线重连,业务不间断,降低RTO(RecoveryTimeObjective,复原时间目标)和RPO(RecoveryPointObjective,复原点目标)。

    -灾难恢复:冷备用和热备用。冷备和热备用的区别在于运行时是否提供服务。

    -对于主节点,简单来说就是主节点挂机,某个从节点自动切换到主节点。

    -从集群的角度来看,即使单个节点出现故障,也可以正常向外界提供服务。

    常见策略:

    -多实例部署

    -跨机房部署

    -两地三中心容灾高可用方案。

    # # # #手动切换

    也就是说,如果主节点关闭,手动将从节点修改为主节点。

    存在的问题:

    -可能的数据不一致

    -需要人工干预

    -代码和配置具有侵入性,因此需要配置其他节点并修改应用程序数据源的配置。

    ####MHA

    MHA全称叫做MySQLMasterHighAvailability,是由Facebook工程师[YoshinoriMatsunobu](

    MHA负责MySQL主库的高可用性。当主库出现故障时,MHA将选择一个编号与原始主库最接近的候选节点作为新的主节点,并填写不同于之前关闭的主节点的Binlog。数据完成后,很快就会写VIP

作者信息

threadxu [等级:3] 后端开发
发布了 3 篇专栏 · 获得点赞 12 · 获得阅读 869

相关推荐 更多