首页手记 mysql高可用架构设计(慕课网课程笔记)

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

基于日志点复制配置步骤

在主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

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

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

由于数据损坏或丢失所引起的主从复制错误
- 主库或者从库意外宕机引起的错误
  - 解决方法：
    - 使用跳过二进制日志事件
    - 注入空事务的方式先恢复中断的复制链路
    - 再使用其它方法来对比主从服务器上的数据
主库上的二进制日志损坏
备库上的中继日志损坏
在从库上进行数据修改造成的主从复制错误