组建MySQL集群的几种方案,优劣与讨论

合集下载

MySQL集群之五大常见的MySQL高可用方案(转)

MySQL集群之五大常见的MySQL高可用方案(转)

MySQL集群之五⼤常见的MySQL⾼可⽤⽅案(转)1. 概述我们在考虑MySQL数据库的⾼可⽤的架构时,主要要考虑如下⼏⽅⾯:如果数据库发⽣了宕机或者意外中断等故障,能尽快恢复数据库的可⽤性,尽可能的减少停机时间,保证业务不会因为数据库的故障⽽中断。

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

当业务发⽣数据库切换时,切换前后的数据库内容应当⼀致,不会因为数据缺失或者数据不⼀致⽽影响业务。

关于对⾼可⽤的分级在这⾥我们不做详细的讨论,这⾥只讨论常⽤⾼可⽤⽅案的优缺点以及⾼可⽤⽅案的选型。

2. ⾼可⽤⽅案2.1. 主从或主主半同步复制使⽤双节点数据库,搭建单向或者双向的半同步复制。

在5.7以后的版本中,由于lossless replication、logical多线程复制等⼀些列新特性的引⼊,使得MySQL原⽣半同步复制更加可靠。

常见架构如下:通常会和proxy、keepalived等第三⽅软件同时使⽤,即可以⽤来监控数据库的健康,⼜可以执⾏⼀系列管理命令。

如果主库发⽣故障,切换到备库后仍然可以继续使⽤数据库。

优点:1. 架构⽐较简单,使⽤原⽣半同步复制作为数据同步的依据;2. 双节点,没有主机宕机后的选主问题,直接切换即可;3. 双节点,需求资源少,部署简单;缺点:1. 完全依赖于半同步复制,如果半同步复制退化为异步复制,数据⼀致性⽆法得到保证;2. 需要额外考虑haproxy、keepalived的⾼可⽤机制。

2.2. 半同步复制优化半同步复制机制是可靠的。

如果半同步复制⼀直是⽣效的,那么便可以认为数据是⼀致的。

但是由于⽹络波动等⼀些客观原因,导致半同步复制发⽣超时⽽切换为异步复制,那么这时便不能保证数据的⼀致性。

所以尽可能的保证半同步复制,便可提⾼数据的⼀致性。

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

MySQL数据库的集群方案和高可用性架构介绍

MySQL数据库的集群方案和高可用性架构介绍

MySQL数据库的集群方案和高可用性架构介绍引言MySQL是一种开源的关系型数据库管理系统,广泛用于各种规模的应用中。

为了满足大规模应用的需求,MySQL提供了一系列的集群方案和高可用性架构。

本文将介绍一些常用的MySQL集群方案和高可用性架构,以及它们的特点和适用场景。

一、数据库集群概述数据库集群是通过多个数据库实例进行数据共享和负载均衡,以提高性能和可用性的方案。

在数据库集群中,每个节点都是相互独立的数据库实例,它们可以是主-从结构、主-主结构或者其他形式。

当一个节点发生故障时,系统可以自动切换到其他可用节点,从而保证系统的可用性。

二、MySQL集群方案1. MySQL复制MySQL复制是最简单的集群方案之一。

它基于主-从结构,将数据从一个主节点复制到多个从节点。

主节点负责处理写操作,从节点负责处理读操作。

MySQL 复制具有易于实现、低成本和高可用性的特点。

然而,由于从节点只能读取数据,所以写操作需要在主节点上执行,可能会引发一些性能瓶颈。

2. MySQL主-主复制MySQL主-主复制是一种分布式架构,每个节点既是读节点又是写节点。

主-主复制通过双向复制实现数据的同步,从而提供更好的读、写负载均衡和高可用性。

然而,主-主复制需要处理数据冲突和一致性问题,配置和维护也相对复杂。

3. MySQL分片MySQL分片是一种将数据水平划分到多个节点上的集群方案。

每个节点只存储部分数据,通过分片策略将查询路由到正确的节点上。

分片可以提高系统的可伸缩性和性能,但也会增加架构的复杂性。

分片需要考虑数据切分、数据迁移、数据一致性和节点故障等问题。

三、MySQL高可用性架构1. 主-从复制+故障检测与切换主-从复制结合故障检测与切换是一种常见的MySQL高可用性架构。

其中,主节点负责处理写操作,从节点用于读操作和故障恢复。

故障检测与切换组件可以监控主节点的状态,并在主节点故障时自动将从节点升级为新的主节点。

这种架构具有简单、可靠和成本较低的特点。

多图文详细介绍mysql各个集群方案

多图文详细介绍mysql各个集群方案

多图文详细介绍mysql各个集群方案MySQL是一个开源的关系型数据库管理系统,已经成为了业界最流行的数据库之一、由于单机MySQL数据库的性能有限,为了提高数据库的可用性、扩展性和性能,业界提出了各种MySQL集群方案,本文将详细介绍几种常见的MySQL集群方案。

1.MySQL主从复制集群:MySQL主从复制是一种简单而常用的集群方案。

该方案通过一个主数据库和多个从数据库实现数据的异步复制,主数据库负责写入操作,从数据库负责读取操作。

主从复制具有以下特点:-主数据库可以提供写入的高性能,从数据库可以提供读取的高性能。

-从数据库可以用于灾备,一旦主数据库出现故障,可以快速切换到从数据库继续提供服务。

-主从复制的实现较为简单,不需要引入复杂的集群管理软件。

-主从复制的缺点是从数据库的数据有一定的延迟。

2.MySQL双主集群:MySQL双主集群是一种更进一步的集群方案,通过在多个数据库之间实现双向复制,实现了数据库的读写分离。

双主集群具有以下特点:-双主结构可以提供更高的可用性,一旦一个数据库出现故障,可以快速切换到另一个数据库继续提供服务。

-双主结构可以提供更高的性能,读写操作可以同时在两个数据库上进行。

-双主集群的缺点是配置和管理比较复杂,需要保证数据的一致性和冲突解决。

3.MySQL分片集群:MySQL分片集群通过将数据分散到多个数据库节点上实现横向扩展,以应对海量数据的处理需求。

分片集群具有以下特点:-分片集群可以提供无限的水平扩展性,可以随着数据的增长增加更多的节点。

-分片集群可以提供更好的性能,可以将负载均衡到多个节点上。

-分片集群的缺点是管理和维护成本较高,需要处理数据的分片和路由问题。

4.MySQL主备集群:MySQL主备集群通过在多个数据库节点之间实现实时数据同步,实现了高可用性和故障切换。

主备集群具有以下特点:-主备结构可以提供高可用性,一旦主节点出现故障,可以自动切换到备用节点继续提供服务。

mysql 集群方案

mysql 集群方案

MySQL 集群方案引言MySQL 是一种常用的关系型数据库管理系统,具有高性能、稳定性和可靠性。

然而,在高并发和大数据量的情况下,单机 MySQL 往往无法满足需求。

为了解决这一问题,可以采用集群方案来提高数据库的性能和可扩展性。

本文将介绍几种常见的 MySQL 集群方案,包括主从复制、主主复制和分片存储,并对它们的原理、优缺点进行分析。

此外,还将讨论如何选取最适合应用需求的 MySQL 集群方案。

1. 主从复制主从复制是最常见的 MySQL 集群方案之一。

它通过将一个 MySQL 服务器作为主节点,其他服务器作为从节点,实现数据的同步和复制。

主节点接收所有的写操作,并将写入的数据同步到从节点,从节点只负责读操作。

主从复制的原理是通过二进制日志将主节点的更新操作记录下来,然后从节点读取这些日志并执行相同的操作,以达到数据的同步和复制。

主从复制的优点是实现简单、易于管理和部署,同时可以提高读取数据的性能和提供高可用性。

然而,主从复制也存在一些缺点,如写操作集中在主节点、主节点故障需要手动切换等。

2. 主主复制主主复制是另一种常见的 MySQL 集群方案。

它和主从复制的区别是,主节点能够接收读写操作,从节点也可以接收读写操作。

这样可以实现负载均衡和高可用性。

主主复制的原理和主从复制类似,但需要对数据同步进行更复杂的处理。

通过在主节点之间进行双向同步,确保数据的一致性。

主主复制的优点是读写分散、高可用性和负载均衡。

然而,主主复制也存在一些问题,如数据冲突和同步延迟。

3. 分片存储当数据量非常大时,即使使用主从复制或主主复制也无法满足需求。

这时可以采用分片存储的方式来解决。

分片存储将数据按照一定的规则分散存储在不同的节点上,每个节点可以独立进行读写操作。

分片存储的原理是根据某一列或一组列的值进行分片,将相同值的数据存储在同一个节点上。

通过路由算法将查询请求发送到对应的节点上,以实现数据的分布式存储和查询。

mysql集群解决方案

mysql集群解决方案

mysql集群解决方案
《MySQL集群解决方案》
随着互联网应用的不断发展,数据库需求量也在不断增加。

为了提高数据库的性能和可用性,很多企业都开始使用数据库集群解决方案。

MySQL作为开源的关系型数据库管理系统,也
有着丰富的集群解决方案可供选择。

MySQL集群解决方案一般包括以下几种形式:主从复制、多
主复制、基于分布式文件系统的集群和基于分布式数据库的集群。

主从复制是最简单的MySQL集群解决方案,它通过在一个主
数据库上进行数据更新,然后将更新同步到多个从数据库上来实现负载均衡和故障转移。

多主复制则是在主从复制的基础上,实现了多个主数据库之间的双向同步,从而提高了数据库的可用性和性能。

基于分布式文件系统的集群是通过将数据库文件存储在一个共享的分布式文件系统中,从而实现了多个数据库实例之间的文件共享和数据同步。

而基于分布式数据库的集群则是通过将数据分片存储在不同的数据库实例上,每个实例只存储一部分数据,从而实现了数据库的分布式存储和查询加速。

在选择MySQL集群解决方案时,需要根据实际业务需求和性
能要求来进行选择。

同时,还需要考虑集群的部署和维护成本,以及数据一致性和故障恢复等方面的问题。

总的来说,MySQL集群解决方案可以帮助企业提高数据库的性能和可用性,从而满足不断增长的数据库需求。

通过选择适合自己业务需求的集群解决方案,并进行合理的部署和维护,可以有效地提升数据库的安全性和可靠性。

MySQL中的集群和负载均衡配置和优化

MySQL中的集群和负载均衡配置和优化

MySQL中的集群和负载均衡配置和优化I. 引言MySQL是一种广泛使用的关系型数据库管理系统,它支持集群和负载均衡配置,以实现高可用性和性能。

在本文中,我们将探讨MySQL中集群和负载均衡的配置和优化方法,以帮助开发人员和系统管理员更好地管理和优化MySQL数据库。

II. MySQL集群配置MySQL集群是通过在多个数据库服务器之间共享负载和数据来提高系统的可扩展性和可用性。

以下是一些在MySQL中配置集群的步骤和技巧:1. 选择适当的集群解决方案:MySQL提供了几种集群解决方案,如MySQL Cluster、Percona XtraDB Cluster和Galera Cluster等。

选择适合你的需求的解决方案至关重要,因为它们可能有不同的功能和性能特点。

2. 设计适当的集群拓扑:在配置MySQL集群之前,需要仔细设计拓扑结构。

例如,可以选择单主模式或主-从模式。

单主模式下只有一个主数据库处理写请求,而主-从模式中,一个主数据库处理写请求,而多个从数据库处理读请求。

3. 配置适当的数据同步策略:在MySQL集群中,数据同步是非常重要的,因为它确保了数据在多个数据库服务器之间的一致性。

MySQL提供了多种数据同步策略,如异步复制和半同步复制。

根据实际情况选择最适合的策略。

III. MySQL负载均衡配置负载均衡是通过将负载分布到多个数据库服务器上来提高系统性能和可用性的方法。

以下是一些在MySQL中配置负载均衡的步骤和技巧:1. 使用负载均衡器:负载均衡器是实现负载均衡的关键组件。

有很多开源和商业的负载均衡器可以选择,如HAProxy、Nginx和MySQL Router等。

选择适合的负载均衡器,并根据实际需求进行配置。

2. 配置合适的负载均衡算法:负载均衡算法决定了如何将负载分配到多个数据库服务器上。

常见的负载均衡算法包括轮询、权重和最少连接数等。

根据应用程序的特点选择适当的负载均衡算法。

MySQL数据库的集群方案

MySQL数据库的集群方案

MySQL数据库的集群⽅案读写分离结构(主从)读多写少,也就是对数据库读取数据的压⼒⽐较⼤。

其中⼀个是主库,负责写⼊数据,成为写库;其他都是从库,负责读取数据,成为读库。

对我们的要求:读库和写库的数据⼀致;写数据必须写到写库;读数据必须到读库;集群⽅案与单节点的差异:数据库从之前的单节点变为多节点提供服务;主节点数据,同步从节点数据;应⽤程序需要连接2个数据库节点,并且在程序内部实现判断读写操作;这种⽅案的缺点:应⽤程序需要连接到多个节点,对应⽤程序⽽⾔变得复杂;这个问题可以通过中间件解决;如果在程序内部实现,可使⽤Spring的AOP功能实现;主从之间的同步,是异步完成,也就意味着是弱⼀致性;可能会导致数据写⼊主库后,应⽤程序读取从库获取不到数据,或者可能会丢失数据,对于数据安全性要求⽐较⾼的应⽤是不合适的;该问题可以通过PXC集群解决;中间件应⽤程序会连接到多个节点,使得应⽤程序的复杂度提升,可以通过中间件⽅式解决。

应⽤程序只需要连接到中间件即可,⽆需连接多个数据库节点;应⽤程序⽆需区分读写操作,对中间件直接进⾏读写操作即可;在中间件中进⾏区分读写操作,读操作发送到从节点,写操作发送到主节点;这种⽅式的架构也存在问题,中间件的性能成为系统的瓶颈,但是可以使⽤多个中间件部署的⽅式进⾏缓解。

这样的话,中间件的可靠性得到了保证,但是也带来了新的问题,应⽤系统依然需要连接2个中间件,增加了应⽤系统的复杂度。

负载均衡为了解决以上问题,我们将继续优化架构,在应⽤程序和中间件之间增加proxy代理,由代理来完成负载均衡的功能,应⽤程序只需要对接到proxy即可。

PXC集群架构在前⾯的架构中,都是基于MySQL主从的架构,那么在主从机构中,弱⼀致性问题依然没有解决,如果在需要强⼀致性的需求中,显然这种架构是不能应对的,⽐如:交易数据。

PCX提供了读写强⼀致性的功能,可以保证数据在任何⼀个节点写⼊的同时可以同步到其他节点,也就意味着可以从其他的任何节点进⾏读取操作,⽆延迟。

MySQL的高可用解决方案比较与选型指南

MySQL的高可用解决方案比较与选型指南

MySQL的高可用解决方案比较与选型指南引言:在当今互联网应用需求日益多样化和复杂化的环境下,数据库的可用性和稳定性显得尤为重要。

MySQL作为一款开源的关系型数据库管理系统,得到了广泛的应用和发展。

为了提高MySQL的高可用性,不同的解决方案应运而生。

本文将介绍几种常见的MySQL高可用解决方案,并给出相应的选型指南,以供读者参考。

一、MySQL主从复制方案主从复制是MySQL最常见也最简单的高可用解决方案之一。

它通过将一台MySQL服务器(主服务器)的数据实时地复制到其他多台MySQL服务器(从服务器)上,实现数据的备份和冗余存储。

主从复制的好处是简单易用、实现成本低,适用于大部分中小型应用场景。

然而,主从复制也存在一些限制,如主服务器故障时会有较长时间的切换和数据一致性的问题。

二、MySQL主从复制+Keepalived的方案为了解决主从复制方案的切换延迟和数据一致性问题,一种常见的改进方案是在主从复制的基础上加入Keepalived。

Keepalived是一个IP故障切换工具,它能够在主服务器出现故障时,快速将一个虚拟IP切换到备份服务器上,实现高可用性。

该方案简单易用,对应用程序透明,但配置和管理相对复杂。

三、MySQL主从复制+Heartbeat的方案Heartbeat是一个开源的高可用性软件,通过监控网络和主服务器的状态,实现服务器故障切换和自动切换。

与Keepalived相比,Heartbeat功能更为强大,可以实现更复杂的故障处理策略。

但同时也带来了更复杂的配置和管理。

四、MySQL主从复制+MHA的方案MHA(MySQL Master High Availability)是由MySQL官方推出的一款高可用性解决方案。

相较于前面提到的Keepalived和Heartbeat,MHA提供了更完整的解决方案,包括自动监控、故障检测、自动切换等功能。

MHA具有较高的稳定性和数据一致性,并支持在线切换和平滑的主从切换。

mysql数据库集群方案

mysql数据库集群方案

MySQL数据库集群方案简介MySQL数据库集群是指将多个MySQL服务器组成集群,提供高可用性、伸缩性和容错性。

通过将数据分布在多个服务器上,可以提高系统的性能和可靠性。

本文将介绍MySQL数据库集群的基本概念、优势和常用的集群方案。

基本概念1. 主从复制主从复制是MySQL中常用的一种数据库集群方案。

它通过将一个MySQL服务器配置为主服务器(Master)和一个或多个MySQL服务器配置为从服务器(Slave),将主服务器上的数据复制到从服务器上。

主从复制的工作原理是主服务器将修改的数据写入二进制日志文件(binlog),从服务器通过读取主服务器的binlog文件来同步数据。

主从复制的优势在于简单可靠,但复制延迟可能会影响性能。

2. 共享存储共享存储是另一种常见的MySQL数据库集群方案。

它将多个MySQL服务器连接到同一个存储系统上,实现数据的共享和高可用性。

共享存储方案可以使用网络存储协议(如NFS、iSCSI等)或分布式文件系统(如GlusterFS、Ceph等)来实现。

共享存储的优势在于数据一致性和故障容错,但在高并发访问时可能存在性能瓶颈。

3. 数据分片数据分片是一种将数据分散存储在多个MySQL服务器上的集群方案。

它将数据分成多个逻辑分片,每个分片存储在独立的MySQL服务器上。

数据分片可以根据不同的规则进行,如按照数据表、数据行、哈希等方式进行划分。

数据分片的优势在于扩展性和负载均衡,但需要应用程序支持分片规则。

优势MySQL数据库集群方案具有以下几个主要优势:1.高可用性:通过多个服务器实时同步数据,保证系统在单点故障时的可用性。

2.伸缩性:通过增加服务器节点,可以扩展系统的存储容量和并发处理能力。

3.容错性:当一个服务器故障时,其他服务器可以继续提供服务,不影响系统的正常运行。

4.负载均衡:通过将数据分布在多个服务器上,可以均匀分摊访问压力,提高系统的性能和响应速度。

5.数据一致性:通过复制、共享存储或数据分片等机制,保证多个服务器的数据一致性。

MySQL数据库的集群和分布式部署方案

MySQL数据库的集群和分布式部署方案

MySQL数据库的集群和分布式部署方案引言随着互联网及大数据时代的到来,数据量的快速增长使得传统的数据库架构面临着一系列的挑战。

MySQL作为目前最为常用的关系型数据库之一,也需要采用集群和分布式部署方案来满足高可用、高性能和高扩展性的需求。

本文将探讨MySQL数据库的集群和分布式部署方案,并分析各种方案的优缺点。

一、MySQL集群方案MySQL集群是指将多个数据库服务器连接在一起,形成一个逻辑上的整体,提供高可用和高性能的数据库服务。

常用的MySQL集群方案有主从复制、主从切换和半同步复制。

1. 主从复制主从复制是MySQL集群中最常用的方案之一。

它通过一个主数据库(Master)将数据同步到多个从数据库(Slave),实现数据的复制和读写分离。

主从复制的优点是容易部署和维护,可以提供较高的可用性和性能。

但是,主从复制也存在一些问题,如数据一致性的延迟和只能支持读写分离,无法实现写操作的负载均衡。

2. 主从切换主从切换是在主从复制的基础上进一步发展而来的方案。

它通过在多个从数据库中选举一个作为新的主数据库,实现主备切换。

主从切换的优点是可以提供更高的可用性,当主数据库故障时能够快速切换到备数据库。

但是,主从切换也存在一些问题,如切换过程中可能会有数据丢失和应用层的连接中断。

3. 半同步复制半同步复制是在主从复制的基础上改进的方案,通过在主数据库确认写操作成功后,才将其同步到从数据库,确保数据的一致性。

半同步复制的优点是提供了更高的数据一致性和可用性。

但是,半同步复制也存在一些问题,如对主数据库的写操作有一定的延迟,并且需要额外的网络开销。

二、MySQL分布式部署方案MySQL分布式部署是将一个数据库拆分成多个子数据库部署在不同的节点上,通过分片、分区和数据复制等方式实现数据的分散存储和查询。

常用的MySQL分布式部署方案有垂直切分、水平切分和分区表。

1. 垂直切分垂直切分是将数据库按照表或列进行切分,将不同的表或列存放在不同的节点上。

mysql 集群方案

mysql 集群方案

mysql 集群方案MySQL 集群方案随着互联网应用的快速发展,数据库的高可用性和高性能成为企业关注的焦点。

而MySQL作为目前最流行的开源关系型数据库之一,其集群方案被广泛应用于大型企业和互联网公司的数据库架构中。

一、什么是MySQL集群方案MySQL集群方案是指通过将多个MySQL数据库服务器组成一个集群,实现数据的分布式存储和负载均衡,从而提高数据库的可用性和性能。

MySQL集群方案通常包括主从复制、读写分离、分片等技术,可以根据实际业务需求选择不同的方案组合。

二、主从复制主从复制是MySQL集群方案中最基础的技术之一。

通过将一个MySQL服务器作为主服务器,其他MySQL服务器作为从服务器,实现主服务器上数据的实时同步到从服务器上。

主从复制可以提高数据库的可用性,当主服务器出现故障时,可以快速切换到从服务器上继续提供服务。

三、读写分离读写分离是MySQL集群方案中常用的一种技术。

通过将读操作和写操作分离到不同的MySQL服务器上,可以提高数据库的性能和并发处理能力。

读写分离的原理是在主服务器上进行写操作,然后将写操作的日志同步到从服务器上,读操作则可以直接在从服务器上执行,减轻主服务器的负载压力。

四、分片分片是MySQL集群方案中处理大数据量的一种技术。

当单个MySQL服务器无法满足业务需求时,可以将数据分片存储在多个MySQL服务器上,每个MySQL服务器只负责一部分数据的存储和查询。

分片可以提高数据库的横向扩展能力,适用于数据量大且读写请求分布均匀的场景。

五、负载均衡负载均衡是MySQL集群方案中保证数据库性能的重要手段。

通过在MySQL服务器前面增加负载均衡器,将客户端的请求均匀分发到多个MySQL服务器上,避免单个MySQL服务器的负载过高。

负载均衡可以提高数据库的并发处理能力,保证系统的稳定性和可用性。

六、高可用性高可用性是MySQL集群方案的核心目标之一。

通过主从复制、读写分离、分片等技术,可以实现数据库的高可用性。

MySQL数据库集群架构设计与部署

MySQL数据库集群架构设计与部署

MySQL数据库集群架构设计与部署引言:近年来,随着互联网的快速发展和数据量的快速增长,数据库作为数据存储和管理的核心组件,承担着越来越重要的角色。

传统单机数据库在处理大规模数据并发访问时往往性能有限,无法满足高可用性和高负载的需求。

因此,数据库集群架构应运而生。

本文将探讨MySQL数据库集群架构的设计与部署,并介绍其主要特点与优势。

一、MySQL集群架构的概述MySQL集群架构是指通过将多个数据库节点组成一个逻辑集群,实现数据库的分布式存储和高可用性。

一般而言,MySQL集群包括以下三个组件:1. 数据节点(Data Node):负责存储和处理数据,每个数据节点都包含一个MySQL数据库实例。

数据节点可以通过水平扩展来实现数据库性能的提升。

2. 管理节点(Management Node):负责管理整个集群的配置、监控和故障恢复等任务。

管理节点可以通过增加冗余节点来保证集群的高可用性。

3. MySQL Proxy:作为集群服务的前端入口,负责路由请求和负载均衡,将请求分发到对应的数据节点进行处理。

通过以上三个组件的协同工作,MySQL集群架构实现了数据库的高可用性、数据的负载均衡和性能的水平扩展。

二、MySQL集群架构的设计要素1. 数据一致性:数据库集群中的所有数据节点应保持一致的数据副本,以确保数据的完整性和一致性。

为了实现数据一致性,可以采用同步复制或异步复制的方式。

同步复制可以提供较高的数据一致性,但会对性能产生较大的影响,而异步复制则可以提供较好的性能但牺牲了一定的数据一致性。

2. 故障恢复:在数据库集群中,节点故障是不可避免的。

为了保证系统的可用性,需要能够快速检测到节点故障,并进行自动切换,将故障节点替换为备用节点。

此外,还需要定期备份和恢复数据,以应对更严重的故障情况。

3. 负载均衡:数据库集群应能够实现请求的自动分发和负载均衡,以充分利用各个节点的处理能力,提高系统的整体性能。

mysql数据库集群方案

mysql数据库集群方案

mysql数据库集群方案随着互联网的快速发展,大型网站的访问量逐渐增加,单机mysql已经不能满足高并发、高可用、海量数据的需求。

因此,mysql数据库集群方案应运而生。

1.集群基础架构mysql集群是由多台服务器组成,它们协同工作以提供更高的可用性和可扩展性。

主要的组件包括管理节点、数据节点和客户端接口。

1.1 管理节点管理节点控制集群中的所有数据节点,并管理数据、用户和节点。

它还负责控制故障检测和修复。

管理节点可以被安装在物理服务器、虚拟机中或是云服务中。

1.2 数据节点数据节点是存储数据的主要组成部分,每个数据节点都包括一个mysql服务器实例和文件系统。

数据节点可以在物理服务器或虚拟机中安装。

每个数据节点都包含一部分数据,通过数据分片技术实现数据的分散存储。

1.3 客户端接口客户端接口是集群应用程序和集群之间的通信通道。

这个组件提供给应用程序公共命令和API,已实现对集群的管理和操作。

例如,可将在一个节点上执行的命令传递给整个集群中的所有节点。

2. 集群配置通常,在您配置mysql集群之前,需要考虑以下因素:2.1 负载均衡为了使集群运作良好,必须保持负载均衡。

通常,此功能通过VIP(虚拟IP)和透明路由器实现。

2.2 数据备份您可以使用MySQL自带的复制功能来备份数据。

另外,一些第三方备份和恢复方案也可用于mysql集群。

2.3 集群容错确保所有节点连通性通常需要在应用程序与查询期间检查节点。

在检测到故障时,故障的节点将自动从集群中删除,让其他节点继续提供服务。

2.4 系统监控系统监控是mysql集群的重要组成部分。

它可用于监控组件和节点的运行,以及故障检测和诊断。

3. mysql集群方案mysql有许多集群方案,其中最为常用的包括MySQL cluster、Galera cluster和Percona XtraDB Cluster。

3.1 MySQL ClusterMySQL Cluster是由MySQL AB开发的开源集群方案,可扩展性高、高可用性和很好的负载均衡。

mysql高可用方案

mysql高可用方案

Mysql 高可用方案1. 引言MySQL 是广泛使用的关系型数据库管理系统,但在高可用性方面仍然存在一些挑战。

尽管 MySQL 自带了一些高可用性功能,例如主从复制和分区复制,但这些功能并不能完全保证数据库的连续可用性。

因此,为了应对数据库故障和性能问题,需要实施一种高可用方案。

本文将介绍一些常见的 MySQL 高可用方案,包括主从复制、MySQL Cluster、Galera Cluster 和基于云平台的高可用方案,并讨论它们的优缺点。

2. 主从复制主从复制是 MySQL 自带的一种高可用性功能。

在主从复制中,一个 MySQL 服务器充当主节点,而一个或多个服务器充当从节点。

主节点负责接收和处理写操作,然后将写操作的日志发送给从节点。

从节点将接收到的日志应用到自己的数据库上,从而保持与主节点的一致性。

主从复制的优点包括简单、易于部署和维护。

此外,主从复制还可以提高读取性能,因为读操作可以在从节点上并行处理。

然而,主从复制也存在一些局限性。

首先,主从复制的同步性可能是异步的,这意味着从节点可能无法实时地与主节点保持一致。

其次,主从复制无法提供对写操作的故障转移支持,因此在主节点故障时需要手动进行切换。

3. MySQL ClusterMySQL Cluster 是一种基于共享存储的高可用性方案。

它通过将数据划分为不同的片段,并部署在多个节点上来实现高可用性和可伸缩性。

每个节点都包含存储引擎、数据节点和管理节点。

MySQL Cluster 的优点之一是可以提供实时数据访问和高并发性能。

此外,它还具备自动故障检测和恢复的能力,因此可以快速处理节点故障。

另外,MySQL Cluster 还支持动态扩展和在线维护。

然而,MySQL Cluster 也有一些限制。

首先,MySQL Cluster 的配置和管理相对复杂,需要特定的专业知识。

其次,它对硬件要求较高,需要使用高性能的硬件。

此外,MySQL Cluster 不支持所有的 SQL 特性,例如存储过程和触发器。

Mysql集群搭建(多实例、主从)

Mysql集群搭建(多实例、主从)

Mysql集群搭建(多实例、主从)1 MySQL多实例⼀、MySQL多实例介绍1、什么是MySQL多实例MySQL多实例就是在⼀台机器上开启多个不同的服务端⼝(如:3306,3307,3308),运⾏多个MySQL服务进程,通过不同的socket监听不同的服务端⼝来提供各⾃的服务。

2、MySQL多实例的特点有以下⼏点有效利⽤服务器资源,当单个服务器资源有剩余时,可以充分利⽤剩余的资源提供更多的服务。

节约服务器资源资源互相抢占问题,当某个服务实例服务并发很⾼时或者开启慢查询时,会消耗更多的内存、CPU、磁盘IO资源,导致服务器上的其他实例提供服务的质量下降;3、部署mysql多实例的两种⽅式第⼀种是使⽤*多个配置⽂件启动*不同的进程来实现多实例,这种⽅式的优势逻辑简单,配置简单,缺点是管理起来不太⽅便;第⼆种是通过官⽅⾃带的*mysqld_multi*使⽤单独的配置⽂件来实现多实例,这种⽅式定制每个实例的配置不太⽅⾯,优点是管理起来很⽅便,集中管理;4、同⼀开发环境下安装多个数据库,必须处理以下问题配置⽂件安装路径不能相同数据库⽬录不能相同启动脚本不能同名端⼝不能相同socket⽂件的⽣成路径不能相同2 mysql多实例搭建⼀、mysqld_multi搭建1、下载免编译⼆进制包下载地址:mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz2、解压和迁移cd /usr/local#将安装包拖进local⽂件夹下并解压tar -zxvf mysql-5.7.17-linux-glibc2.5-x86_64.tar.gzmv mysql-5.7.17-linux-glibc2.5-x86_64 mysql3、关闭iptables#临时关闭service iptables stop#永久关闭chkconfig iptables off4、关闭selinuxvi /etc/sysconfig/selinux#将SELINUX修改为DISABLED,即SELINUX=DISABLED5、创建mysql系统⽤户和组groupadd -g 27 mysqluseradd -u 27 -g mysql mysqlid mysql*6**、创建**mysql**⽬录*mkdir -p /data/mysql/mysql_3306/datamkdir -p /data/mysql/mysql_3306/logmkdir -p /data/mysql/mysql_3306/tmpmkdir -p /data/mysql/mysql_3307/datamkdir -p /data/mysql/mysql_3308/datamkdir -p /data/mysql/mysql_3308/logmkdir -p /data/mysql/mysql_3308/tmp*7**、更改⽬录权限**#**任意⽬录下,输⼊*chown -R mysql:mysql /data/mysql/chown -R mysql:mysql /usr/local/mysql/*8**、添加环境变量*echo 'export PATH=$PATH:/usr/local/mysql/bin' >> /etc/profilesource /etc/profile*9**、复制**f**⽂件到**etc**⽬录*#将原来的f⽂件删除了cp /usr/local/mysql/support-files/f /etc/f*10**、修改**f**(在⼀个⽂件中修改即可)*vi /etc/f[client]port=3306socket=/tmp/mysql.sock[mysqld_multi]mysqld = /usr/local/mysql/bin/mysqld_safemysqladmin = /usr/local/mysql/bin/mysqladminlog =/data/mysql/mysqld_multi.log[mysqld]basedir = /usr/local/mysqlsql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES#3306数据库[mysqld3306]mysqld=mysqldmysqladmin=mysqladmindatadir=/data/mysql/mysql_3306/dataport=3306server_id=3306socket=/tmp/mysql_3306.socklog-output=fileslow_query_log = 1long_query_time = 1slow_query_log_file = /data/mysql/mysql_3306/log/slow.loglog-error = /data/mysql/mysql_3306/log/error.logbinlog_format = mixedlog-bin = /data/mysql/mysql_3306/log/mysql3306_bin#3307数据库[mysqld3307]mysqld=mysqldmysqladmin=mysqladmindatadir=/data/mysql/mysql_3307/dataport=3307server_id=3307socket=/tmp/mysql_3307.socklog-output=fileslow_query_log = 1long_query_time = 1slow_query_log_file = /data/mysql/mysql_3307/log/slow.loglog-error = /data/mysql/mysql_3307/log/error.logbinlog_format = mixedlog-bin = /data/mysql/mysql_3307/log/mysql3307_bin#3308数据库[mysqld3308]mysqld=mysqldmysqladmin=mysqladmindatadir=/data/mysql/mysql_3308/dataport=3308server_id=3308socket=/tmp/mysql_3308.socklog-output=fileslow_query_log = 1long_query_time = 1slow_query_log_file = /data/mysql/mysql_3308/log/slow.loglog-error = /data/mysql/mysql_3308/log/error.logbinlog_format = mixedlog-bin = /data/mysql/mysql_3308/log/mysql3308_bin*11**、**初始化数据库**#**初始化**3306**数据库*/usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/mysql_3306/data --defaults-file=/etc/f*#**初始化**3307**数据库*/usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/mysql_3307/data --defaults-file=/etc/f*#**初始化**3308**数据库*/usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/mysql_3308/data --defaults-file=/etc/f*12**、查看数据库是否初始化成功*查看3306、3307、3308数据库cd /data/mysql/mysql_3306/data/13、*设置启动⽂件*cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql14、*mysqld_multi**进⾏多实例管理*启动全部实例:/usr/local/mysql/bin/mysqld_multi start查看全部实例状态:/usr/local/mysql/bin/mysqld_multi report启动单个实例:/usr/local/mysql/bin/mysqld_multi start 3306停⽌单个实例:/usr/local/mysql/bin/mysqld_multi stop 3306查看单个实例状态:/usr/local/mysql/bin/mysqld_multi report 3306#*启动全部实例*/usr/local/mysql/bin/mysqld_multi start/usr/local/mysql/bin/mysqld_multi report# *查看启动进程*ps -aux | grep mysql#进⼊tmp⽬录,查看sock⽂件cd /tmp15、*修改密码*mysql的root⽤户初始密码是空,所以需要登录mysql进⾏修改密码,下⾯以3306为例:mysql -S /tmp/mysql_3306.sockset password for root@'localhost'=password('xxxxxx');flush privileges;#修改3307数据库密码mysql -S /tmp/mysql_3307.sockset password for root@'localhost'=password('xxxxxx');flush privileges;#修改3308数据库密码mysql -S /tmp/mysql_3307.sockset password for root@'localhost'=password('xxxxxx');flush privileges;16、*新建⽤户及授权*⼀般新建数据库都需要新增⼀个⽤户,⽤于程序连接,这类⽤户只需要insert、update、delete、select权限。

mysql各种集群的优缺点

mysql各种集群的优缺点

mysql各种集群的优缺点
mysql各种集群的优缺点
1.主从架构:只是有数据备份的功能;
2.主主互备+keepalived:实现数据备份加⾼可⽤;
3.主主互备,主主下⾯分别挂个从;
4.A和B主主互备,把从库都挂到B下,减少IO问题;
5.MMM架构,perl编写,基于mysql主从复制,成熟⾼可⽤集群⽅案,由⼀个管理端(monitor)和多个代理端(aget)构成
优点:监控所有Master节点及Slave节点状态,当master节点出现故障,会把vip⾃动转移到健康节点上;更重要的是当Master节点发⽣故障,会⾃动将后端Slave节点转向备⽤的Master节点继续同步复制,切换过程不需要⼈⼯⼲预;
缺点:对ip,服务器数量有要求(⾄少两台服务器,2个真实ip,3个vip);业务繁忙,数据量⼤的时候不是很稳定,会出现复制延时,切换失效等问题;所以MMM⽅案不适合应⽤于对数据安全性要求很⾼,并读写频繁的环境中。

数据量⼤的时候,会有主从数据不同步的问题;
6.MHA架构,搭建起来⽐较⿇烦,⾄少三台机器,淘宝进⾏过⼆次开发,可以⽤两台机器;
读写分离中间件:
7.mysqlproxy:通过lua脚本实现的读写分离,不太稳定,官⽹不建议⽤;
8.Amoeba:致⼒于mysql分布式数据库前端代理层,它主要在应⽤层,访问mysql的时候充当SQL路由器的功能,依据⽤户事先设置的规则,将SQL请求发送到特定的数据库上执⾏。

基于此可以实现负载均衡、、⾼可⽤性等需求。

Amoeba相当于⼀个SQL请求的,⽬的是为负载均衡、读写分离、⾼可⽤性提供机制,⽽不是完全实现它们。

MySQL数据库集群方案的选择与实施

MySQL数据库集群方案的选择与实施

MySQL数据库集群方案的选择与实施MySQL数据库是一种常用的关系型数据库管理系统,它广泛应用于各种规模的企业和个人项目中。

随着数据量的不断增长和访问量的提升,单一的MySQL数据库往往无法满足需求,因此需要采用数据库集群方案来解决这一问题。

本文将讨论MySQL数据库集群方案的选择与实施,并探讨各种方案的优缺点。

1. 引言随着互联网的迅猛发展,大量的数据被存储在数据库中。

为了确保高可用性和扩展性,数据库集群方案应运而生。

本文将围绕MySQL数据库集群方案展开讨论。

2. 数据库集群概述数据库集群是由多台服务器组成的,每台服务器上运行相同的数据库实例,并通过网络相互连接。

数据库集群提供高可用性、负载均衡和数据冗余等功能。

3. MySQL数据库集群方案的选择3.1 主从复制主从复制是最简单的MySQL数据库集群方案之一。

其中一个服务器作为主服务器,负责处理读写请求,而其他服务器作为从服务器,将主服务器上的数据复制到自己的数据库中。

3.2 主备复制主备复制是一种更高级的MySQL数据库集群方案。

它与主从复制类似,但在从服务器上还可以执行读操作。

当主服务器不可用时,从服务器会接管工作,确保数据库的连续可用性。

3.3 MySQL集群管理工具MySQL提供了一些集群管理工具,如MySQL Cluster和MySQL Fabric。

MySQL Cluster是一种基于共享存储的集群方案,它提供高可用性和数据分区等功能。

而MySQL Fabric是一个框架,用于管理和监控MySQL服务器集群。

使用这些工具可以更方便地实施MySQL数据库集群方案。

4. MySQL数据库集群方案的实施4.1 硬件需求在实施MySQL数据库集群方案之前,需要确保硬件资源满足需求。

服务器的配置应根据数据库的大小和访问量进行调整,以确保良好的性能。

4.2 软件需求除了硬件需求外,还需要选择合适的软件来实施MySQL数据库集群方案。

这包括MySQL的版本、操作系统、集群管理工具等。

多图文,详细介绍mysql各个集群方案

多图文,详细介绍mysql各个集群方案

多图⽂,详细介绍mysql各个集群⽅案多图⽂,详细介绍mysql各个集群⽅案集群的好处⾼可⽤性:故障检测及迁移,多节点备份。

可伸缩性:新增数据库节点便利,⽅便扩容。

负载均衡:切换某服务访问某节点,分摊单个节点的数据库压⼒。

集群要考虑的风险⽹络分裂:群集还可能由于⽹络故障⽽拆分为多个部分,每部分内的节点相互连接,但各部分之间的节点失去连接。

脑裂:导致数据库节点彼此独⽴运⾏的集群故障称为“脑裂”。

这种情况可能导致数据不⼀致,并且⽆法修复,例如当两个数据库节点独⽴更新同⼀表上的同⼀⾏时。

@⽬录⼀,mysql原⼚出品1,MySQL Replicationmysql复制(MySQL Replication),是mysql⾃带的功能。

原理简介:主从复制是通过重放binlog实现主库数据的异步复制。

即当主库执⾏了⼀条sql命令,那么在从库同样的执⾏⼀遍,从⽽达到主从复制的效果。

在这个过程中,master对数据的写操作记⼊⼆进制⽇志⽂件中(binlog),⽣成⼀个 log dump 线程,⽤来给从库的 i/o线程传binlog。

⽽从库的i/o线程去请求主库的binlog,并将得到的binlog⽇志写到中继⽇志(relaylog)中,从库的sql线程,会读取relaylog⽂件中的⽇志,并解析成具体操作,通过主从的操作⼀致,⽽达到最终数据⼀致。

MySQL Replication⼀主多从的结构,主要⽬的是实现数据的多点备份(没有故障⾃动转移和负载均衡)。

相⽐于单个的mysql,⼀主多从下的优势如下:如果让后台读操作连接从数据库,让写操作连接主数据库,能起到读写分离的作⽤,这个时候多个从数据库可以做负载均衡。

可以在某个从数据库中暂时中断复制进程,来备份数据,从⽽不影响主数据的对外服务(如果在master上执⾏backup,需要让master 处于readonly状态,这也意味这所有的write请求需要阻塞)。

就各个集群⽅案来说,其优势为:主从复制是mysql⾃带的,⽆需借助第三⽅。

MYSQL集群解决方案

MYSQL集群解决方案

MYSQL集群解决方案--高可用性、负载均衡一、mysql的市场占有率二、mysql为什么受到如此的欢迎三、mysql数据库系统的优缺点四、网络服务器的需求五、什么是mysql的集群六、什么是负载均衡七、mysql集群部署和实现方法八、负载均衡的配置和测试九、Mysql集群系统的测试(测试方案+测试脚本+测试结果分析)●∙mysql的市场占有率MySQL是世界上最流行的开源数据库,已有1100多万的击活安装,每天超过五万的下载。

MySQL为全球开发者、DBA和IT管理者在可靠性、性能、易用性方面提供了选择。

第三方市场调查机构Evans Data Corporation调查显示,过去两年内在开发者使用的所有数据库中,MySQL已经拥有了25%的市场占有率。

开源已经成为当今IT结构中不可或缺的重要部分,而且开源的市场占有率将继续增加。

如下图所示:●∙mysql为什么受到如此的欢迎随着Internet的飞速发展和对我们生活的深入影响,越来越多的个人在互联网上购物、娱乐、休闲、与人沟通、获取信息;越来越多的企业把他们与顾客和业务伙伴之间的联络搬到互联网上,通过网络来完成交易,建立与客户之间的联系。

互联网的用户数和网络流量正以几何级数增长,这对网络服务的可伸缩性提出很高的要求。

例如,比较热门的Web站点会因为被访问次数急剧增长而不能及时处理用户的请求,导致用户进行长时间的等待,大大降低了服务质量。

另外,随着电子商务等关键性应用在网上运行,任何例外的服务中断都将造成不可估量的损失,服务的高可用性也越来越重要。

所以,对用硬件和软件方法实现高可伸缩、高可用网络服务的需求不断增长,这种需求可以归结以下几点:1) 可伸缩性(Scalability),当服务的负载增长时,系统能被扩展来满足需求,且不降低服务质量。

2) 高可用性(Availability),尽管部分硬件和软件会发生故障,整个系统的服务必须是每天24小时每星期7天可用的。

组建MySQL集群的几种方案,优劣与讨论

组建MySQL集群的几种方案,优劣与讨论

组建MySQL集群的几种方案LVS+Keepalived+MySQL(有脑裂问题?但似乎很多人推荐这个)DRBD+Heartbeat+MySQL(有一台机器空余?Heartbeat切换时间较长?有脑裂问题?)MySQL Proxy(不够成熟与稳定?使用了Lua?是不是用了他做分表则可以不用更改客户端逻辑?)MySQL Cluster (社区版不支持INNODB引擎?商用案例不足?稳定性欠佳?或者还有其他问题?又或者听说现在发展不错?)MySQL + MHA (如果配上异步复制,似乎是不错的选择,又和问题?)MySQL + MMM (似乎反映有很多问题,未实践过,谁能给个说法)淘宝的Cola(似乎现在停止开发了?)?变形虫Amoeba(事务支持?)或者,其他方案?回答1:不管哪种方案都是有其场景限制或说规模限制,以及优缺点的。

1. 首先反对大家做读写分离,关于这方面的原因解释太多次数(增加技术复杂度、可能导致读到落后的数据等),只说一点:99.8%的业务场景没有必要做读写分离,只要做好数据库设计优化和配置合适正确的主机即可。

2.Keepalived+MySQL --确实有脑裂的问题,还无法做到准确判断mysqld是否HANG 的情况;3.DRBD+Heartbeat+MySQL --同样有脑裂的问题,还无法做到准确判断mysqld是否HANG的情况,且DRDB是不需要的,增加反而会出问题;3.MySQL Proxy -- 不错的项目,可惜官方半途夭折了,不建议用,无法高可用,是一个写分离;4.MySQL Cluster -- 社区版本不支持NDB是错误的言论,商用案例确实不多,主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高;5.MySQL + MHA -- 可以解决脑裂的问题,需要的IP多,小集群是可以的,但是管理大的就麻烦,其次MySQL + MMM 的话且坑很多,有MHA就没必要采用MMM建议:1.若是双主复制的模式,不用做数据拆分,那么就可以选择MHA或Keepalive 或heartbeat2.若是双主复制,还做了数据的拆分,则可以考虑采用Cobar;3.若是双主复制+Slave,还做了数据的拆分,需要读写分类,可以考虑Amoeba;上述所有的内容都要依据公司内部的业务场景、数据量、访问量、并发量、高可用的要求、DBA人群的数量等综合权衡这是我在知乎上的一个问题,就一人回答了下,搬上CU来讨论讨论,本人之前开发人员,对MySQL不太熟,现国内『某省运营商』希望出个分布式MySQL的方案,就方案的那种,结果摊到小弟头上,望大神指点迷津。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

组建MySQL集群的几种方案
LVS+Keepalived+MySQL(有脑裂问题?但似乎很多人推荐这个)
DRBD+Heartbeat+MySQL(有一台机器空余?Heartbeat切换时间较长?有脑裂问题?)
MySQL Proxy(不够成熟与稳定?使用了Lua?是不是用了他做分表则可以不用更改客户端逻辑?)
MySQL Cluster (社区版不支持INNODB引擎?商用案例不足?稳定性欠佳?或者还有其他问题?又或者听说现在发展不错?)
MySQL + MHA (如果配上异步复制,似乎是不错的选择,又和问题?)
MySQL + MMM (似乎反映有很多问题,未实践过,谁能给个说法)
淘宝的Cola(似乎现在停止开发了?)?变形虫Amoeba(事务支持?)
或者,其他方案?
回答1:
不管哪种方案都是有其场景限制或说规模限制,以及优缺点的。

1. 首先反对大家做读写分离,关于这方面的原因解释太多次数(增加技术复杂度、可能导致读到落后的数据等),只说一点:99.8%的业务场景没有必要做读写分离,只要做好数据库设计优化和配置合适正确的主机即可。

2.Keepalived+MySQL --确实有脑裂的问题,还无法做到准确判断mysqld是否HANG 的情况;
3.DRBD+Heartbeat+MySQL --同样有脑裂的问题,还无法做到准确判断mysqld是否HANG的情况,且DRDB是不需要的,增加反而会出问题;
3.MySQL Proxy -- 不错的项目,可惜官方半途夭折了,不建议用,无法高可用,是一个写分离;
4.MySQL Cluster -- 社区版本不支持NDB是错误的言论,商用案例确实不多,主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高;
5.MySQL + MHA -- 可以解决脑裂的问题,需要的IP多,小集群是可以的,但是管理大的就麻烦,其次MySQL + MMM 的话且坑很多,有MHA就没必要采用MMM
建议:
1.若是双主复制的模式,不用做数据拆分,那么就可以选择MHA或Keepalive 或heartbeat
2.若是双主复制,还做了数据的拆分,则可以考虑采用Cobar;
3.若是双主复制+Slave,还做了数据的拆分,需要读写分类,可以考虑Amoeba;
上述所有的内容都要依据公司内部的业务场景、数据量、访问量、并发量、高可用的要求、DBA人群的数量等综合权衡
这是我在知乎上的一个问题,就一人回答了下,搬上CU来讨论讨论,本人之前开发人员,对MySQL不太熟,现国内『某省运营商』希望出个分布式MySQL的方案,就方案的那种,结果摊到小弟头上,望大神指点迷津。

相关文档
最新文档