SAKURA
0%

MySQL高可用中间件方案选型

发表于 更新于

MySQL高可用中间件方案选型，稍微总结一下。

常用MySQL高可用中间件方案

MySQL High Available Cluster

MySQL Router

MySQL Router is part of InnoDB Cluster and is lightweight middleware that provides transparent routing between your application and back-end MySQL Servers. It is used for a wide variety of use cases, such as providing high availability and scalability by routing database traffic to appropriate back-end MySQL servers. The pluggable architecture also enables developers to extend MySQL Router for custom use cases.

Mysql InnoDB Cluster 主要由三个模块构成：

MySQL InnoDB Cluster

  1. 支持Group Replication 功能的Mysql Server(version >= 5.7.17)，模块主要功能在于实现了组内通信，故障转移（英语：failover, 即当活动的服务或应用意外终止时，快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作）、故障恢复（英语：failback，将系统，组件，服务恢复到故障之前的组态）
  2. Mysql-shell：实现快速部署，主要提供了一套AdminAPI，可以自动化配置Group Replication，让我们无须再手动配置cluster中group replication相关参数。
  3. Mysql-router：内置读写分离，负载均衡。自动根据Mysql InnoDB Cluster中的metadata自动调整。

优点：
其实也就是InnoDB Cluster的优点
缺点：
Mysql-router没有SQL审计，限流，分库分表的功能，但是可以通过C来写插件进行扩展；
非InnoDB Cluster架构下，主库和从库的拓扑变更需要修改配置并重启。

Maxscale

mariadb_maxscale
优点：

  • 支持读写分离，高可用，故障转移

  • 提供了监控能力

官网介绍
缺点：
BSL协议，在生产环境，如果后端超过3个MariaDB实例提供服务，就必须购买商业授权。
Failover以及Switchover和Rejoin仅支持基于GTID(全局事务ID)的复制一起使用，并且仅适用于简单的一主多从拓扑架构：即1个master后面跟着多个slave。需要把loss-less无损半同步复制(semi replication)开启，参数rpl_semi_sync_master_wait_point=AFTER_SYNC，确保slave已经接收到了master的binlog，因为master宕机，MaxScale无法远程拷贝scp那一缺失的binlog，那么数据就出现不一致了。

ProxySQL

C++开发，轻量级的开源软件，配置数据基于SQLite存储，Proxysql读写分离的中间件，支持高可用 主从\ MGR \ PXC等环境，并提供连接池、缓存、日志记录等功能。
优点：

  • 支持多路复用连接池
  • 自动下线后端DB； 延迟超过阀值、 ping 延迟超过阀值、网络不通或宕机
  • 可缓存查询结果
  • 强大的规则路由引擎；实现读写分离、 查询重写、sql流量镜像
  • 提供了监控能力

缺点：
例子少，只有官方文档。用户不如MaxScale多。

ArkProxy

ArkProxy

优点：

  • 透明读写分离和支持 Hint 分发
  • 100%兼容MySQL语法，用户友好
  • 自动负载均衡、权重分发，灵活控制数据库流量
  • 内部实现消息压缩，同时实现用户连接数限制和统计
  • Trace智能统计分析及审计，支持将访问请求对接到Kafka，供大数据系统统计分析
  • 内置高效连接池，在高并发时大大提升数据库集群的处理能力
  • 提供自定义一致性读和自路由一致性读来满足数据的强一致性读需求
  • 自定义SQL 拦截，可以拦截危险SQL
  • 配置文件可动态加载，避免重启
  • Percona 分支数据库支持无任何权限侵入直接上线的功能

缺点：
貌似上述功能都要依赖他们的体系。

MyCat

优点：

  • 支持 SQL 92标准
  • 支持Mysql集群，可以作为Proxy使用
  • 支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使用
  • 支持galera for mysql集群，percona-cluster或者mariadb cluster，提供高可用性数据分片集群
  • 自动故障切换，高可用性
  • 支持读写分离，支持Mysql双主多从，以及一主多从的模式
  • 支持全局表，数据自动分片到多个节点，用于高效表关联查询
  • 支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询
  • 多平台支持，部署和实施简单

缺点：
MyCat2已经出现了，社区活跃度不太稳定，感觉企业里使用的不多。同时，对数据查询语句作拆分本身就是一个比较头疼的事情，可能会有很多bug。增加节点需要手动修改schema.xml配置文件，然后做一次reload操作等等。schema.xml配置简直不能忍。

Apache shardingsphere-JDBC

ShardingSphere-JDBC 是 Apache ShardingSphere 的第一个产品，也是 Apache ShardingSphere 的前身。 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC。
  • 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP 等。
  • 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，Oracle，SQLServer，PostgreSQL 以及任何遵循 SQL92 标准的数据库。
  • 自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致。
  • 对应用透明：集群的维护，对应用程序是透明的，几乎感觉不到。
    以上几点，足以说明Galera Cluster是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案。

Galera Cluster架构

解决方案：
不做读写分离的话 HA + Galera Cluster
集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，都是基于Galera的，Galera Cluster架构就是multi-master的集群架构。

优点：

  • 多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的。
  • 同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失。异步复制中，主库将数据更新传播给从库后立即提交事务，而不论从库是否成功读取或重放数据变化。这种情况下，在主库事务提交后的短时间内，主从库数据并不一致。同步复制时，主库的单个更新事务需要在所有从库上同步更新。换句话说，当主库提交事务时，集群中所有节点的数据保持一致。
  • 并发复制：从节点在APPLY数据时，支持并行执行，有更好的性能表现。
  • 故障切换：在出现数据库故障时，因为支持多点写入，切的非常容易。
  • 热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小。
    个人感觉适合交易类的场景，是一个可以保证数据强一致性的架构。

缺点：
比较新型的架构使用者较少，还在发展。

MySQL Group Replication架构

MGR是以Plugin的形式嵌入在MySQL实例中，插件内部实现了冲突检测、Paxos协议通信等。

MySQL异步复制：

master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不care。slave接收到master binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知。假设master发生宕机并且binlog还没来得及被slave接收，而切换程序将slave提升为新的master，就会出现数据不一致的情况！另外，在高并发的情况下，传统的主从复制，从节点可能会与主产生较大的延迟。

MySQL半同步复制：

半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay log并且响应给master以后，才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的

MGR：

由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。
缺点：
只支持InnoDB存储引擎；
必须有主键；
必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set;

MySQL 主从同步配置

MySQL5.7安装前期准备

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 安装MySQL
sudo apt-get update
sudo apt-get install mysql-server
# 配置MySQL
sudo mysql_secure_installation
# 查看密码策略    
SHOW VARIABLES LIKE 'validate_password%';
# SET global validate_password_policy=LOW;
SET global validate_password_length=4;
# 查看密码规则 5.7后默认使用auth_socket认证插件
SELECT user, authentication_string, plugin, host FROM mysql.user;
# 更改策略
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY "root";
# 允许所有host的root用户远程连接
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'root'; 
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
# 允许远程连接
vim /etc/mysql/mysql.conf.d/mysqld.cnf # 注释bind-address = 127.0.0.1

主从同步配置

  • 主节点
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # Master
    log-bin=mysql-bin # 开启二进制日志
    server-id=1 [[设置server-id]]，需要唯一


    # 重启MySQL
    service mysql restart

    # 新建同步用户
    CREATE USER 'MySlave'@'192.168.56.112' IDENTIFIED BY 'root';
    GRANT REPLICATION SLAVE ON *.* TO 'MySlave'@'192.168.56.112';
    FLUSH PRIVILEGES;
  • 从节点
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    # Slave
    log-bin=mysql-bin # 开启二进制日志
    server-id=2 [[设置server-id]]，需要唯一

    # 重启MySQL
    service mysql restart

    # 主库ip / 主库用户 / 主库密码 / 主库bin log 文件名 / 主库文件偏移量
    CHANGE MASTER TO
        MASTER_HOST='192.168.56.111', 
        MASTER_USER='MySlave',
        MASTER_PASSWORD='root',
        MASTER_LOG_FILE='mysql-bin.000001',
        MASTER_LOG_POS=771;

    START SLAVE;

    SHOW SLAVE STATUS\G;