青铜到王者，快速提升你 MySQL 数据库的段位！(6)

innobackupex --user root --socket=/tmp/mysql.sock --password root123  --defaults-file=/etc/my.cnf --apply-log --redo-only +全备 innobackupex  --user root --socket=/tmp/mysql.sock --password root123  --defaults-file=/etc/my.cnf --apply-log --redo-only 全备  --incremental-dir=增备1 innobackupex  --user root --socket=/tmp/mysql.sock --password root123   --defaults-file=/etc/my.cnf --apply-log --redo-only 全备  --incremental-dir=增备2 innobackupex --user root --socket=/tmp/mysql.sock --password root123  --defaults-file=/etc/my.cnf --apply-log  +全备

注# –redo-only代表只进行前滚操作

# –apply-log应用日志，保证数据的完整性

第五部分：永恒钻石篇

给大家介绍下企业中最常使用的主流 MySQL 高可用架构；

从两方面介绍

1. 基于主从复制

a. 双主M-M keepalived

b. MHA

2. 基于 Galera 协议；

M-M keepalived 双主架构：

一般中小型公司都使用这种架构，搭建比较方便简单；可以采用主从或者主主模式，在 master 节点发生故障后，利用 keepalived 高可用机制实现快速切换到 slave 节点。原来的从库变成新的主库。

但针对这个架构，个人建议以下几点：

1. 一定要完善好切换脚本，keepalived 的切换机制要合理，避免切换不成功的现象发生。

2. 从库的配置尽快要与主库一致，不能太次；避免主库宕机发生切换，新的主库（原来的从库）影响线上业务进行。

3. 对于延迟的问题，在这套架构中，也不能避免。可以使用 mysql 5.7 中增强半同步完成。也可以改变架构使用 PXC，完成时时同步功能，基本上没有延迟；

4. keepalived 无法解决脑裂的问题，因此在进行服务异常判断时，可以修改我们的判断脚本，通过对第三方节点补充检测来决定是否进行切换，可降低脑裂问题产生的风险。

5. 采用 keepalived 这个架构，在设置两节点状态时，都要设置成不抢占模式，都是 backup 状态，通过优先级，来决定谁是主库。避免脑裂，冲突现象发生。

6. 安装好 mysql 需要的一些依赖包；建议配置好 yum 源，用 yum 安装 keepalived 即可。

MHA 架构：

MySQL MHA 架构：可以说是企业最流行，用的最多的架构了。一些同学也经常问我相关的问题。

既然 MHA 这么火，那么它有什么优点呢？

1. 故障切换时，可以自行判断哪个从库与主库的数据最接近，就切换到上面，可以减少数据的丢失，保证数据的一致性

2. 支持 binlog server，可提高 binlog 传送效率，进一步减少数据丢失风险。

3. 可以配置 mysql 5.7 的增强半同步，来保证数据的时时同步

当然也会有一些比较棘手的缺点：

1. 自动切换的脚本太简单了，而且比较老化，建议后期逐渐完善。

2. 搭建 MHA 架构，需要开启 linux 系统互信协议，所以对于系统安全性来说，是个不小的考验。

PXC 架构：

可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。

PXC 基本就属于最完美的一套架构设计理念：

1. 主从同步，基本上无延迟；

2. 完全兼容MySQL

3. 新增节点进入到集群，部署起来很简单。

4. 服务高可用性可以保证，并且数据一致性更加严格；

第六部分：最强王者篇

进入到最后一个段位，在这里知识的高楼基本已经建成，我们需要做的就是一些高级优化操作了。

可以从四个部分来考虑优化的问题：程序设计角度、系统维度、数据库方面、硬件方向

（编辑：ASP站长网）