mysql tomcat高可用_MySQL如何实现高可用

1.MySQL复制功能介绍

MySQL复制功能提供分担读负载。使用复制功能对数据库服务器进行水平扩展，MySQL的复制是异步的。

复制解决了什么问题：

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

利用二进制日志增量进行

不需要太多的带宽，但是使用基于行的复制在进行大批量的更改时会对带宽带来一定的压力

特别是跨IDC环境下进行复制

实现数据读取的负载均衡：

需要其他组件配合完成

利用DNS轮询到的方式把程序的读连接到不同的备份数据库，使用LVS,haproxy这样的代理方式

增强了数据安全性：

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

复制并不能代替备份

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

实现数据库在线升级

2.MySQL二进制日志

MySQL日志分类：

MySQL服务层日志：

二进制日志

慢查日志

通用日志

MySQL存储引擎层日志：

innodb

重做日志

回滚日志

什么是二进制日志：

二进制日志记录了所有对MySQL数据库的修改时间，包括增删改查事件和对表结构的修改时间。在binlog中记录的事件都是已经成功执行了的，至于回滚了的事件不存储在二进制日志中。

二进制日志的格式：

基于段的格式 binlog_format=STATEMENT

优点：

日志记录量相对较小，节约磁盘以及网络I/O

只对一条记录修改或者插入，row格式所产生的日志量小于段产生的日志量

缺点：

必须要记录上下文信息，保证语句在从服务器上执行结果和在主服务器上相同

特定函数如UUID(),user()，这样非确定性函数还是无法复制

可能造成MySQL复制的主从服务器数据不一致

基于行的日志格式 binlog_format=ROW

ROW格式可以避免MySQL中出现的主从不一致的问题

优点：

使MySQL主从复制更加安全

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

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

缺点：

记录日志量较大

混合日志格式 binlog_format=MIXED

特点：

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

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

3.MySQL二进制格式对复制的影响

基于SQL语句到的复制(SBR)

优点：

生成的日志量少，节约网络传输I/O

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

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

缺点：

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

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

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

基于行的复制(RBR)

优点：

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

可以减少数据库锁的使用

缺点：

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

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

4.MySQL复制工作方式

1.主将变更写入二进制日志

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

3.在从上重放relay_log中的日志

5.配置MySQL复制

基于日志点的复制配置步骤：

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

配置主数据库服务器:

bin_log = mysql-bin

server_id = 100

配置从数据库服务器：

bin_log = mysql-bin

server_id = 101

relay_log = mysql-relay-bin

log_slave_update = on[可选]

read_only = on[可选]

初始化从服务器数据

启动复制链路

基于日志点的复制配置优缺点：

优点：

是MySQL最早支持的复制技术，Bug相对较少

对SQL查询没有任何限制

故障处理比较容易

缺点：

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

6.基于GTID复制的优缺点

什么是GTID？

GTID即全局事务ID，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。

优点：

可以很方便的进行故障转移

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

缺点：

故障处理比较复杂

对执行的SQL有一定的控制

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

所使用的MySQL的版本(5.6以上)

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

所使用的高可用管理组件

对应用的支持程度

7.MySQL复制拓扑

一主多从的复制拓扑：

优点：

配置简单

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

用途：

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

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

分担主库的读负载

主-主复制拓扑：

主主模式下的主-主复制的配置缺点：

产生数据冲突而造成复制链路的中断

耗费大量的时间

造成数据丢失

主主模式下的主-主复制的配置注意事项：

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

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

auto_increment_increment = 2(控制自增ID的步长)

auto_increment_offset = 1 | 2 (从哪个值开始自增)

主备模式下的主-主复制的配置注意事项：

只有一台主服务器对外提供服务，一台服务器出于只读状态并且只作为热备使用，在对外提供服务的主库出现故障或是计划性的维护时才会进行切换。使原来的备库成为主库，而原来的主库会成为新的备库，并处理只读或是下线状态是，待维护完成后重新上线。

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

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

在两台服务器上启用log_slave_updates参数

在初始的备库上启用read_only

8.MySQL复制性能优化

影响主从延迟的因素：

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

控制主库的事务大小，分割大事务

二进制日志传输时间

使用MIXED日志格式或设置set binlog_row_image=minimal;

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

使用多线程复制

如何配置多线程复制：

stop_slave;

Set global slave_parallel_type = 'logoical_clock';

Set global slave_parallel_workers=4;

start slave;

9.MySQL复制常见问题处理

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

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

使用跳过二进制日志时间

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

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

主库上的二进制日志损坏：

备库上的中继日志损坏：

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

不唯一的server_id或server_uuid：

max_allow_packet设置引起的主从复制错误：

MySQL复制无法解决的问题：

分担主数据库的写负载

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

提供读写分离的功能

10.什么是高可用框架

高可用性H.A.(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。

如何实现高可用：

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

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

对备份数据进行恢复测试

正确配置数据库环境

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

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

避免存在单点故障

主从切换及故障转移

如何解决MySQL单点故障：

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

利用SUN共享存储或DRDB磁盘复制解决MySQL单点故障

利用多写集群或NDB集群来解决MySQL单点故障

利用MySQL主从复制来解决MySQL单点故障

如何结局也主服务器的单点问题：

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

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

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

11.读写分离和负载均衡介绍

两种读写分离方式：

由程序实现读写分离：

优点：

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

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

缺点：

程度代码更复杂

人为控制，容易出现错误

由中间件来实现读写分离：

mysql-proxy

maxScale

优点：

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

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

缺点：

对查询效率有损耗

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

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

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

如何实现负载均衡：

软件：

LVS

Haproxy

MacScale

硬件：

F5