mysql分布式（分布式系统为什么要选mysql数据库）

本文目录

• 分布式系统为什么要选mysql数据库
• Mysql分布式 Dual Master具体是
• Mysql变成分布式数据库
• mysql分布式集群的搭建方案
• 现在mysql的分布式数据访问层主流方案有哪些
• 单机MySQL数据库怎么做成分布式数据库集群
• MySQL大型分布式集群具体怎么做

分布式系统为什么要选mysql数据库

分布式系统看它是否支持事务，如果用在统计分析场景中，不需要支持事务，这时候分布式的各个节点，选择列存储更好，选择mysql是一种错误，它不适合分析型场景。如果是事务场景，并发数和数据量都极大，需要分布式场景， 将数据按照一定的规则分布在不同的服务器（节点）上，每个节点采用某类型的行存数据库， 如果要满足需求的行存数据库需要有以下特点1、支持事务；2、支持高并发的能力；3、在与分布式中间件通讯时，能够为了适配业务的需求，可以做些定制开发；4、数据量增大，进行拓展的时候，数据操作方便；5、核心组件升级容易；6、维护容易；综上所述，目前可选的 是mysql为最优。

Mysql分布式 Dual Master具体是

所谓的Dual Master，实际上就是两台MySQL服务器互相将对方作为自己的 Master，自己作为对方的Slave，这样任何一台服务器上的数据变更，都会通过MySQL 的复制机制同步到另一台服务器。当然，有的读者可能会担心，这样不会导致两台互为Master 的 MySQL之间循环复制吗?当然不会,这是由于MySQL在记录Binary log日志时,记录了当前的server-id, server-id在我们配置MySQL复制时就已经设置好了。一旦有了server-id，MySQL就很容易判断最初的写入是在哪台服务器上发生的，MySQL不会将复制所产生的变更记录到Binary log，这样就避免了服务器间数据的循环复制。当然，我们搭建Dual-Master 架构，并不是为了让两个 Master 能够同时提供写入服务，这样会导致很多问题。举例来说，假如Master A 与Master B几乎同时对一条数据进行了更新，对Master A的更新比对Master B的更新早，当对Master A的更新最终被同步到Master B时，老版本的数据将会把版本更新的数据覆盖，并且不会抛出任何异常，从而导致数据不一致的现象发生。在通常情况下，我们仅开启一台Master的写入，另一台Master仅仅 stand by或者作为读库开放，这样可以避免数据写入的冲突，防止数据不一致的情况发生。在正常情况下，如需进行停机维护，可按如下步骤执行Master的切换操作:1）停止当前Master 的所有写入操作。2）在 Master 上执行set global read_only=1，同时更新MySQL 配置文件中相应的配置，避免重启时失效。3）在 Master上执行show Master status，以记录 Binary log 坐标。4)使用Master上的Binary log坐标,在stand by的 Master上执行select Master_pos_wait(),等待stand by Master的 Binary log跟上 Master的 Binary log。5）在stand by Master 开启写入时，设置read_only=O。6）修改应用程序的配置，使其写入到新的Master。

Mysql变成分布式数据库

　1、amoeba相当于一个SQL请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。用户需要结合使用MySQL的Replication等机制来实现副本同步等功能。amoeba对底层数据库连接管理和路由实现也采用了可插拨的机制，第三方可以开发更高级的策略类来替代作者的实现。这个程序总体上比较符合KISS的思想。　　2、由上一条，建议使用MySQL的Replication机制建立Master-Slave来做副本。我一开始理解有误，使用了amoeba的virtual DB（负载均衡pool）做writePool，结果使得本应插入同一个表中的数据被拆分地写入了不同的物理数据库中。这样自然与副本的语义不符了。　　3、amoeba已经实现了数据的垂直切分与水平切分。水平切分方面，粒度是行。使用SQLJEP语句可以设计出复杂的切分规则，个人认为是比较强大的。垂直切分的粒度是表，可以把针对不同表的请求发送到不同的节点上执行，但不能以列作为分片粒度。从作者的说法看，amoeba不做SQL解析和重写。在目前的机制下似乎是难以实现同一个表不同的列在不同节点上的分布。不过对开发人员来说，设计良好的表结构应该可以实现简单的基于关系属性的负载均衡的。

mysql分布式集群的搭建方案

不是很理解，比如说你3台搭建分布式，你通过什么方式区分库表？假设每台服务器上部署一个mysql实例，那你怎么把数据分布到3个mysql里面？是每个mysql里面存不同的表么？如果这样，就还可以接受。这块问题不是很大。

第二个问题，你的HA主备，意思是说两个分布式互为主备？那怎么备份，怎么切换？

其实按照你想要达到的目标。应该是每两台互做主备，形成3对主备库，然后这3对再组建一个分布式集群。

其实和你要做的可能差不多，不过逻辑上还是有差异的。HA你准备怎么做？keepalived？

另外，咨询一下，你的分布式是通过什么来实现，不同业务访问不同的数据库，每个库存不同的表？还是相同的表分布在不同数据库？

看你服务器的配置如何，其实我觉得一般来说拿3台来做备机有点浪费，如果配置允许，可以考虑做成6套mysql主备的分布式集群。

通过交叉互备实现硬件的最大利用。下图是我们之前用4台服务器做的一套集群方案。

如果还有其他问题可以和我联系。

现在mysql的分布式数据访问层主流方案有哪些

（1）方案一（数据库保存所有服务器索引信息） 全对称结构，没有中央服务器 web方案： 只从本地数据库检索符合条件的记录，给出结果 每次检索都要从本地服务器的海量数据中进行 数据库方案： 数据库保存所有服务器的索引内容 缓存命中率高的记录，减少检索时间 服务器负载分析： 服务器负载假设： 一百个结点，每结点一百人同时使用，每个结点一万条记录 web服务器：同时一百线程在本地数据库服务器检索 数据库服务器：每次接收一百个查询请求；每个请求要从一百万条索引中检索（最坏的情况）；缓冲机制可以稍微减轻负担 数据更新操作： 同时更新所有数据库/只更新本地，服务器间相互同步 方案二（数据库保存本地索引及少量缓冲） 每高校作为一个结点 所有结点全对称结构，网络中没有一个中央服务器 web方案： 接收到请求时同时多线程向其它服务器同时搜索（服务器压力问题？） 数据库方案： 数据库保存本地数据 数据库保存一定量缓冲数据， 服务器负载分析： 服务器负载假设： 一百个结点，每结点一百人同时使用 则每个web服务器同时发起一万个线程向其它数据服务器搜索（oops!） 每个数据库服务器会同时接收到一万个查询请求（oops！） 采用学习过程只能少量减少查询请求和web服务器搜索线程 数据更新操作： 只更新本地 方案三（中央服务器方案一） 每高校一个结点 每结点结构相同，连接到同一个中央服务器 web方案 每个查询向中央服务器进行，由中央服务器实行检索，中央服务器返回检索结果 数据库方案 中央数据库保存所有索引信息 每结点可以只用小型数据库保存本地用户和其它信息即可 服务器负载分析： 服务器负载假设： 一百个结点，每结点一百人同时使用，每结点资料记录一万条 web服务器：同时发起一百个进程向中央数据库查询 数据库服务器（中央）：同时接收一万条查询请求并返回大容量结果 数据库服务器（结点）：少量工作 数据更新操作： 只更新中央服务器 方案四（中央服务器方案二） 每高校一个结点 每结点结构相同，连接到同一中央服务器 web方案： 每个查询向中央服务器进行，由中央服务器根据查询内容进行转发到结点数据库，再由结点数据库返回结果 数据库方案： 中央服务器保存各结点分类信息，根据页面请求的分类转发查询到相应服务器 服务器负载分析： 服务器负载假设： 一百个结点，每结点一百人同时使用，每结点资料记录一万条，每结点一百个类别 web服务器：同时一百个进程向中央数据库查询 数据库服务器（中央）：同时接收一万条请求并转发 数据库服务器（结点）：从中央服务器接收查询请求，最坏情况下每结点接收到一万条查询请求 数据更新操作： 只更新本地服务器 分类变化时更新中央服务器

单机MySQL数据库怎么做成分布式数据库集群

可以采用开源的MyCat解决方案，优点是免费，缺点是出现问题可能要自己解决或者去社区寻找解决方案；也可以采用北京万里开源软件有限公司的集群解决方案，后端使用开源的MySQL存储数据，优点是有任何问题他们都可以帮忙解决，而且不用担心系统后续的扩展、集群高可用等情况，他们的工程师还开发过MySQL核心代码，找他们可以睡个安稳觉，缺点是不免费，他们还有自己的国产数据库GreatDB，100%兼容MySQL。对于初创企业，可以考虑选择免费的开源解决方案，毕竟遇到的问题可能有限，如果要想长期稳定发展，还是选择万里开源这样的公司比较靠谱一些。

MySQL大型分布式集群具体怎么做

1、主要解决针对大型网站架构中持久化部分中，大量数据存储以及高并发访问所带来是数据读写问题。分布式是将一个业务拆分为多个子业务，部署在不同的服务器上。集群是同一个业务，部署在多个服务器上。2、着重对数据切分做了细致丰富的讲解，从数据切分的原理出发，一步一步深入理解数据的切分，通过深入理解各种切分策略来设计和优化我们的系统。这部分中我们还用到了数据库中间件和客户端组件来进行数据的切分，让广大网友能够对数据的切分从理论到实战都会有一个质的飞跃。通过分布式+集群的方式来提高io的吞吐量，以及数据库的主从复制，主主复制，负载均衡，高可用，分库分表以及数据库中间件的使用。