Mysql高可用方案Haproxy+Keepalive+Percona XtraDB Cluster实现：方案介绍 （一）

由于最近公司需要一套Mysql的高可用方案，所以整理了一下这套方案的实现步骤，为什么选这套方案，主要是参考了下面的总结

https://www.2cto.com/database/201804/736048.html

 

一、方案概述

Haproxy主要功能是进行负载均衡
Keepalived的主要功能是检查mysql可用状态，辅助切换
方案拓扑关系如下：

此方案中：

1）Percona XtraDB Cluster集群部分

管理节点： 192.168.6.114， 192.168.6.115

数据节点和mysql节点：192.168.6.111， 192.168.6.112，192.168.6.113，。。。

其他红色标注的表示实际环境下可以进行横向扩展（数据节点和mysql节点可以分别部署）

2）负载均衡和高可用

部署节点：192.168.6.114， 192.168.6.115

虚拟路由节点：192.168.6.116

也可以另外单独找两台服务器进行部署，虚拟节点是面向用户（web调用）的节点
 

二、注意事项

1、使用 Galera 必须要给 MySQL-Server 打 wsrep 补丁。可以直接使用官方提供的已经打好补丁的 MySQL 安装包， 如果服务器上已经安装了标准版 MYSQL，需要先卸载再重新安装。卸载前注意备份数据。
2、 MySQL/Galera 集群只支持 InnoDB 存储引擎。如果你的数据表使用的 MyISAM，需要转换为 InnoDB，否则记录不 会在多台复制。可以在 备份老数据时，为 mysqldump 命令添加–skip-create-options 参数，这样会去掉表结构的 声明信息，再导入集群时自动使用 InnoDB 引擎。不过这样会将 AUTO_INCREMENT 一并去掉，已有 AUTO_INCREMENT 列的表，必须在导入后重新定义。
3、MySQL 5.5 及以下的 InnoDB 引擎不支持全文索引（FULLTEXT indexes），如果之前使用 MyISAM 并建了全文索引 字段的话，只能安装 MySQL 5.6 with wsrep patch。
4、所有数据表必须要有主键（PRIMARY）,如果没有主键可以建一条 AUTO_INCREMENT 列。
5、MySQL/Galera 集群不支持下面的查询：LOCK/UNLOCK TABLES，不支持下面的系统变量：character_set_server、 utf16、utf32 及 ucs2。
6、数据库日志不支持保存到表，只能输出到文件（log_output = FILE），不能设置 binlog-do-db、binlog-ignore-db。
7、跟其他集群一样，为了避免节点出现脑裂而破坏数据，建议 Galera 集群最低添加 3 个节点。
8、在高并发的情况下，多主同时写入时可能会发生事务冲突，此时只有一个事务请求会成功，其他的全部失败。 可以在写入/更新失败时，自动重试一次，再返回结果。

9、节点中每个节点的地位是平等的，没有主次，向任何一个节点读写效果都是一样的。实际可以配合 VIP/LVS 或 HA 使用，实现高可用性。

Percona XtraDB Cluster特点：

（1）同步复制，事务在所有集群节点要么同时提交，要么不提交。

（2）多主复制，可以在任意一个节点写入。

（3）从服务器上的并行应用事件，真正的“并行复制”。

（4）自动配置节点。

（5）数据一致性，没有不同步的从服务器。

相对于MySQL原生复制和semi-sync，Galera replication比较有吸引力的特性：

1. 同步复制，主备无延迟，master宕机后slave可以立即顶上并提供服务
   （semi-sync需要apply完所有relay log）
2. 事务冲突检测保证数据一致性，多个节点可以同时读写数据，可以极大简化数据访问
3. 行级别并行复制，MySQL 5.6之前slave sql线程只有一个，这个长期饱受诟病，是导致slave落后master的
   主要原因

Galera replicateion 限制

1. 集群至少3个节点（2个节点也可以运行）
2. 存储引擎：Innodb / XtraDB / Maria
3. 不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…
4. 不支持XA Transaction