标签：方式   nod   逻辑   灾备   阻塞   proxy   awd   ima   minimal   

主要介绍：复制功能介绍、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

基于日志点复制配置步骤

• 在主DB服务器上建立复制账号
  • create user ‘repl’ @’ip段’identified by ‘password’
  • grant replication slave on . to ‘repl’ @’ip段‘
• 配置从数据库服务器
  • bin_log = /usr/local/mysql/log/mysql-bin
  • server_id = 100
  • gtid_mode = on
  • enforce-gtid-consiste
  • log_slave_update = on
  • read_only = on
• 初始化从服务器数据
  • mysqldump –master-data=2 -single-transaction
  • xtrabackup –slave-info
• 启动基于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

大专栏  mysql高可用架构设计备模式下的主-主复制配置主要事项" class="headerlink" title="主备模式下的主-主复制配置主要事项">主备模式下的主-主复制配置主要事项

• 只有一台主服务器对外提供服务
• 一台服务器处于只读状态并且只作为热备使用
• 在对外提供服务的主库出现故障或是计划性的维护时才会进行切换
• 使原来的备库成为主库，而原来的主库会成为新的备库，并处理只读或是下线状态，待维护完成后重新上线
• 确保两台服务器上的初始数据相同
• 确保两台服务器上已经启动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

mysql高可用架构设计

标签：方式   nod   逻辑   灾备   阻塞   proxy   awd   ima   minimal   

原文地址：https://www.cnblogs.com/sanxiandoupi/p/11698443.html