mysql高可用架构设计，处理高并发，大流量！
主要介绍：复制功能介绍、mysql二进制日志、mysql复制拓扑、高可用框架、单点故障、读写分离和负载均衡介绍等前端
mysql复制功能介绍 mysql
mysql复制功能提供分担读负载sql
复制解决的问题 数据库
实如今不一样服务器上的数据分布安全
利用二进制日志增量进行性能优化
不须要太多的带宽服务器
可是使用基于行的复制在进行大批量的更改时会对带宽带来必定得压力，特别是跨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