MySQL 集群评估指南 充分利用您的 MySQL 集群评估指南


版权 © 2012,Oracle 和/或其附属公司,版权所有。 MySQL 集群评估指南 充分利用您的 MySQL 集群评估指南 MySQL® 技术白皮书 2012 年 2 月 版权 © 2012,Oracle 和/或其附属公司,版权所有。 2 目录 1 引言 3 2 何为 MySQL 集群? 3 2.1 MySQL 集群体系结构 3 3 MySQL 集群 7.2 主要功能 5 4 评估前的考虑因素 5 4.1 MySQL 集群“开盒即用”运行应用程序的速度比现有的MySQL 数据库更快么? 5 4.2 如何安装 MySQL 集群? 6 4.3 该数据库需要特殊操作系统支持么? 6 4.4 整个数据库都能放入内存么? 6 4.5 该应用程序使用复杂 JOIN 操作么? 7 4.6 应用程序使用全表扫描? 7 4.7 数据库需要外键么? 7 4.8 应用程序需要全文本搜索么? 8 4.9 与其他存储引擎相比,MySQL 集群如何工作? 8 4.10 MySQL 集群的数据分布增加了应用程序复杂度,而且限制了运行的查询类型,是这样吗? 9 5 评估最佳措施 9 5.1 硬件 9 5.2 性能度量 11 5.3 测试工具 12 5.4 SQL和NoSQL 接口 12 5.5 数据模型和查询设计 13 5.6 使用磁盘数据表或内存表 14 5.7 用户自定义分区和分配条件 15 5.8 并行化应用程序和其他提示 15 6 配置文件的相关建议 16 7 完整性检查 17 7.1 确定可以检测集群的部分基本测试 17 8 故障解决 18 8.1 表满(内存或磁盘空间) 18 8.2 重做(REDO)日志所用空间不足 19 8.3 死锁超时 19 8.4 部分变化 19 9 结论 20 10 其他资源 20 甲骨文(中国)软件系统有限公司联系 21 版权 © 2012,Oracle 和/或其附属公司,版权所有。 3 1 引言 本指南旨在帮助您有效地评估 MySQL 集群数据库并确定应用程序选项(作为新项目中的一部分或对现有服 务进行升级)是否正确。 本指南概述了 MySQL 集群数据库及在最新 7.2 GA(一般可用性)正式版本中的新增功能,接着讨论了下列 内容: ⁃ 开始评估前需考虑的问题; ⁃ 最佳评估措施; ⁃ 配置选项和正常性检查; ⁃ 故障解决。 根据本手册中的建议,您可以快速有效地评估 MySQL 集群,缩短新服务上线的时间。 2 何为 MySQL 集群? MySQL 集群是具有写可扩展性、实时性、符合 ACID 标准的事务数据库,可用性高达 99.999%,开源,总体 拥有成本(TCO)低。 采用无单点故障的分布式多主机构架,MySQL 集群可以在商业硬件上水平扩展,并 能自动分片解决繁多的读写操作,可以通过 SQL 和 NoSQL 接口访问。 MySQL 集群实时设计提供了可预测服务,具有毫秒级的响应性能,每秒可为数百万次的操作提供服务。 支 持内存和基于磁盘的数据、数据自动分区(分片)、负载平衡、无需停机便可在运行中的集群中动态添加节 点,在处理不可预测的任务时可以对数据库进行线性扩展。 MySQL 集群集成标准 MySQL 服务器,同时配备一个集群存储引擎 NDB。MySQL 集群内的数据可以通过各 种 PHP、Java 或.NET 以及标准 SQL 等连接器访问。 还能使用 MySQL 集群的 native NoSQL NDB API 直接访 问和操作数据。该 C++ 接口为存储在 MySQL 集群上的数据提供快速的底层连接。 通过 NDB API 访问集群可使用其他 NoSQL 接口。Java 应用程序使用 Java 专用 MySQL 集群连接器可简单高 效的访问数据。Java 专用 MySQL 集群连接器提供两个对象-关系型映射持续解决方案 —— 属于 OpenJPA 插 件的 Cluster J 或 Cluster JPA —— 两种框架直接使用 NDB API,并不使用 JDBC 和 MySQL 服务器。 Cluster J 和 JPA 直接将 Java 对象映射到 MySQL 集群数据库的关系表中。 进来发布的一种 Memcached 插件能够使 Memcached 客户端通过标准 Memcached 协议直接访问表。 2.1 MySQL 集群体系结构 从体系结构上看,MySQL 集群由三类不同节点组成,每种具有特定用途,通过搭配可以为读写操作提供实 时性、线性可扩展性和 99.999%的 可用性。 图 1 为含有四个数据节点的 MySQL 集群简化体系结构,其中四个数据节点分布在两个节点组中。 版权 © 2012,Oracle 和/或其附属公司,版权所有。 4 图1 四个数据节点的 MySQL 集群 数据节点为 MySQL 集群的主要节点。 数据节点具有下列功能:  存储和管理内存中数据和磁盘数据  表可分区(分片),用户可对其进行定义  在数据节点上同步复制数据  事务和数据检索  自动的故障转移  故障后自动重新同步,具有自愈功能 对表进行自动分片并将分片结果分布到各数据节点上,每个数据节点为可以接受写操作的主节点,这样在各 商业节点遇到写任务繁重的情况时可以快捷扩展,这种方式具有高度的应用程序透明度。 在无共享体系结构下(如使用磁盘共享机制)存储和分配数据,并将数据同步复制到至少一个副本中,如某 个数据节点发生故障,总会有其他数据节点上存储有相同的信息。 这种操作可使请求和事务不会发生中断。 数据节点发生故障后,可对处于故障转移窗口期(次秒级)的事务进行回滚,然后重新恢复运行。 可以选择存储数据的方式;既可以全部放入内存,也可以部分放到磁盘上(仅限非索引数据)。 内存存储适 用于频繁变更(当前工作集)的数据。 设置数据点并定期将存储在内存中的数据备份到本地磁盘上并在各节点间进行协调,确保在发生停电等系统 故障时可以恢复 MySQL 集群。 可使用磁盘存储要求不很严格的数据,这类数据集比可用内存大。 针对多数其他的数据库服务器,为提高性 能,采用页面缓存技术将数据节点内存中频繁使用的磁盘数据放入缓存中。 版权 © 2012,Oracle 和/或其附属公司,版权所有。 5 应用程序节点提供从应用程序逻辑到数据节点的连接。 应用程序可以通过一台或多台可以连接 MySQL 集群 中存储数据的 MySQL 服务器并访问使用 SQL 的数据库 ,访问 MySQL 服务器时,可使用能够提供多种访问 技术的任何标准的 MySQL 连接器1。 此外,高性能 NDB API 接口(基于 C++)可用于提升控制、改善实时行为、增加吞吐量。 如上所述,NDB API 提供可供其他 NoSQL 接口直接访问集群的层,从而可以绕过 SQL 层,降低延时并提高 了开发的灵活性。 所有应用程序节点可以从所有数据节点上访问数据,因此即使遇到故障也不会导致服务终止,因为应用程序 可以使用其他正常节点。 管理节点负责将集群配置发送到集群中的所有节点,以便进行节点管理。 节点需加入集群以及系统需要重新 配置的时候,管理节点才启用。 管理节点的停用和重启不会影响正在使用的数据和应用程序节点。 默认情 况下,管理节点还提供属性服务,当出现网络故障发生“裂脑”或集群出现“网络分区”2。 通过下列指南中了解 MySQL 集群体系结构如何实现高度可用的快速扩展、嵌入式服务及电信服务: http://mysql.com/why-mysql/white-papers/mysql_wp_scaling_web_databases.php 3 MySQL 集群 7.2 主要功能 MySQL 集群 7.2 版本以 7.0 和 7.1 版本为基础,加入多种新的功能,可以支持下一代 web 和通信服务,提高 了跨数据中心的扩展能力,同时简化了操作: 支持下一代服务:复杂查询的性能提高 70 倍、自适应查询本地化、数据节点扩展能力提高 4 倍、采用 native memcached API 并集成最新 native memcached API 服务器端。 提高跨数据中心的扩展性:新式多站点集群提高跨地域双工复制能力。 简化应用:提升了用户特权。 关于这些新功能的详情,请参考下列白皮书: http://mysql.com/why-mysql/white-papers/mysql_wp cluser7_architecture.php 4 评估前的考虑因素 4.1 MySQL 集群“开盒即用”运行应用程序的速度比现有的MySQL 数据库更快么? 实际情况是,应用程序和数据库一般都会有优化。 根据《MySQL 集群数据库性能优化指南》中的指南进行 操作可明显提高性能,当您扩展写操作时,依然可以保持很高水平的可用性和很低的延迟。 您可以从下列 页面下载性能优化指南: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php 1 http://www.mysql.com/downloads/connector/ 2http://www.clusterdb.com/mysql-cluster/mysql-cluster-fault-tolerance-impact-of-deployment-decisions/ 版权 © 2012,Oracle 和/或其附属公司,版权所有。 6 4.2 如何安装 MySQL 集群? 浏览快速启用指南,马上着手使用和运行: http://mysql.com/products/cluster/get-started.html - quickstart Oracle 提供安装集群二进制包所用 RPM 和非 RPM 包并提供下载和编辑源代码的选项。 MySQL 参考指南 (http://dev.mysql.com/doc/refman/5.5/en/index.html)包括集群和 MySQL 服务器端组件的安装说明。 您也可以使用 MySQL 集群管理器中新的 Bootstrap 选项在单主机上自动配置和提供带有 4 个节点的集群 —— 是开发者提供证据(Proof of Concepts)的理想之选。 可以通过下列页面详细了解该选项: http://www.clusterdb.com/mysql-cluster/mysql-cluster-manager-1-1-2-creating-a-cluster-is-now-trivial/ MySQL 集群管理器是 MySQL 集群运营商级版本中的程序,从下列网址可下载并能免费试用 30 天 https://edelivery.oracle.com/ 。 4.3 该数据库需要特殊操作系统支持么? 所有 MySQL 集群节点(数据节点、MySQL 服务器节点和管理节点)必须运行 Linux、Windows 或 UNIX 操 作系统。 如想了解支持的最新平台,请查看: http://www.mysql.com/support/supportedplatforms/cluster.html 集群中使用的所有主机必须具有相同的体系结构。有节点的机器必须选择大端或小端,并且两者不可混用。 例如,您无法将 SPARC 上运行的管理节点导向至在 x86 主机上运行的数据节点。 这种限制不适用于只运行 mysql 或其他可以访问集群 SQL 节点的客户端。 可以将 32 位主机上应用程序节点与 64 位主机上数据节点混 用,反之亦然。 MySQL 客户端(使用 JDBC、.NET、PHP、Perl、Python、Ruby 等)可以运行任何操作系统并通过运行在支 持平台上的 MySQL 服务器端访问 MySQL 集群。 4.4 整个数据库都能放入内存么? MySQL 集群支持磁盘数据和内存数据。 但就目前来说磁盘的存储有某些限制。 例如,非索引数据可存放到 磁盘上,但索引列必须常驻内存。 数据库越大,需要的内存/硬件资源就可能越多。 关于磁盘数据实施的其 他信息,请参阅: http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-disk-data.html 如需了解数据库目前使用已配置内存资源的情况,可查询 ndbinfo.memoryusage 表: http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-ndbinfo-memoryusage.html 如果使用 MySQL 集群 电信运营商级版本 可以查看 MySQL 企业监控器图中关于该信息的动态情况。 在设计全新数据库时,需通过下列计算确定数据节点大致的内存需求: (内存) 数据大小 *副本 * 1.25 = 数据库内存总需求 实例:50 GB * 2 * 1.25 = 125 GB (数据大小 *副本 * 1.25)/节点数 = 每个节点的内存大小 实例:(2 GB * 2 * 1.25)/4 = 1.25 GB 版权 © 2012,Oracle 和/或其附属公司,版权所有。 7 4.5 该应用程序使用复杂 JOIN 操作么? 最新 MySQL 集群 7.2 GA 版本具有两种功能,结合使用时,相对于之前 的 MySQL 集群版本,join 操作的性 能可提高 70 倍(甚至更高)。 ⁃ 索引统计功能使 SQL 优化器能为每个查询提供更好的执行方案。 过去,非优化查询计划通过 USE INDEX 或 FORCE INDEX 手动执行索引查询、更改执行计划。 必须提前在每个表上运行 ANALYZE table,以充分利用该功能。 ⁃ 自适应查询本地化(AQL)将 join 操作分布到各数据的节点上(发送至协同作业的位置)而无需上传到 MySQL 服务器;从而提高了 join 的计算能力,大幅度减少了系统的消息传输量。 您可以从下列网页上了解详情并查看查询示范: http://www.clusterdb.com/mysql-cluster/70x-faster-joins-with-aql-in-mysql-cluster-7-2-dmr/ 某些 JOIN 操作无法分布到各数据节点上,因此无法利用 AQL,所以有必要对您的应用程序进行调整使其达 到最佳的性能。 通过全局变量- ndb_join_pushdown 控制 AQL ,在默认情况下选用该变量。 为使连接操作能够利用 AQL(即被“pushdown”到数据节点上),必须达到下列条件: 1. 待连接的列必须具备完全一致的数据类型。 (如连接INT 列和 BIGINT 列时就无法将数据pushdown到数 据节点上)。 包括任何 VARCHAR 列的长度。 2. 引用BLOB 或 TEXT列的连接无法将数据pushdown到数据节点上。 3. 不支持显式封锁;但强制执行 NDB 存储引擎特征是基于行的隐式封锁。 4. 为在连接中进行“pushdown”操作,必须使用ref、eq_ref, 或 const 访问方法z中的某一种或数种访问连接中 的子表。这些访问方法见 http://dev.mysql.com/doc/refman/5.5/en/explain-output.html。 5. 连接参考表通过 [LINEAR] HASH、LIST 或 RANGE 进行分区,目前无法被“pushdown”。 6. 如果查询规划决定在候选子表中使用连接缓冲区(Using join buffer),则该表无法pushdown。但可能是 另一pushdown表集的父表。 7. 如果pushdown连接的父表为 eq_ref 或 const,仅通过 eq_ref 连接的子表才能合并。 ( 通过ref 连接的表很 可能成为另一个pushdown连接的根) 设计模式和应用程序查询时首先需考虑这些问题 —— 如符合限制条件 4,尝试在连接中对表进行扫描,这属 于首条规则。 查询涉及到多层连接时,某些层可以被完美地 pushdown,其他层在 MySQL 服务器端上执行。 如果您的应用程序由多个这类连接操作组成,而连接操作又无法使用 AQL, InnoDB 等其他 MySQL 存储引 擎将为负载提供更好的选择。 4.6 应用程序使用全表扫描? 如使用全表扫描,除非修改应用程序,否则与针对该查询的其他 MySQL 存储引擎相比其性能将会降低。 这 取决于数据分区和在多个数据节点上分配的方式。 应用程序多数情况下(但并非独占性)执行主键操作时, 一般都能从 MySQL 集群的数据分布中获益。 4.7 数据库需要外键么? MySQL 集群存储引擎通常不支持外键。 如果使用 MySQL 服务器端访问数据,可通过触发器消除该限制。 (注意:任何使用 NDB API 的客户端不会造成限制。) 该方法的说明如下: http://dev.mysql.com/tech-resources/articles/mysql-enforcing-foreign-keys.html 版权 © 2012,Oracle 和/或其附属公司,版权所有。 8 4.8 应用程序需要全文本搜索么? 目前,MySQL 集群存储引擎不支持全文本搜索。 提供全文本搜索的常规方法即:将集群数据库复制到只读 MyISAM 从服务器,或使用带有 MySQL 集群的外部搜索引擎,如 Sphinx 或 Lucene。 注意:InnoDB 存储引擎目前具有全文本搜索预览功能。 http://blogs.innodb.com/wp/2011/07/innodb-fts-performance/ 4.9 与其他存储引擎相比,MySQL 集群如何工作? “如果仅使用内存表,在 MySQL 集群中执行插入操作耗时会更长,原因何在?” “有一张大 MyISAM 表,若将其改变为 InnoDB,迁移时间只需数秒。而 将表调整为 NDB(MySQL 集群) 时,操作时间延迟 5 倍。 我们希望速度能快点。“ “我们向 INNODB 和 MySQL 集群发出类似请求时,执行速度往往都比 InnoDB 请求快,为什么呢?“ 上述方案忽视了 MySQL 集群存储体系结构与其他 MySQL 存储引擎体系结构间的最基本差别。 MySQL 集群 采用分布式无共享数据存储,具有高度可扩展性,主要用于大量采用主键访问的应用程序,但访问 MySQL 服务器端和分布于数据节点上的表之间的数据时,会占用网络访问资源。 下图中请注意:为满足查询需求,数据检索中需涉及多个数据节点。 上文讨论的自适应查询本地化 (AQL)可将某些级别的查询分发到不同数据节点上就地处理,降低网络信息发送成本,并提高了查询性 能。 Node Group 1 Node Group 2 Query: SELECT fname, lname FROM author WHERE authid BETWEEN 1 AND 3; Result: Albert Camus Ernest Hemingway Johan Goethe GermanyGoetheJohan3 FranceCamusAlbert1 countrylnamefnameauthid (PK) GermanyGoetheJohan3 FranceCamusAlbert1 countrylnamefnameauthid (PK) JapanTanizakiJunichiro4 USAHemingwayErnest2 countrylnamefnameauthid (PK) JapanTanizakiJunichiro4 USAHemingwayErnest2 countrylnamefnameauthid (PK) 图2 数据节点上的数据访问 作为参考点,下图传统存储引擎中的行查询不产生网络通信成本,因为整个数据库表分布在相同主机上。 版权 © 2012,Oracle 和/或其附属公司,版权所有。 9 Query: SELECT fname, lname FROM author WHERE authid BETWEEN 1 AND 3; Result: Albert Camus Ernest Hemingway Johan Goethe JapanTanizakiJunichiro4 GermanyGoetheJohan3 USAHemingwayErnest2 FranceCamusAlbert1 countrylnamefnameauthid (PK) JapanTanizakiJunichiro4 GermanyGoetheJohan3 USAHemingwayErnest2 FranceCamusAlbert1 countrylnamefnameauthid (PK) 图 3 使用存储引擎数据访问 用于处理大量相对较小的事务时,MySQL 集群性能最佳,因此调整应用程序使其符合这种模式,从而可以 达到最佳效果。 4.10 MySQL 集群的数据分布增加了应用程序复杂度,而且限制了运行的查询类 型,是这样吗? 针对这两个提问,答案是否定的! 默认情况下将表自动分区(分片)并通过哈希主键分配到不同节点上。 支持其他分区方法,但多数情况下默 认值可以接受。 分片操作在数据库层自动执行和实现,应用程序开发者无需为控制数据分布而修改其应用程序 —— 从而大 大简化了扩展。 此外,应用程序可自由运行复杂查询,如在不同分片上进行连接(JOIN)操作,因此用户无需为方便扩展性 而降低其功能。 5 评估最佳措施 无论将现有数据库迁移到 MySQL 集群中还是构建全新应用程序,都应遵守指南规定,确保评估有效、顺 利。 例如将数据库迁移到 MySQL 集群中,很可能对当前数据模型和访问方式进行优化,以使其适用于原存储引 擎中。 您可能需要修改某些模式和查询,以便使 MySQL 集群达到最佳的性能。 下文给出评估前您应考虑的最佳措施。 5.1 硬件 您进行评估是否有配置充分资源的足够主机? 版权 © 2012,Oracle 和/或其附属公司,版权所有。 10 针对早期评估和原型,通常将所有的集群节点部署到单一物理主机上空间是足够的。 考虑使用 MySQL 集群 管理器中的 Bootstrap 选项,快速启用(见上文“如何安装 MySQL 集群”)。 如果您要全面评估 MySQL 集群的性能和 HA(高可用性)特征,建议的最低硬件配置如下:  两台主机,每台主机上运行一个数据节点。  两台主机,每台主机上运行一个应用程序节点和管理服务器。 这将确保在构成 MySQL 集群的所有进程上达到最低水平的冗余。 有时候可通过在相同主机上共置 MySQL 节点和数据节点消除网络延迟,提高性能。 每个节点类型建议的硬件规格如下所示: 数据节点 ⁃ 32 x x86-64 位 CPU 内核。 尽量使用高频率处理器,加快节点间信息处理; ⁃ 较大的 CPU 缓存有助于性能优化; ⁃ 内存容量充足、可以存储内存数据集的 64 位主机; ⁃ 见上述章节中推荐的评估内存需求的方法。 ⁃ Linux、Solaris 或 Windows 操作系统。 ⁃ 2 x 网络接口卡和 2 x 硬件冗余电源 为避免数据中心单点故障,2 个数据节点构成的节点组应使用不同基础设施(如电源和制冷)。 如有可能对系统进行合理配置,减少磁盘数据交换,这点十分重要。 一般而言,每个数据节点上磁盘配置空间应为 DataMemory 7 倍。 该空间用于存储 2 个局部检查点 (LCP)、重做(Redo)日志和 3 个备份文件。 如果您使用磁盘数据,将需要为其分配空间 —— 包 括对预留额外空间进行备份。 磁盘驱动器的相关建议如下: 配备快速、低延迟子系统十分重要,因为这些性能会影响到检查点和 备份。 图 4 检查点和重做日志建议的磁盘配置 版权 © 2012,Oracle 和/或其附属公司,版权所有。 11 图5 基于磁盘表建议的磁盘配置 MySQL 服务器端/应用程序节点 ⁃ 4 - 32 x86-64 位 CPU 核心 ⁃ 内存至少 4GB,该层的内存大小并非至关重要,具体要求受连接和缓冲存储器的影响。 ⁃ 2 x 网络接口卡和 2 x 硬件冗余电源。 集群部署 为进行评估,建议在指定网络上(如起始 IP 地址 10.0.1.0 的网络)部署数据和应用程序节点,网络最低要求 为 1 Gb 以太网。MySQL 服务器也可以加入公共网络,以便进行应用程序访问,优化第二数据中心的异构复 制。也可以在广域网链接中定位数据节点,但初始评估中不建议。 为提供网络故障恢复力,建议使用有保障的冗余网络接口卡(NIC)来配置每台服务器,连接到冗余交换 机。如果在单个主机(如 Oracle Sun T 系列系统)上部署多个数据节点,建议绑定 4 个或更多 NIC,以适应 更高的带宽要求。 5.2 性能度量 主要衡量因素有: ⁃ 每秒需处理多少事务? ⁃ 响应时间要求如何? ⁃ 加入一个应用程序节点或数据节点后性能扩展情况如何? ⁃ 集群丢失一个应用程序或数据节点后性能会受到何种影响? ⁃ 运行备份和模式变更等在线维护时,性能受到的影响如何? ⁃ 如拔掉网线、结束数据库进程或关闭电源等情况后,数据库运行受到怎样影响? 版权 © 2012,Oracle 和/或其附属公司,版权所有。 12 5.3 测试工具 验证性能标准时您需要什么工具 ? 这些测试工具来自遗传系统并针对该环境进行过优化么? 如果这样,考虑重做,并做公平合理的比较。 5.4 SQL和NoSQL 接口 MySQL 集群将表存储在数据节点中,而不是存储在 MySQL 服务器上,访问数据库的接口有多种。 开发者有如下选择: ⁃ 用于复杂查询及访问应用程序和专业知识组成的丰富生态系统的 SQL; ⁃ 简单键值(Simple Key-Value)接口绕过 SQL 层,提供快速的读取操作; ⁃ 微秒级延迟的实时接口。 根据不同接口,开发人员可以在其喜爱的环境下从事开发,提高了生产效率和灵活性,使新服务投放市场的 时间大为缩短。如有需要,可通过多种访问方式访问相同数据集(如通过 SQL 提供服务以及通过键值 API 进行网络访问)。 下图旨在介绍每个 API 的功能和使用情况。 图 6 MySQL 集群 API 速查表 API 常见选择为使用 MySQL 服务器提供到数据节点的标准 SQL 接口,连接所有的标准 MySQL 连接器,包 括:  常见 web 开发语言和框架,如 PHP、Perl、Python、Ruby、Ruby on Rails、Spring、Django 等;  JDBC(用于其它至 ORM 的连接,包括 EclipseLink、Hibernate 等);  .NET;  ODBC。 版权 © 2012,Oracle 和/或其附属公司,版权所有。 13 在实时性很重要的场合,建议考虑使用 native NoSQL API,如 NDB API(C++ API)、memcached 或 Java 专 用 MySQL 集群连接器。 在 SQL 上使用 NDB API 的优势:  较低延迟和成本 —— 需解析或优化查询;  对应用程序和数据节点之间的交互活动进行细致的管理;  可以针对响应时间重要的请求进行相应的调节;  批量接口 —— 可以对插入、更新、读、删除等操作进行批量处理。可以在一份或多分表中对这些批 量处理进行定义;  使用 NDB API,其延迟比 SQL 至少少三倍,一般更取决于请求类型和是否采用了批量接口。 从下列开发指南中您可以了解到 NDB API 详情: http://dev.mysql.com/doc/ndbapi/en/index.html 从下列页面您可以了解到 MySQL 集群专用 Memcached API 的详情: http://www.clusterdb.com/mysql-cluster/scalabale-persistent-ha-nosql-memcache-storage-using-mysql-cluster/ 参考下列白皮书,了解 Java 专用 MySQL 集群连接器的更多信息: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_connector_for_java.php 5.5 数据模型和查询设计 该数据模型是专为 MySQL 集群开发还是仅仅为一种继承模型呢? 评估数据集是否反映了某些实际的问题呢? 您有需要匹配相关使用情况的查询要测试么? 这种情况是常规情况还是极端情况呢? 良好的数据模型和查询对性能至关重要。只有充分理解网络延迟、数据算法和搜索数据结构基本要点才能成 功进行评估。  所设计的数据模型和查询应能最小化节点之间的网络回路(确保连接满足 AQL 要求并避免进行全表 扫描,这样有助于最小化节点之间的网络回路。  在哈希表中查询数据是一种时间恒定的操作,不受数据集的影响。  树状结构(T 树、B 树)中查询数据的算法复杂度为(O (log n))。 对于数据库设计师而言,这意味着检索数据时选择合适的索引结构和访问方式对检索至关重要。强烈建议将 对性能要求高的应用程序请求设计为主键查询。因为在哈希结构中查询数据比从树状结构中查询数据的速度 更快,通过单个数据节点即可实现。因此,在数据模型中考虑该问题十分必要。选择合适主键定义也极为重 要。 如要求进行排序索引查询,则应将表分区,确保扫描数据节点仅有一个。 让我们看一看使用者的数据库实例。该实例在电信行业属于常见情况。在用户数据库中,将用户配置文件分 布到多个表中属于常见现象。并且,一般使用全局用户 ID。接着,用户的网络识别标记将被映射到该 ID。 对每份用户表,用户 ID 符合下列两种情况之一:  用户配置文件中表的唯一主键即为全局用户 ID(gsid);  主键内容的一部分,如用户服务表中可能存储了多种服务,因此主键可能是 形式的 组合键。 版权 © 2012,Oracle 和/或其附属公司,版权所有。 14 全局用户 id 为表中的单主键时,只需通过简单的主键请求即可完成数据读取。但如果全局用户 id 只是综合 主键的一部分时,则存在两种可能: 使用排序索引扫描获取数据: SELECT * FROM service WHERE gsid=1202; 使用查询中的优先知识。通常情况下,用户无法获得超过固定服务数的服务。严谨的人往往并不喜欢这一 点,但使用该信息可以优化查询,提升查询速度,并且比顺序索引扫描的扩展性好) SELECT * FROM service WHERE gsid=1202 and serviceid IN (1, 2, 3, 4,5,6,7,8,10...64); 选择 gsid 作为每个表的分区键,与同一用户所用表单相关的事务都可以在单一数据节点上完成 —— 相当于 通知应用程序分布(详细情况请参阅第 0 节)。 如果您正在使用 NDB API,您可以将上述方法结合 NDB API 中的批处理接口,读取网络回路中的用户配置 文件(使用 SQL 时,每次读取表都会产生不必要的往返传输)。 集群的分布式属性和利用节点上多个 CPU、核心或线程的能力意味着:如果所设计的应用程序可以并行处理 多项事务,则可以使系统性能最大化。此外,您也可以同时运行多个应用程序,确保集群始终能够并行处理 多项事务。 使用上述设计原理,同时结合分区和分布式思路,可以设计出高性能、高扩展性数据库。 出现在数据节点中的应用程序查询的累积信息可通过 ndbinfo.counters 表查询 —— 说明见 http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-ndbinfo-counters.html 。 最大化 MySQL 集群性能的设计数据模型和查询,详细情况见《MySQL 集群数据库性能优化指南》: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php 5.6 使用磁盘数据表或内存表 标识待存储到磁盘上的表数据,从而可以使数据集大小可大于物理内存。 可选择使非索引属性驻留磁盘,索引属性一般常驻内存。表上数据库越大、索引越多,需要的内存或主机往 往资源越多。 与多数基于磁盘的数据库管理系统(DBMS)类似,系统提供一个 LRU(最近最少使用算法)缓冲来进行缓 存,该缓冲区可以将常用页面调入内存。读取含有磁盘数据的记录时,在缓冲区内存中查找是否有所需页 面。如缓冲区无要查找的页面内容,需从磁盘上查找该记录数据。 在某些阶段,缓冲区缓存设置了检查点,缓冲区的所有页面都回写到表空间中。表空间和为索引属性分配的 可用内存共同决定磁盘数据表中可存储的数据量。 也就是说,MySQL 集群中的磁盘数据表与传统的基于磁盘的数据库管理系统(DBMS)一样存在性能的局限 性。缓冲区缓存越大越好,因为这样更能预防可能出现的磁盘输入/输出越界问题。对可能遇到大量随机访 问、性能和响应时间等要求较高的表,采用内存表的设计方式可提高性能,避免输入/输出操作时出现越界问 题。 ndbinfo.diskpagebuffer 表显示缓存有效性信息; MySQL 集群 电信运营商级版本 用户可随时通过 MySQL 企 业级监控器查看该信息: http://www.clusterdb.com/mysql-cluster/further-mysql-cluster-additions-to-mysql-enterprise-monitor/ 版权 © 2012,Oracle 和/或其附属公司,版权所有。 15 5.7 用户自定义分区和分配条件 如上所述,向将 MySQL 集群作为存储引擎的表中添加行时,每行被分配到一个分区单元(分片)中,而分 片由集群中的特定数据节点控制。将处理事务所需的全部数据集中放入一个分片中往往可以获得最佳性能。 也就是说,在单数据节点上可以实现最佳性能,而多数据节点之间的数据转发和弹回会产生额外延迟。 默认情况下,MySQL 集群根据哈希主键分区数据。从 MySQL 集群的主键中选取合适的字段加载到哈希算法 中,不适用默认的操作行为。这种情况下您可以驾驭该系统,在主键位于同一个数据节点上的多个表中查找 相关数据。与此类似,单个数据节点中可以包括多种索引扫描 —— 该操作进程称之为“分区修剪”。 分区修剪的优势取决于集群中数据节点的数量以及结果集的大小 —— 增加数据节点、减少待检索记录数均 能提高性能。 图 7 显示分区修剪(橙色柱条)如何减少更小数据集中的时间延迟,但在较大数据集中会增加延时。注意: 柱条较短表示性能更佳。 图7 索引扫描分区修剪的效果 5.8 并行化应用程序和其他提示 如上所述,MySQL 集群是分布式自动分片数据库。这就意味着在实际操作中,并行工作、处理应用程序请 求的数据节点往往不止一个。 并且,MySQL 集群 7.2 提升了多线程处理功能,数据节点现在可以更有效利用多线程/核心。为使用这种功 能,启动数据节点时应使用 ndbmtd 二进制文件而非 ndb 文件进行配置,并且需正确配置 config.ini 文件—— http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-programs-ndbmtd.html。 可通过以下几种方式在 MySQL 集群中实现并行化:  增加更多应用程序节点  使用多线程数据节点  对请求进行批量处理  将连接到数据节点上的不同应用程序节点上的作业并行化  利用每个应用程序节点和数据节点之间的多次连接(连接池) 版权 © 2012,Oracle 和/或其附属公司,版权所有。 16 可根据参考因素确定处理所需负载需要的线程和应用程序的数量。方法之一: 每次连接一个应用程序节点, 并提高线程数。当某应用程序节点的负载不再增加时再增加另一个应用程序节点。建议开始学习该内容时, 在具有两个数据节点的集群上操作,再增加数据节点数量,从而了解系统是如何扩展的。如果按照本手册中 的最佳操作指南设计应用程序查询和数据模型,应用程序产生负载时,数据节点系统的吞吐量接近两数据节 点系统吞吐量的两倍。 如有可能,在更多 MySQL 服务器上尝试多线程和负载平衡。在 MySQL 集群中可以提升其他性能,更加充 分利用多核心/线程 CPU,包括:  在 MySQL 服务器到数据节点之间设置多重连接,降低锁定连接次数(--ndb-cluster-connection- pool=X): http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-program-options-mysqld.html#option_mysqld_ndb-c- connection-pool  设置线程的实时优先级: http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd- realtimescheduler  锁定数据节点线程(CPU 的内核线程和维护线程): http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-ndbd-definition.html#ndbparam-ndbd- lockexecutethreadtocpu 6 配置文件的相关建议 下列为 MySQL 集群常规配置文件模板。多数参数可保留默认值,但某些重要参数需根据实际情况进行修 改: config.ini [TCP DEFAULT] SendBufferMemory=2M ReceiveBufferMemory=1M [NDB DEFAULT] NoOfFragmentLogFiles= 6 * DataMemory (MB) / 64 上述内容仅做提示用,但如果您了解每秒写入的数据量,则可以进行详细配置。 MaxNoOfExecutionThreads=8 该值取决于数据节点主机上的核心数。单核主机上无需该参数。对于 2 核心主机,将该参数值设为 3.对 4 核 心主机,将该参数值设为 4。对于 8 核心以上主机,将该参数值设为 8。 RedoBuffer =32M LockPagesInMainMemory=1 my.cnf [mysqld] ndb-use-exact-count=0 ndb-force-send=1 engine-condition-pushdown=1 注意:如果使用 MySQL 集群管理器,请定义配置参数,无需编辑 config.ini 文件,具体操作请参阅 www.mysql.com/cluster/mcm 版权 © 2012,Oracle 和/或其附属公司,版权所有。 17 7 完整性检查 开始检测前有必要对运行环境进行完整性检查。请考虑下列问题: 我能根据 config.ini 和 my.cnf 中指定的主机名/IP 地址 ping 通 MySQL 集群中的所有机器么? 是否安装了可能阻止数据节点间通过必要端口进行通信的防火墙? 提示:运行 traceroute 命令,检查确定各节点之间不存在不必要的路由器跳数。 我的磁盘空间是否充足? 提示: 最好使可用磁盘空间保持在 DataMemory 大小的 10 至 12 倍。 数据节点上是否有足够的内存空间,以便处理数据集? 提示: 数据节点启动时如无法分配充足的内存空间,将无法启动。 我在任何地方都能获得相同版本的 MySQL 集群么? 提示:出现不匹配时,ndb_mgm –e show 和集群会提示存在不匹配现象。 7.1 确定可以检测集群的部分基本测试 针对 MySQL 集群,通过下列基本测试可以了解其运行情况。 创建基本表 CREATE TABLE t1 (a integer, b char(20), primary key (a)) ENGINE=NDB; 插入部分数据 INSERT INTO t1 VALUES (1, ‘hello’); INSERT INTO t1 VALUES (2, ‘hello’); INSERT INTO t1 VALUES (3, ‘hello’); INSERT INTO t1 VALUES (4, ‘hello’); 从表中选择数据 SELECT * FROM t1; 从管理服务器端(ndb_mgm)重启某数据节点(ndbd) 3 restart –n 检查节点是否重启、是否重新连接集群、是否所有节点已正常连接 show all status 从表中选择数据 SELECT * FROM t1; 在其他数据节点上重复该操作 如果无法顺利完成上述步骤,在获取返回数据时出错,或启动/停止数据节点时出问题,需查看出错日志、网 络和防火墙,并了解原因。 如上所述,为您提供的论坛和邮件列表可以帮您解决初始配置问题。MySQL 集群 论坛地址: http://forums.mysql.com/list.php?25 MySQL 集群邮件列表如下: Cluster@lists.mysql.com 版权 © 2012,Oracle 和/或其附属公司,版权所有。 18 8 故障解决 评估过程中如需测试 MySQL 集群容量和性能的临界情况,不妨将相关问题设置为初始集群配置。该节指出 可能遇到的部分相关出错情况、错误原因及如何解决错误。 8.1 表满(内存或磁盘空间) 出错信息提示 ERROR 1114: The table '' is full 原因分析 下列原因之一:  与数据库相关的所有内存已用尽,表无法继续增加。注意:内存用于存储索引,即便其他表 数据均存储在磁盘上。 或  表中含有磁盘数据,且相关表空间容量已用尽。 或  哈希索引已满,每个分区单元超过 49,000,000 行。 解决方案 如内存用尽: 如果数据库空间无法减小,并且除硬盘外在内存中已无空间存储其他数据,则需分配更多内 存。 如果主机上物理内存依然有剩余,则将更多内存分配给数据库,通过增加 IndexMemory 和 DataMemory 配置参数即可(详情请参阅“MySQL 集群参考指南”)。 如无更多物理内存可用,可以在主机添加内存,或将运行在新主机上的新节点组加入其中。 如果与表空间(TABLESPACE)有关的磁盘空间用完: 如果主机磁盘上尚有剩余空间可用,可使用 ALTER TABLESPACE SQL 命令增加为表分配的 存储空间。否则,在增加 TABLESPACE 空间前需增加额外的硬件,提高磁盘空间大小。 如果哈希索引满: 增加分区数量后,每个分割单元的行数降低。默认情况下,MySQL 集群每个 LQH 线程中自动 增加 1 个分区单元,因此分区单元的数量因下列情况而增加: o 添加更多数据节点 o 使用 ndbmtd 并合理设置 MaxNoOfExecutionThreads 增加每个数据节点的 LQH 进程数 http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-programs-ndbmtd.html#ndbparam- ndbmtd-maxnoofexecutionthreads 上述操作后,需运行: mysql> ALTER TABLE mytab REORGANIZE PARTITION; 此外,也可以针对 MySQL 集群提供最大的表,提高分区单元的数量: ALTER TABLE mytab MAX_ROWS=100000000; 最后,您可以指定待用分区单元的数量,但该数会限制随后在表上进行的在线重分区。因此,在多数 情况下,这种操作不可取: mysql> ALTER TABLE mytab PARTITION BY KEY (`pk`) PARTITIONS 32;; 版权 © 2012,Oracle 和/或其附属公司,版权所有。 19 8.2 重做(REDO)日志所用空间不足 出错信息提示 Temporary error: 410: REDO log buffers overloaded, consult online manual (increase RedoBuffer, and|or decrease TimeBetweenLocalCheckpoints, and|or increase NoOfFragmentLogFiles) 原因分析 为重做(REDO)缓冲区分配的空间不足,难以执行当前的数据库操作(所需空间决定于更新率,而 非数据库大小)。 解决方案 加入 NoOfFragmentLogFiles 参数(默认值设为 16),配置其他日志文件。每新增一个日志文件即可 增加重做日志空间 64MB。滚动重启(含 --initial 选项)会变更生效。 8.3 死锁超时 出错信息提示 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 原因分析 某节点必须等待的时间比 TransactionDeadlockDetectionTimeout 指定的时间(默认值 1.2 秒)更长,因 此在客户端提示出错。其根本原因可能如下:  存在节点故障(属于资源问题)  节点负载过重  另一个操作占用资源时间过久(应用程序设计) 解决方案 如节点出现故障,恢复故障(如有必要请更换硬件)。 尝试增加 TransactionDeadlockDetectionTimeout 值,应对过载问题。 检查应用程序设计并找出占用资源时间更短的方法(如,在安全前提下使用多个更短事务)。 8.4 部分变化 出错信息提示 ERROR 1297 (HY000): Got temporary error 1204 'Temporary failure, distribution changed' from NDBCLUSTER 原因分析 这是种暂时性出错,在数据节点启动后,MySQL 服务器尝试访问数据库时会发生这种错误。 解决方案 应用程序接收到这种临时措施通知后将重试。 如上所述,为您提供的论坛和邮件列表可以帮您解决初始配置问题。MySQL 集群 论坛地址: http://forums.mysql.com/list.php?25 MySQL 集群邮件列表如下: cluster@lists.mysql.com 版权 © 2012,Oracle 和/或其附属公司,版权所有。 20 9 结论 本手册中,我们介绍了最佳的操作方法。根据该操作,您可以快速有效地评估 MySQL 集群数据库。我们建 议在开始评估前,先了解您将要使用的应用程序和可用硬件的特征。 当然,您还可以咨询 Oracle MySQL 集群咨询团队,加速评估速度和应用程序恢复原型,从而可以缩短新的 数据库应用程序的上市时间。来自世界最大型 web 站点、电信和政府组织 MySQL 集群项目的 Oracle 的 MySQL 集群咨询人员提供随时随处为您提供最精深的专业咨询。 http://www.mysql.com/consulting/ 10 其他资源 MySQL 集群快速启用指南: http://www.mysql.com/products/cluster/start.html Bootstrapping MySQL 集群: http://www.clusterdb.com/mysql-cluster/mysql-cluster-manager-1-1-2-creating-a-cluster-is-now-trivial/ MySQL 集群文档: http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster.html MySQL 集群 API 开发指南: http://dev.mysql.com/doc/ndbapi/en/index.html MySQL 集群 7.2:新功能白皮书 http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php.zh 用 MySQL 集群扩展 Web 数据库指南 http://www.mysql.com/why-mysql/white-papers/mysql_wp_scaling_web_databases.php.zh MySQL 集群性能优化指南: http://mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php MySQL 集群用户论坛和邮箱列表: http://forums.mysql.com/list.php?25 cluster@lists.mysql.com 版权 © 2012,Oracle 和/或其附属公司,版权所有。 21 甲骨文(中国)软件系统有限公司联系 北京 远洋光华中心办公室 北京市朝阳区景华南街 5 号远洋光华中心 C 座 21 层 oracle.com/cn http://www.mysql.com (MySQL) 联系我们 800 810 0161 mysql-sales_cn_grp@oracle.com © 2012 Oracle, Java 为美国甲骨文股份有限公司及其子公司、关联公司在美国与其他国家的注册商标。其他名称有可能为各个公司的注册商标 或商标。
还剩20页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

anysort

贡献于2012-12-10

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!