当前位置: 首页 > 建站技术 > 数据库 > MySQL > 正文

  • 标签
  • 源码
  • 特效
  • mysql高可用架构设计,处理高并发,大流量!

    主要介绍:复制功能介绍、mysql二进制日志、mysql复制拓扑、高可用框架、单点故障、读写分离和负载均衡介绍等

    mysql复制功能介绍

    mysql复制功能提供分担读负载

    复制解决的问题

    实现在不同服务器上的数据分布

    利用二进制日志增量进行

    不需要太多的带宽

    但是使用基于行的复制在进行大批量的更改时会对带宽带来一定得压力,特别是跨IDC环境下进行复制

    实现在不同服务器上的数据分布

    实现数据读取的负载均衡

    需要其他组件配合完成

    利用DNS轮询的方式把程序的读连接到不同的备份数据库,

    使用LVS,haproxy这样的代理方式

    非共享架构,同样的数据分布在多台服务器上

    增强了数据安全性

    利用备库的备份来减少主库负载

    复制并不能代替备份

    实现数据库高可用和故障切换

    实现数据在线升级

    mysql二进制日志

    mysql服务层日志

    二进制日志

    慢查日志

    通用日志

    mysql存储引擎层日志

    innodb日志

    重做日志

    回滚日志

    记录了所有对mysql数据库的修改事件,包括增删改查事件和对表结构的修改事件

    二进制日志格式

    基于段的格式(记录sql语句)

    binlog_format = statement

    优点

    日志记录量相对较小,节约磁盘及网络i/o, 只对一条记录修改或者插入

    缺点

    必须要记录上下文信息

    保证语句在从服务器和主服务器上执行结果一致

    对于特定的函数如uuid(),user()这样非确定性函数还是无法复制,可能造成mysql复制的主备服务器数据不一致

    基于行的格式

    binlog_format = ROW

    同一sql语句修改了10000条数据的情况下,基于段的日志格式只会记录这个sql语句,基于行的日志格式会有10000条记录分别记录每一行的数据修改

    优点

    使mysql主从复制更加安全

    对每一行数据的修改比基于段的复制高效

    误操作而修改了数据库中的数据,同时又没有备份可以恢复时,我们就可以通过分析二进制日志,对日志记录的数据修改操作做反向处理的方式来达到恢复数据的目的。

    缺点

    记录日志格式较大

    binlog_row_image = [full|minimal|noblob]

    混合日志格式

    binlog_format = mixed

    特点:

    根据sql语句由系统决定在基于段和基于行的日志格式中进行选择

    数据量的大小由所执行的sql语句决定

    mysql二进制日志格式对复制的影响

    基于sql语句的复制(SBR)

    优点

    生成的日志量少,节约网络传输i/o

    并不强制要求主从数据库的表定义完全相同

    相比于基于行的复制方式更为灵活

    缺点

    对于非确定事件,无法保证主从复制数据的一致性

    对于存储过程、触发器、自定义函数进行的修改也可能造成数据不一致

    相比于基于行的复制方式在从上执行时需要更多的行锁

    基于行的复制

    优点

    可以应用于任何sql的复制包括非确定函数,存储过程等

    可以减少数据库锁的使用

    缺点

    要求主从数据的表结构相同,否则可能会中断复制

    无法在从上单独执行触发器

    mysql复制工作方式


    步骤

    主将变更写入二进制日志

    从读取主的二进制日志变更并写入到relay_log中

    基于日志点的复制

    基于GTID的复制

    在从上重放relay_log中的日志

    基于sql段的日志是在从库上重新执行记录的sql

    基于行的日志则是在从库上直接应用对数据库的修改

    基于日志点的复制


    基于日志点复制配置步骤

    在主DB服务器上建立复制账号

    create user 'repl' @'ip段'identified by 'password'

    grant replication slave on . to 'repl' @'ip段‘

    配置从数据库服务器

    bin_log = mysql-bin

    server_id = 101

    relay_log = mysql-relay-bin

    log_slave_update = on

    read_only = on

    初始化从服务器数据

    mysqldump --master-data=2 -single-transaction

    xtrabackup --slave-info

    启动复制链路

    change master to master_host="master_host_ip",master_user='repl',master_password='password' master_log_file='mysql_log_file_name',master_log_pos=4;

    优缺点

    优点

    是mysql最早支持的复制技术,bug相对较少

    对sql查询没有任何限制

    处理故障比较容易

    缺点

    故障转移是重新获取新主的日志点信息比较困难

    基于GTID的复制

    什么是GTID

    GTID即全局事务id,其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的id;GTID=source_id:transaction_id

    bin_log = /usr/local/mysql/log/mysql-bin

    server_id = 100

    gtid_mode = on

    enforce-gtid-consiste

    启动基于GTID的复制


    change master to master_host="master_host_ip",master_user='repl',master_password='password',master_auto_position = 1;

    优缺点

    优点

    可以很方便的进行故障专业

    从库不会丢失主库上的任何修改

    缺点

    故障处理比较复杂

    对执行的sql有一定得限制

    选择复制模式要考虑的问题

    所使用的mysql版本

    复制架构及主从切换的方式

    所使用的高可用管理组件

    对应用的支持程度

    mysql复制拓扑


    mysql5.7之前,一个从库只能有一个主库

    mysql5.7之后,支持一从多主架构

    一主多从的复制拓扑


    优点

    配置简单

    可以用多个从库分担读负载

    用途

    为不同业务使用不同的从库

    将一台从库放到远程IDC,用作灾备恢复

    分担主库的读负载

    主-主复制拓扑


    配置注意事项

    两个主中所操作的表最好能够分开

    使用下面两个参数控制自增id的生成

    auto_increment_increment = 2

    auto_increment_offset = 1 | 2

    主备模式下的主-主复制配置主要事项

    只有一台主服务器对外提供服务

    一台服务器处于只读状态并且只作为热备使用

    在对外提供服务的主库出现故障或是计划性的维护时才会进行切换

    使原来的备库成为主库,而原来的主库会成为新的备库,并处理只读或是下线状态,待维护完成后重新上线

    确保两台服务器上的初始数据相同

    确保两台服务器上已经启动binlog并且有不同的server_id

    在初始的备份上启用read_only

    也可以给主库分配几个从库


    级联复制


    mysql复制性能优化

    影响主从延迟的因素


    主库写入二进制日志的时间

    解决方法:控制主库的事务大小,分割大事务

    二进制日志传输时间

    解决方法:使用mixed日志格式或设置set binlog_row_image=minimal

    默认情况下从库只有一个sql线程,主上并发的修改在从上变成了串行

    解决方法:使用多线程复制,在mysql5.7中可以按照逻辑时钟的方式来分配sql线程

    配置步骤:

    stop slave

    set global slave_parallel_type = 'logical_clock'

    set global slave_parallel_workers = 4

    start slave

    mysql复制常见问题处理

    由于数据损坏或丢失所引起的主从复制错误

    主库或者从库意外宕机引起的错误

    解决方法:

    使用跳过二进制日志事件

    注入空事务的方式先恢复中断的复制链路

    再使用其它方法来对比主从服务器上的数据

    主库上的二进制日志损坏

    备库上的中继日志损坏

    在从库上进行数据修改造成的主从复制错误

    mysql复制无法解决的问题

    分担数据库的写负载

    自动进行故障转移及主从切换

    提供读写分离功能

    高可用框架 什么是高可用

    高可用H.A(High Avalilability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间,以提高系统和应用的可用性

    表示高可用常用的因子

    正常可用时间

    全年时间百分比

    引起系统不可用的原因

    严重的主从延迟

    主从复制中断

    锁引起的大量阻塞

    软硬件故障造成的服务器宕机等

    如何实现高可用

    避免导致系统不可用的因素,减少系统不可用的时间

    建立完善的监控及报警系统

    对备份数据进行恢复测试

    正确配置数据库环境

    对不需要的数据进行归档和清理

    增加系统冗余,保证发生系统不可用时可以尽快恢复

    避免存在单点故障

    主从切换及故障转移

    原因

    有服务器磁盘空间耗尽、

    性能糟糕的sql

    表结构和索引没有优化

    主从数据不一致

    人为的操作失误

    单点故障

    单点故障是指在一个系统中提供相同功能的组件只有一个,如果这个组件失效了,就会影响整个系统的正常使用。组成应用系统的各个组件都有可能成为单点。

    如何避免mysql单点故障

    利用sun共享存储或drdb磁盘复制解决mysql单点故障

    sun


    drdb


    利用多写集群或ndb集群来解决mysql单点故障


    如何解决主服务器的单点问题

    主服务器切换后,如何通知应用新的主服务器的ip地址

    如何检查mysql主服务器是否可用

    如何处理从服务器和新主服务器之间的那种复制关系

    MMM架构介绍

    Multi-Master Replication Manager

    MMM提供了什么功能

    MMM监控mysql主从复制健康情况

    在主库出现宕机时进行故障转移并自动配置其他从对主的复制

    如何找到从库对应的新的主库日志点的日志同步点

    如果存在多个从库出现数据不一致的情况如何处理

    提供了读、写虚拟ip, 在主服务器出现问题时,可以自动迁移虚拟ip

    MMM架构


    MMM部署所需资源


    MMM优缺点

    优点

    使用perl脚本语言开发及完全开源

    提供了读写vip(虚拟ip),使服务器角色的变更对前端应用透明

    MMM提供了从服务器的延迟监控

    缺点

    发布时间比较早不支持mysql新的复制功能

    没有读负载的功能

    在进行主从切换时,容易造成数据丢失

    MMM监控服务存在单点故障

    MHA架构介绍

    Master High Avalilability

    提供的功能

    监控主数据库服务是否可用

    当主DB不可用时,从多个从服务器中选举出新的主数据库服务器

    提供了主从切换和故障转移功能

    MHA主从切换过程

    尝试从出现故障的主数据库保存二进制日志

    从多个备选从服务器中选举新的备选主服务器

    在备选主服务器和其他从服务器之间同步差异二进制数据

    应用从原db服务器上保存的二进制日志

    读写分离和负载均衡介绍

    进行mysql主从复制配置的一个主要目的:为了分担主库的读负载

    为什么要读写分离

    只能在主上进行写操作

    读操作主和从上都可以

    读写分离的两种方式

    程序实现读写分离

    优点

    由开发人员控制什么样查询在从库中执行,因此比较灵活

    有程序直接连接数据库,所以性能损耗比较少

    缺点

    增加了开发的工作量,使程序代码更加复杂

    认为控制,容易出现错误

    中间件实现读写分离

    优点

    由中间件根据查询语法分析,自动完成读写分离

    对程序透明,对于已有程序不用做任何调整

    缺点

    增加了中间层,所以对查询效率有损耗

    对于延迟敏感业务无法自动在主库执行

    读写分离与读的负载均衡区别

    读写分离要解决的是如何在复制集群的不同角色上,去执行不同的sql语句

    读的负载均衡主要解决的是具有相同角色的数据库,如何共同分担相同的负载

    如何实现读的负载均衡

    软件

    LVS

    Haproxy

    MaxScale

    硬件

    F5

    关注创业、电商、站长,扫描方便乐网站微信二维码,定期抽大奖。

    【版权与免责声明】如发现内容存在版权问题,烦请提供相关信息发邮件至2723741405@qq.com,我们将及时沟通与处理。本站内容除非来源注明方便乐,否则均为网友转载,涉及言论、版权与本站无关。

    本文永久链接:http://www.fangbianle.com/news/show-255608.html

  • 营销
  • 创业
  • 电商
  • 微商
  • AppsFlyer携手百度搜索推广oCPC持续赋能移动营销
    选择新网络推广的优势
    优秀的营销策划人,需要做对三件事
    移动营销:得让消费者自己寻找东西
    网络推广为什么越来越难做?
    最适合中国的10种营销策略
    后流量时代 陌陌的移动营销新方式
    2018年有这些免费的网络推广方法