共计 4680 个字符，预计需要花费 12 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“mysql fabric 的概念是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“mysql fabric 的概念是什么”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
MySQL Fabric 是一个用于管理 MySQL 服务器群的可扩展框架，是 GPL 的开源软件；也就是说在符合 GPL 的规范下，用户可以自由的使用和修改这个软件。mysql fabric 是处理任何管理请求的进程；使用 HA 特性时可以让此进程负责监视主服务器并在发生故障时，开始故障转移，将从服务器升级成主服务器。
MySQL Fabric 简介
MySQL Fabric 是一个用于管理 MySQL 服务器群的可扩展框架。
MySQL Fabric 能“组织”多个 MySQL 数据库，是应用系统将大于几 TB 的表分散到多个数据库，即数据分片(Data Shard)。在同一个分片内又可以含有多个数据库，并且由 Fabric 自动挑选一个适合的作为主数据库，其他的数据库配置成从数据库，来做主从复制。在主数据库挂掉时，从各个从数据库中挑选一个提升为主数据库。之后，其他的从数据库转向新的主数据库复制新的数据。注意：这里说的“自动”是指由 MySQL Fabric 在后台完成，而不需要用户手动更改配置。最重要的是，MySQL Fabric 是 GPL 的开源软件，也就是在符合 GPL 的规范下，你可以自由的使用和修改这个软件。
Fabric 框架实现了两个特性：高可用性 (high availablity) 和使用数据分片的横向扩展(sharding)，这两个特性既可以单独使用，也可以结合使用。
这两个特性都基于以下两个层面实现：
mysql fabric 是处理任何管理请求的进程。使用 HA 特性时，还可以让此进程负责监视主服务器并在发生故障时, 开始故障转移，将从服务器升级成主服务器。MySQL Fabric-aware 连接器把从 MySQL Fabric 获取的路由信息存储到缓存中，然后凭借该信息将事务或查询发送给正确的 MySQL 服务器。
高可用性
HA 组由两个或更多个 MySQL 服务器组成；任何时刻，其中都有一台服务器作为主服务器(MySQL 复制功能的主服务器)，其他服务器则作为从服务器(MySQL 复制功能的从服务器)。HA 组的作用就是确保该组中保存的数据始终可访问。MySQL 的复制功能可通过复制来确保数据安全，MySQL Fabric 的高可用性解决方案在此基础上提供了两个必不可少的额外要素：
故障检测和升级 — MySQL Fabric 监视 HA 组中的主服务器，在主服务器发生故障时选择一个从服务器并将其升级为主服务器数据库请求路由 — 将写入请求路由到主服务器以及将读取请求在各个从服务器之间进行负载均衡的操作对应用是透明的，即使在故障转移期间拓扑发生变化时也是如此
分片 — 横向扩展
当接近一个 MySQL 服务器 (或 HA 组) 的容量或写入性能极限时，MySQL Fabric 可在多个 MySQL 服务器“组”中对数据进行分区，从而支持数据库服务器横向扩展。请注意，一个组可以只包含一个 MySQL 服务器，也可以是一个 HA 组。管理员定义这些服务器之间的数据分片方式；指定应将哪些表的列用作分片键，以及是使用 HASH 映射还是 RANGE 映射将这些键映射至正确的分片, 如果需要进一步分片，MySQL Fabric 可以拆分现有分片；此外，还可以重新分配分片。
MySQL Fabric 要解决的问题
为什么做数据分片？当你的应用需要处理的表大于 1TB 的数据时，Data Shard 常常是 必须的。这么大的表，无论在查询、更新的效率上，或者是备份、更改结构所需要的 时间上，都会造 成 很大的问题。然而当你将这么大的表分散到多个数据库服务器上，又会使每一台数据库服 务器都有可能是单个故障点。只要 有一台挂掉就会使整个系统 的操作发生问题。另一方面，应用端的程序也会因为每个查询都要依其查询条件 (where 子句的内容)分别指向不同的数据库 而变得更加复杂。再者，当数据分片的 结构 改变时(例如增加一个数据库)，会使应用端的所有 程序都必须修改，从而导致 维护变得极为复杂。
为了解决应用程序复杂度增加的问题，有人在应用程序和数据库服务器之间增加 一个代理 (proxy)或者成为 switch，应用程序所有对数据库的指令先送到 proxy，再由 proxy 判断要转到 哪个数据库。下图就是这个方案的示意图。这也许可以解决应用程 序难以维护的问题，但是 当应用端的数量增加，数据库分片增加，或者系统压力增 加时，这个 switch 会成为容量及性 能的瓶颈和单点故障(当它宕掉时，应用端找不到 数据库)，而且所有的数据库指令均需要传 两次(先到 switch 再到数据库)。每个查询都会造成额外的负荷。
MySQL Fabric 的架构
MySQL Fabric 采用不用的做法，其架构如下图所示。主要的特点是把 switch 合并到各应用端的 connector 中，以解决单一 switch 的单点故障和性能瓶颈。
MySQL Fabric 由三个部分构成：
1.MySQL Fabric 管理节点：
是一个 python 脚本，是整个架构的核心。
MySQL Fabric 管理节点主要的功能是管理整个数据库服务器场(Database Server Farm), 它启动时会找 /etc/mysql/fabric.cnf 这个配置文件，由它指定 fabric 背后当成存放 Server Farm 架构和配置之 repository 的 MySQL 数据库位置、端口和连接账号等信息。
Fabric 在初始化时(执行 mysqlfabric manage setup 命令)，会在 MySQL 数据库上开一个 schema(通常是名称为 fabric 的 database)，存放 Server Farm 的配置相关信息，如哪些服务器组由哪些数据库构成，各服务器组中的主从服务器分别是哪些，等等。
MySQL Fabric 节点在设置配置时，会对 Server Farm 中各数据库下达建立主从复制的命令(上图的红色线条)。
在正常运行时定期 ping 各组的主服务器，当发现主数据库没有正常运行时，它会启动故障转移程序，在该 server farm 的从数据库中找一个合适的提升为主服务器。其他的从数据库则转向新的主数据库继续复制数据。
2. 数据库服务器场(database server farm)
这是整个架构中的工作引擎，在传统的数据库应用中这是单一的 MySQL 数据库，MySQL Fabric 则是以多个数据库支持大数据量表 (TB 级以上) 和高可用性数据库的需求。这些数据库分成几个高可用组 (HA Group)，每个组包含一个以上的数据库服务器，上图中最下面的几个灰色和浅蓝色的方块代表高可用组。如果高可用组中有多个数据库，MySQL Fabric 会挑选(使用命令 mysqlfabric group promote 命令) 一个提升为主数据库(Master)，其他数据库则成为从数据库(Slave)，从数据库复制主数据库的变化，完成设定同一高可用组内的主从复制。以后，Fabric 会定期件事这个主数据库。当主数据宕掉之后，Fabric 会从高可用组内挑选一个提升为主数据库，其他的数据库会转向这个新的主数据库继续复制。
另一方面，MySQL Fabric 也会只是应用端的 conector 对这些主从数据库做读写分离，当应用程序对数据库做读写兼有的操作时，connector 会将该指令提交给主数据库。如果应用程序只会对数据库进行读操作，且连线的 read_only 参数设置为“ON”，则所有的查询均轮流传送到这几个数据库。借助读写分离，应用系统的资料处理能力得以增加。此外，如前面所述，MySQL Fabric 还能处理需要拆分到多个数据库服务器的表(sharding tables)，每一个高可用组都可能存放 shard table 的部分数据。应用端的 connector 会将对 shard table 的指令依 MySQL Fabric 的管理节点的设定送到不同的高可用组，这样可使数据库的容量随着高可用组的数量增加而增长。同时，对非拆分的表所下的指令和所有的 DDL 会由 connector 送到全局高可用组(global group)，全局高可用组的主数据库被 MySQL Fabric 设置为其他高可用组的主数据库。所有存拆分表的高可用组的主数据库复制 global group 的变化，这么一来其他高可用组都有一份非拆分表的资料。从而使得 SQL 中拆分表对非拆分表的 JOIN 操作变得更简单。
3. Connector
应用系统在运行时，每个 SQL 指令都会经由 connector 发送到数据库。MySQL Fabric 所搭配的 connector 和一般使用单机的 MySQL 数据库一样，只是在较新版的 connector 是 fabric aware connector 多了一些能处理数据库服务器场 (database server farm) 的功能。使他们能在建立数据库连接时，以 XML-RPC 协议检查 MySQL Fabric 的管理节点中 server farm 的配置，然后通过该连接下的查询可依 fabric 的指示送到适合的数据库。
如此一来，常见的 database shard 方案中可能造成性能瓶颈的 proxy 放到 connector 中，从而解决了这个问题。目前 MySQL Fabric 支持的技术有 java、python、PHP，即 Connector/J、Connector/Python 和 Connector/PHP 都是 Fabric-aware。
以 java 为例，JDBC driver 必须是 Connector/J 5.1.30 以后的版本，Fabric 的 Java 程序和一般对单机 MySQL 的查询的 Java 程序差不多，只是在建立 database connection object 时 database connection URL 不是指向数据库，改为指向 MySQL Fabric 管理节点(服务器的 IP 和端口通常是 32274)。
当查询的表时全局表 (不做 table shard) 或 DDL(例如建表或改表结构)时，建立 connection object 的要加上 fabricServerGroup= 参数，之后通过这个 connection object 所下的 SQL 指令会送到 Global Group 的主数据库，再由数据库复制到其他的高可用组 (shard) 中。
如果 SQL 命令所要操作的表时分区表 (shard table)，则建立 connection object 时要在参数加上 fabricShardTable= 参数，之后通过这个 connection object 所下的 SQL 命令会根据 MySQL Fabric 所设定的分表(shard) 原则送到各分区 (shard) 的高可用组。
这样一来，应用程序对这些 shard table 下的 SQL 指令时，不需要在 SQL 中判断要送到哪个数据库，完全由 connector 在建立数据库连接时向 MySQL Fabric 所查到的 server farm 的配置信息 (哪个数据库属于哪个 shard group，各 shard table 的拆分原则等) 所决定。而且这个配置在建立主连接后就缓存在 Connector 所在的应用端。
这样，在每次下 SQL 指令时就不需要重复查询 MySQL Fabric 管理节点，而依存于应用端的分表配置直接送到正确的数据库。而应用程序的效率不会因为做了表的拆分而有任何降低。
读到这里，这篇“mysql fabric 的概念是什么”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
