mysql共享存储ha

‘壹’ 详解Mysql 高可用方案 之 Failover mha

在分布式系统中，高可用性（High Availability，HA）是确保服务不中断的关键因素，尤其是在数据密集型应用中，数据库的高可用性尤为重要。当系统发生故障或意外中断时，保持数据库的可用性，确保业务连续性，是设计高可用性方案的核心目标。本文将详细探讨如何构建MySQL的高可用方案，特别是Failover（故障转移）机制，以及如何利用MHA（MySQL High Availability）工具实现这一目标。

MySQL官方社区版本在早期（如5.7及以前版本）在分布式和系统可用性方面的支持相对有限。因此，设计高可用性方案时，需要考虑如何在主服务器（Master）失效时，自动切换到备用服务器（Slave）或备份库，确保数据一致性，并最小化数据丢失。

Failover机制的实现依赖于数据复制。在分布式数据库系统中，数据复制是实现数据一致性、高可用性和容错性的关键。MySQL支持多种复制方式，包括同步复制、异步复制和半同步复制等，每种方式都有其优缺点。同步复制保证数据一致性，但可能影响主服务器的写入性能；异步复制则能保持较高的性能，但数据一致性无法得到保证；半同步复制在提供性能和一致性之间找到了平衡。

在MySQL中，实现Failover的关键是使用MHA（MySQL High Availability）工具。MHA能够自动在0到30秒内完成数据库故障切换，并在切换过程中最大程度地保证数据一致性。MHA通过检测主服务器状态并自动提升候选的从服务器为新的主服务器，同时通知其他从服务器连接新的主服务器进行复制，实现系统的平滑过渡。

MHA实现故障切换的逻辑包括以下几个步骤：
1. 从宕机崩溃的主服务器保存二进制日志事件（binlog events）。
2. 识别并选择具有最新更新的从服务器作为新的主服务器。
3. 将差异的日志应用到其他从服务器上。
4. 将从主服务器保存的二进制日志事件应用到新的主服务器。
5. 使其他从服务器连接新的主服务器进行复制。
6. 使其他从服务器连接新的主服务器进行复制。

MHA在实现高可用性方案时，通过网络分区检测和二次检测机制解决网络问题，确保系统在面对网络故障时能够正确判断主服务器状态，并避免误切换。此外，MHA还支持客户端自动恢复，确保分布式系统能够自我恢复服务。

为实现客户端的自动恢复，可以采用代理（Proxy）的方式。代理可以解析MySQL协议，根据不同的库、表和请求类型，将请求路由到后端合适的MySQL服务器。这种架构能够提供读写分离，提高性能并简化客户端的连接逻辑。在使用代理时，可以配置VIP（Virtual IP）和脚本，以便在主服务器故障时，自动切换到备用服务器，确保客户端无感知。

总结而言，通过MHA和代理工具的结合，可以构建出一种成本低、变更少、性能影响小的MySQL高可用性方案。该方案能够确保在主服务器故障时，系统能够快速切换到备用服务器，同时保持数据一致性，保证业务连续性。随着MySQL官方对分布式协议的支持加强，如MySQL Group Replication的推出，未来有望出现更多优化高可用性和数据一致性的解决方案。

‘贰’ 五大常见的MySQL高可用方案(最全)

1. 概述

我们在考虑MySQL数据库的高可用的架构时，主要要考虑如下几方面：

如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，保证业务不会因为数据库的故障而中断。

用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。

当业务发生数据库切换时，切换前后的数据库内容应当一致，不会因为数据缺失或者数据不一致而影响业务。

关于对高可用的分级在这里我们不做详细的讨论，这里只讨论常用高可用方案的优缺点以及高可用方案的选型。

2. 高可用方案

2.1. 主从或主主半同步复制

使用双节点数据库，搭建单向或者双向的半同步复制。在5.7以后的版本中，由于lossless replication、logical多线程复制等一些列新特性的引入，使得MySQL原生半同步复制更加可靠。

常见架构如下：

通常会和proxy、keepalived等第三方软件同时使用，即可以用来监控数据库的 健康 ，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。

优点：

架构比较简单，使用原生半同步复制作为数据同步的依据；

双节点，没有主机宕机后的选主问题，直接切换即可；

双节点，需求资源少，部署简单；

缺点：

完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；

需要额外考虑haproxy、keepalived的高可用机制。

2.2. 半同步复制优化

半同步复制机制是可靠的。如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。

该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。

可参考的优化方案如下：

2.2.1. 双通道复制

半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道，其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。另外一条异步复制通道开始追补从机落后的数据。当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。

2.2.2. binlog文件服务器

搭建两条半同步复制通道，其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。

优点：

双节点，需求资源少，部署简单；

架构简单，没有选主的问题，直接切换即可;

相比于原生复制，优化后的半同步复制更能保证数据的一致性。

缺点：

需要修改内核源码或者使用mysql通信协议。需要对源码有一定的了解，并能做一定程度的二次开发。

依旧依赖于半同步复制，没有从根本上解决数据一致性问题。

2.3. 高可用架构优化

将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。

由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。

但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择MMM、MHA或者各个版本的proxy等等。常见方案如下：

2.3.1. MHA+多节点集群

MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。

MHA也可以扩展到如下的多节点集群：

优点：

可以进行故障的自动检测和转移;

可扩展性较好，可以根据需要扩展MySQL的节点数量和结构;

相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低

缺点：

至少需要三节点，相对于双节点需要更多的资源;

逻辑较为复杂，发生故障后排查问题，定位问题更加困难;

数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;

可能因为网络分区发生脑裂现象;

2.3.2. zookeeper+proxy

Zookeeper使用分布式算法保证集群数据的一致性，使用zookeeper可以有效的保证proxy的高可用性，可以较好的避免网络分区现象的产生。

优点：

较好的保证了整个系统的高可用性，包括proxy、MySQL;

扩展性较好，可以扩展为大规模集群;

缺点：

数据一致性仍然依赖于原生的mysql半同步复制;

引入zk，整个系统的逻辑变得更加复杂;

2.4. 共享存储

共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

2.4.1. SAN共享储存

SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下：

使用共享存储时，MySQL服务器能够正常挂载文件系统并操作，如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。

优点：

两节点即可，部署简单，切换逻辑简单；

很好的保证数据的强一致性；

不会因为MySQL的逻辑错误发生数据不一致的情况；

缺点：

需要考虑共享存储的高可用；

价格昂贵；

2.4.2. DRBD磁盘复制

DRBD是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像，当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机(主节点)与远程主机(备节点)的数据就可以保证实时同步。常用架构如下：

当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。

DRBD是linux内核模块实现的快级别的同步复制技术，可以与SAN达到相同的共享存储效果。

优点：

两节点即可，部署简单，切换逻辑简单；

相比于SAN储存网络，价格低廉；

保证数据的强一致性；

缺点：

对io性能影响较大；

从库不提供读操作；

2.5. 分布式协议

分布式协议可以很好解决数据一致性问题。比较常见的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通过使用NDB存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。

优点：

全部使用官方组件，不依赖于第三方软件；

可以实现数据的强一致性；

缺点：

国内使用的较少；

配置较复杂，需要使用NDB储存引擎，与MySQL常规引擎存在一定差异；

至少三节点；

2.5.2. Galera

基于Galera的MySQL高可用集群， 是多主数据同步的MySQL集群解决方案，使用简单，没有单点故障，可用性高。常见架构如下：

优点：

多主写入，无延迟复制，能保证数据强一致性；

有成熟的社区，有互联网公司在大规模的使用；

自动故障转移，自动添加、剔除节点；

缺点：

需要为原生MySQL节点打wsrep补丁

只支持innodb储存引擎

至少三节点；

2.5.3. POAXS

Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。常见架构如下：

优点：

多主写入，无延迟复制，能保证数据强一致性；

有成熟理论基础；

自动故障转移，自动添加、剔除节点；

缺点：

只支持innodb储存引擎

至少三节点；

3. 总结

随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如MySQL自身的优化、MySQL集群架构的优化、Paxos、Raft、2PC算法的引入等等。

而使用分布式算法用来解决MySQL数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越来越多的被大规模使用。

随着官方MySQL Group Replication的GA，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，MySQL高可用问题可以被更好的解决。

‘叁’ MySQL表同步方法详解实现不同表数据自动同步mysql不同表数据同步

MySQL表同步方法详解：实现不同表数据自动同步！
在数据库中，有时需要将一个表的数据自动同步到另一个表中，这个过程通常称为表同步。MySQL提供了多种表同步方法，可以根据实际需求选择合适的方法。本文将详细介绍MySQL表同步方法及其实现步骤。
一、基于触发器的表同步方法
触发器是MySQL中的一种特殊的存储过程，它可以在表上或数据库上设置，当满足一定条件时自动执行。基于触发器的表同步方法，即通过在源表和目标表上设置相应的触发器，实现数据的自动同步。
示例代码：
/**
* 在源表上设置触发器，当有新的数据插入时将数据同步到目标表中
*/
CREATE TRIGGER trigger_insert AFTER INSERT ON source_table FOR EACH ROW
BEGIN
INSERT INTO target_table (col1, col2, col3) VALUES (NEW.col1, NEW.col2, NEW.col3);
END;
/**
* 在源表上设置触发器，当有数据更新时将数据同步到目标表中
*/
CREATE TRIGGER trigger_update AFTER UPDATE ON source_table FOR EACH ROW
BEGIN
UPDATE target_table SET col1 = NEW.col1, col2 = NEW.col2, col3 = NEW.col3 WHERE id = NEW.id;
END;
/**
* 在源表上设置触发器，当有数据删除时将数据从目标表中删除
*/
CREATE TRIGGER trigger_delete AFTER DELETE ON source_table FOR EACH ROW
BEGIN
DELETE FROM target_table WHERE id = OLD.id;
END;
优点：基于触发器实现的表同步方法具有数据一致性强、实时性高的优点。
缺点：触发器的执行会带来一定的性能开销，当数据量较大时，可能会影响服务器的性能。
二、基于存储过程的表同步方法
存储过程是MySQL中的一种特殊程序，可以接受输入参数并返回多个输出结果。基于存储过程的表同步方法，即通过在数据库中设置一个存储过程，定期执行存储过程，将源表数据同步到目标表中。
示例代码：
/**
* 创建存储过程，将源表数据同步到目标表中
*/
CREATE PROCEDURE sync_table()
BEGIN
INSERT INTO target_table (col1, col2, col3)
SELECT col1, col2, col3 FROM source_table;
END;
/**
* 定期执行存储过程，将数据同步到目标表中
*/
CREATE EVENT sync_event
ON SCHEDULE EVERY 1 MINUTE
DO CALL sync_table();
优点：基于存储过程实现的表同步方法具有数据处理能力强、可定制性高的优点。
缺点：基于存储过程实现的表同步方法需要定期执行，存在一定的延迟。
三、基于插件的表同步方法
插件是MySQL中的一种可插拔式存储引擎，它可以实现自定义的数据存储处理操作。基于插件的表同步方法，即通过自定义插件的方式，实现源表数据到目标表的同步。
示例代码：
/**
* 创建插件，将源表数据同步到目标表中
*/
class SyncPlugin : public mysql_storage_engine
{
public:
SyncPlugin(handlerton *hton, const char *name, int flags) : mysql_storage_engine(hton, name, flags) {}
virtual int open(const char *name, const char *mode, uint *flag, ha_create_info *create_info, int create_flags, ha_table_option *option);
virtual int close(void);
virtual int create(const char *name, int mode, ha_create_info *create_info, ha_table_option *option, const st_mysql_const_lex_string *db);
virtual int drop(const char *name);
virtual int rename(const char *from, const char *to, ha_table_option *option);
virtual int write_row(uchar *buf);
virtual int update_row(const uchar *old_data, uchar *new_data);
virtual int delete_row(const uchar *buf);
virtual int create_index(uint key_number, ha_keydef *key_info, const char *name);
virtual int delete_index(const char *name);
virtual int rename_index(const char *from, const char *to);
};
int SyncPlugin::write_row(uchar *buf)
{
int ret = mysql_storage_engine::write_row(buf);
if (ret == HA_ERR_END_OF_FILE) {
// 同步数据到目标表中
insert_into_target_table(buf);
}
return ret;
}
/**
* 注册插件
*/
mysql_declare_plugin(sync_plugin)
{
MYSQL_STORAGE_ENGINE_PLUGIN,
&SyncPlugin::descriptor,
“SyncPlugin”,
“1.0”,
“Yifei Wang”,
“”,
0x01,
nullptr,
nullptr
}
mysql_declare_plugin_end;
优点：基于插件的表同步方法具有可扩展性强、自定义性高的优点。
缺点：基于插件的表同步方法需要编写自定义插件，需要对MySQL存储引擎有较深的了解。
总结：
不同的表同步方法各有优缺点，根据实际需求选择合适的方法可提高数据的一致性和效率。除此之外，还可以通过第三方工具或高可用中间件等方式实现MySQL表数据的自动同步，帮助企业更好地管理数据。