数据库应用与设计-大型数据库系统架构设计方法.ppt

,第三章,大型数据库系统应用 设计方法,可扩展性、高可用性及负载均衡,基本概念,可扩展性（Scalability|伸缩性）：,在一些大的系统中，预测最终用户的数量和行为是非常困难的，可扩展性是指系统 适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就增加 资源（CPU，内存，硬盘等），集群是解决这个问题的另一种方式，它允许一组服 务器组在一起，像单个服务器一样分担处理一个繁重的任务。 高可用性（High availability）：,单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账 单处理这样一些关键的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一 些服务在任何时间都可以访问并在可预期的合理的时间周期内有响应。集群方案通 过在集群中增加的冗余的服务器，使得在其中一台服务器失效后仍能提供服务，从 而获得高的可用性。,负载均衡（Load balancing）：,负载均衡是集群的一项关键技术，通过把请求分发给不同的服务器，从而获得高可 用性和较好的性能。一个负载均衡器可以是从一个简单的Servlet或Plug-Ins（例如 一个Linux box利用ipchains来实现），到昂贵的内置SSL加速器的硬件。除此之外， 负载均衡器还需执行一些其他的重要任务，如“会话胶粘”让一个用户会话始终存 在一个服务器上，“健康检查”用于防止将请求分发到已失效的服务器上。有些负 载均衡器也会参与我们下面将要谈到“失效转移”过程。,基本概念,容错（Fault tolerance）：,高可用性意味着对数据正确性的要求不那么高。在J2EE集群中，当一个服务器实例 失效后，服务仍然是有效的，这是因为新的请求将被冗余服务器处理。但是，当一 个请求在一个正在失效的服务器中处理时，可能得到不正确的结果。不管有多少个 错误，容错的服务应当能确保有严格的正确的行为。 失效转移（Failover）：,失效转移是集群中用来获取容错能力的另一项关键的技术。当一个结点失效后，通 过选择集群中的另一个结点，处理将会继续而不会终止。转移到另一个结点可以被 显式的编码，或是通过底层平台自动地透明地路由到另一个服务器。 等幂方法（Idempotent methods）：,等幂方法是指这样一些方法：重复用相同的参数调用都能得到相同的结果。这些方 法不会影响系统状态，可以重复调用而不用担心改变系统。例如：getUsername() 就是等幂的，而deleteFile就不是。当我们讨论HTTP Session失效转移和EJB失效转 移时，它是一个重要的概念。,讨论的背景,主题,数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析,范式问题解析（Normalization）,数据库基本问题调查,大家都使用过哪些数据库？,哪些内容是数据库系统的关键点？,常见的数据存储,传统的数据库系统, Oracle, DB2、SQL Server, MySQL、PosgreSQL,分布式数据库, Google Spanner & BigTable & MegaStore OceanBase、Hbase,缓存服务器 KeyValue Store, Tair, Memcached Redis,数据库的主要特性,ACID, 原子性（Atomicity） 完整性（Consistency） 隔离性 （Isolation） 持久性 （Durability）,Relation SQL, Structured Query Language （即SQL）, A Relational Model of Data for Large Shared Data Banks,（By Edgar Codd）,RDBMS之前的数据库的问题,不支持数据独立性,数据库与应用系统之间的强耦合 应用系统的复杂度,应用系统本身的规模较小（性价比？）,关系数据库的主要业务场景,Billing （记账类业务，电信、银行） Booking （订票类业务，航空） Inventory （库存管理，零售）,这些业务的共同特征是什么？,关系数据库的关系来自哪里？,这是关系的一个来源,另一个来源是Normalization,ACID的基础概念,Transaction的概念借自Contract Law 一手交钱、一手交货（Atomicity）, 不会出现库存为负，也不会出现资金为负的情况（Consistency） 可同时与多人进行交易（Isolation） 离柜概不负责（Durability）,Atomicity, 要么全部成功，要么全不成功,Consistency, 写入数据库的数据必须满足所有定义的约束规则（主键、唯一键、外键等,约束）,Isolation, 确保并发执行的事务就如同串行执行的事务一样，保证系统状态（state）,的一致性。 Durability, 一旦提交，哪怕出现掉电、Crash也不会丢数据,几个基础概念,Write-Ahead Log Redo, Logical Physical, Physiological,Undo,事务槽事务标识,SCN 系统变更统一时间戳（逻辑时钟）,如何实现原子性 一个简单购物场景, ,A卖一件衣服给B A的衣服库存-1 A的资金+N B的衣服库存+1 B的资金-N,如何实现原子性（2）,事务槽为变更入口，单一入口（原子） 每个变更的记录都包含事务槽信息,数据库中如何保证C,通过Read Dirty与锁来解决PK/UK,通过Ref检查来解决FK的问题（需要Index） 通过PreCommit trigger来做Null以及Check,数据库中如何保证I,锁控制, 不同粒度的锁（表级、块级、记录级）, 不同维度的锁（数据相关锁，内存相关锁）,MVCC, Snapshot Isolation, Block Image + SCN + Undo Image 判断,差别在于读取哪个时间点的Snapshot,数据库中如何保证D,Log before Data,LGWR before DBWn Flush Log on Commit Durability On Commit,Checkpoint Before Redo Log File Reuse,ACID的代价,不同的Isolation对应不同的代价, Serialiazability, Read Committed (Through Snapshot) Read Dirty ? （没有并发控制）,不同的Durability级别, Flush on Commit, Flush on Timeout ( Time Range) Flush on Batch ( commits count?),主题,数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析,范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾,NORMALIZATION,先做个小游戏,用笔记录下, 学生名单、老师姓名、讲师简介、课程名称、课程简介,调整下, 老师（黄晋汤庸）以及对应的老师简介,再次调整下, 课程 （数据库概论分布式数据库原理）简介,NORMALIZATION解决的问题,更新一个源头不会出现异常 每份数据只有一个源头, 如何保证多份数据的一致性？ 一份数据有多少个源头？ 同一份数据被重复了多少次？, 对应的存储空间？, 为了存储耗费的其它资源？,NORMALIZATION带来的问题,表之间的依赖（关系依赖，耦合）,表关联的成本（关联开销，可能的IO开销） 系统扩展的复杂度（解耦合）,如何权衡NORMALIZATION,尽量不要对静态数据做Normalization, 除非你希望节约存储空间,考虑范式化 Vs 反范式化的投入产出 为什么很多IT新人喜欢Normalization 那是因为他们的老师告诉他们需要,建议, 适度的使用, 关键在于判断业务之间的耦合性,主题,数据库基本问题调查 关系数据库的基本背景 ACID基本概念解析,范式问题解析（Normalization） 数据库的扩展性浅析 常见数据库系统回顾,一个小实验,如何将2个人从这里送到大学城？ 如何将5个人从这里送到大学城？ 如何将50个人从这里送到大学城？ 如何将500个人从这里送到大学城？ 如何将5000个人从这里送到大学城？ 如何将50000个人从这里送到大学城？,数据库的扩展性问题,数据库架构、系统架构在于：, 如何满足如下的要求,检索问题, Relation,并发问题, Isolation, Consistency(UK),一致性问题 Isolation,速度问题, Performance, Durability+Isolation,数据库检索问题,如何从班级的联系方式中找到XX的电话号码？ 如何从公司的联系方式中找到XX的电话号码？ 如何从移动公司的系统中找到XX的电话号码？,如何从移动、电信、联通的数据库找到XX的电话号码？,数据库的并发问题,同时有多个人要购买手机号？,如何保证大家购买的不是同一个手机号？,如何支持几百、几千、几万人同时购买手机号？,数据库的一致性问题,如何保证大家看到的库存有效？ 如何保证读取的信息是准确的？,库存的变更如何实时的提供给每一个人看到？,数据库的性能问题？,如何快速的让1个人买到号码？, 有多快？,如何快速的让10个人买到号码？, 要不要排队？ 一个服务员？ 一个营业厅？,PERFORMANCE VS SCALABILITY,1.当只有一个人访问时，速度如何？ 2.当有很多人访问时，速度如何？, 大家都同样快？,如果满足1, 表示Performance很好？,如何能较好的满足2, 表示系统有较好的Scalability,一致性问题再探讨,新浪发的微薄需要强一致吗？,ITPUB的论坛需要强一致吗？ 当当的图书描述信息需要强一致吗？ 12306的火车票库存信息需要强一致吗？ 支付宝/财付通的账户余额需要强一致吗？ 中行信用卡/招商银行卡的账户信息需要强一致吗?,讨论扩展性,数据库系统的扩展性, ,Scale（扩展）就是让我们的数据库能够提供更强的服务能力， 更强的处理能力。 Scalable（可扩展）则是表明数据库系统在通过相应升级（包 括增加单机处理能力或者增加服务器数量）之后能够达到提供 更强处理能力。在理论能上来说，任何数据库系统都是 Scalable 的，只不过是所需要的实现方式不一样而已。 Scalability（扩展性）则是指一个数据库系统通过相应的升级 之后所带来处理能力提升的难易程度。虽然理论上任何系统都 可以通过相应的升级来达到处理能力的提升，但是不同的系统 提升相同的处理能力所需要的升级成本（资金和人力）是不一 样的，这也就是我们所说的各个数据库应用系统的 Scalability 存在很大的差异。,数据库系统的扩展性, ,Scale Up 则是指纵向的扩展，向上扩展，也就是通过增加当前 处理节点的处理能力来提高整体的处理能力，是通过升级现有 服务器的配置，如增加内存，增加CPU，增加存储系统的硬件 配置，或者是直接更换为处理能力更强的服务器和更为高端的 存储系统。 Scale Out 就是指横向的扩展，向外扩展，也就是通过增加处 理节点的方式来提高整体处理能力，即通过增加机器来增加整 体的处理能力。,SCALE UP 优缺点,Scale Up 优点：, ,处理节点少，维护相对简单； 所有数据都集中在一起，应用系统架构简单，开发相对容易；,Scale Up 缺点, ,高端设备成本高，且竞争少，容易受到厂家限制； 受到硬件设备发展速度限制，单台主机的处理能力总是有极 限的，容易遇到最终无法解决的性能瓶颈； 设备和数据集中，发生故障后的影响较大；,SCALE OUT 优缺点,Scale Out 优点, ,成本低，很容易通过价格低廉的PC Server 搭建出一个处理 能力非常强大的计算集群； 不容易遇到瓶颈，因为很容易通过添加主机增加处理能力； 单个节点故障对系统整体影响较小；也存在缺点，更多的计 算节点，大部分时候都是服务器主机，这自然会带来整个系 统维护复杂性的提高，在某些方面肯定会增加维护成本，而 且对应用系统的架构要求也会比 Scale Up 更高，需要集群 管理软件的配合。,Scale Out 缺点, ,处理节点多，造成系统架构整体复杂度提高，应用程序复杂 度提高； 集群维护难以程度更高，维护成本更大；,SCALABILITY很好的数据 库应用系统遵循的原则, 事务相关性最小化原则, 数据一致性原则, 高可用及数据安全原则,事务相关性最小化原则,分布式的架构带来分布式事务的问题,在传统的集中式数据库架构中，事务的问题非常好解决，可,以完全依赖数据库本身非常成熟的事务机制来保证。但是一 旦我们的数据库作为分布式的架构之后，很多原来在单一数 据库中所完成的事务现在可能需要跨多个数据库主机，这样 原来单机事务可能就需要引入分布式事务的概念。 ,分布式事务本身就是一个非常复杂的机制,不管是商业的大型数据库系统还是各开源数据库系统，虽然 大多数数据库厂家基本上都实现了这个功能，但或多或少都 存在各种各样的限制。而且也存在一些 Bug，可能造成某些 事务并不能很好的保证，或者是不能顺利的完成。,一些解决方案,1. 进行 Scale Out 设计的时候合理设计切分规则，尽可能保证事 务所需数据在同一个 MySQL Server 上，避免分布式事务。 2. 大事务切分成多个小事务，数据库保证各个小事务的完整性，,应用控制各个小事务之间的整体事务完整性。,3. 结合上述两种解决方案，整合各自的优势，避免各自的弊端。,1. 比如我们可以在保证部分核心事务所需数据在同一个 MySQL Server 上，而其他并不是特别重要的事务，则通 过分拆成小事务和应用系统结合来保证。,2. 通过这样相互平衡设计的原则，我们既可以避免应用程序 需要处理太多的小事务来保证其整体的完整性，同时也能 够避免拆分规则太多复杂而带来后期维护难度的增加及扩 展性受阻的情况,数据一致性原则,如何在 Scale Out 的同时又较好的保证数据一致性呢？, ,BASE 模型。即：基本可用，柔性状态，基本一致和最终一 致 简单来说，应用系统通过相关的技术实现，让整个系统在满 足用户使用的基础上，允许数据短时间内处于非一致状态， 而通过后续技术来保证数据在最终保证处于一致状态。,高可用及数据安全原则,在支持可扩展性的同时，要注意高可用性和数据安全。,基本方法,SHARDINGREPLICATIONCLUSTER,SHARDING,SHARE NOTHING,并行数据库要求尽可能的去并行执行数据库操作，从而提高性 能。在并行计算体系结构实现中有很多可选的体系结构。包括：,Share-memory：多个cpu共享同一片内存，cpu之间通过 内部通讯机制（interconnection network）进行通讯；,Share-disk ：,每一个cpu使用自己的私有内存区域，通过,内部通讯机制直接访问所有磁盘系统。,Share-nothing： 每一个cpu都有私有内存区域和私有磁盘 空间，而且2个cpu不能访问相同磁盘空间，cpu之间的通讯 通过网络连接。,并行计算体系结构,Share disk,share nothing,share memory,并行计算体系结构, ,Shared memory 体系结构的cpu之间通过主存进行通讯，具有 很高的效率；但当更多的cpu被添加到主机上时，内存竞争 contection就成为瓶颈，cpu越多，瓶颈越厉害。Shared disk也 存在同样问题，因为磁盘系统由 Interconnection Network 连接 在一起。 Shared memory和shared disk的基本问题是interference：当添 加更多的cpu，系统反而减慢，因为增加了对内存访问 （memroy access）和网络带宽（network bandwidth）的竞争。 这样shared nothing体系得到了广泛的推广。 Shared nothing体系是数据库稳定增长，当随着事务数量不断增 加，增加额外的cpu和主存就可以保证每个事务处理时间不变。,SHARED NOTHING,ARCHITECTURE (SN),A shared nothing architecture (SN) is a distributed,computing architecture in which each node is independent and self- sufficient, and there is no single point of contention across the system. More specifically, none of the nodes share memory or disk storage. People typically contrast SN with systems that keep a large amount of centrally-stored state information, whether in a database, an application server, or any other similar single point of contention. While SN is best known in the context of web development, the concept predates the web: Michael Stonebraker at the University of California, Berkeley used the term in a 1986 database paper.1 In it he mentions existing commercial implementations of the architecture (although none are named explicitly). Teradata, which delivered its first system in 1983, was probably one of those commercial implementations.2 Tandem,Computers officially released NonStop SQL, a shared nothing database, in 1984. 3,SHARED NOTHING,ARCHITECTURE (SN),Shared nothing is popular for web development because of its scalability. As Google has demonstrated, a pure SN system can scale almost infinitely simply by adding nodes in the form of inexpensive computers, since there is no single bottleneck to slow the system down.4 Google calls this sharding. A SN system typically partitions its data among many nodes on different databases (assigning different computers to deal with different users or queries), or may require every node to maintain its own copy of the applications data, using some kind of coordination protocol. This is often referred to as database sharding.,从 SHARD 到 SHARDING, ,“Shard” 这个词英文的意思是”碎片”，而作为数据库相关的技术用语，似 乎最早见于大型多人在线角色扮演游戏(MMORPG)中。”Sharding” 称之为” 分片”。 Sharding 不是一门新技术，而是一个相对简朴的软件理念。MySQL 5 之后 才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可 扩展性与否的一个关键指标(当然不是唯一指标)。数据库扩展性是一个永恒 的话题，MySQL 的推广者经常会被问到：如在单一数据库上处理应用数据 捉襟见肘而需要进行分区化之类的处理，是如何办到的呢? 答案是： Sharding。 Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之 上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方 案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库 扩展性问题。,数据库扩展性,目前的商业数据都有自己的扩展性解决方案，在过去相对来说比较 成熟，但是随着互联网的高速发展，不可避免的会带来一些计算模 式上的演变，这样很多主流商业系统也难免暴露出一些不足之处。 比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用， 瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成 本都相对比较高。,Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听 说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。,SHARDING 的应用场景,任何技术都是在合适的场合下能发挥应有的作用。 Sharding 也一样。 联机游戏、IM、BSP 都是比较适合 Sharding 的应用场景。其共性是抽 象出来的数据对象之间的关联数据很小。, ,IM ，每个用户如果抽象成一个数据对象，完全可以独立存储在任 何一个地方，数据对象是 Share Nothing 的； Blog 服务提供商的站点内容，基本为用户生成内容(UGC)，完全 可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的。, ,“Share Nothing” 是从数据库集群中借用的概念，有些类型的数据粒度 之间就不是 “Share Nothing” 的，比如类似交易记录的历史表信息， 如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、 卖家会分别与其它用户继续进行交易， Sharding会可能导致两个买卖 家的信息会分布到不同的 Sharding DB 上，而这时如果针对买卖家查 询，就会跨越更多的 Sharding ，开销就会比较大。 Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，如处 理事务型应用会非常复杂。对于跨不同DB的事务，很难保证完整性， 得不偿失。所以，采用什么样的 Sharding 形式，不是生搬硬套的。,SHARDING与数据库分区 (PARTITION)的区别,有的时候，Sharding 也被近似等同于水平分区(Horizontal Partitioning)， 网上很多地方也用 水平分区来指代 Sharding，但二者之间实际上还是 有区别的。Sharding 的思想是从分区的思想而来，但数据库分区基本 上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够 有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库，甚至跨越物理机器的。,SHARDING 策略 Sharding根据切分规则类型，可分为两种切分模式：, ,数据的垂直（纵向）切分是按照不同的表（或者 Schema）来 切分到不同的数据库（主机）之上，这种切可以称之为； 数据的水平（横向）切分是根据表中的数据的逻辑关系，将同 一个表中的数据按照某种条件拆分到多台数据库（主机）上面， 这种切分称之为。,数据的垂直切分,数据的垂直切分，也可以称之为纵向切分。将数据库想象成为由很 多个一大块一大块的“数据块”（表）组成，我们垂直的将这些 “数据块”切开，然后将他们分散到多台数据库主机上面。这样的 切分方法就是一个垂直（纵向）的数据切分。,当我们的功能模块越清晰，耦合度越低，数据垂直切分的规则定义 也就越容易。完全可以根据功能模块来进行数据的切分，不同功能 模块的数据存放于不同的数据库主机中，可以很容易就避免掉跨数 据库的 Join 存在，同时系统架构也非常的清晰。,EXAMPLE 数据库-垂直划分 系统功能可以基本分为四个功能模块：用户，群组消息，相册以及 事件，分别对应为如下这些表：,用户模块表：,user, user_profile, user_group, user_photo_album,群组讨论表：,groups, group_message, group_message_content, top_message,相册相关表：,photo, photo_album, photo_album_relation, photo_comment,事件信息表：,event,EXAMPLE 数据库-垂直划分, ,群组讨论模块和用户模块之间主要存在通过用户或者是群组关 系来进行关联。一般关联的时候都会是通过用户的 id 或者 nick_name 以及 group 的 id 来进行关联，通过模块之间的接 口实现不会带来太多麻烦； 相册模块仅仅与用户模块存在通过用户的关联。这两个模块之 间的关联基本就有通过用户 id 关联的内容，简单清晰，接口明 确； 事件模块与各个模块可能都有关联，但是都只关注其各个模块 中对象的ID信息，同样可以做到很容易分拆。,EXAMPLE 数据库-垂直划分,我们第一步可以将数据库按照功能模块相关的表进行一次垂直拆分， 每个模块所涉及的表单独到一个数据库中，模块与模块之间的表关 联都在应用系统端通过接口来处理。,通过这样的垂直切分之后，之前只能通过一个数据库来提供的服务， 就被分拆成四个数据库来提供服务，服务能力自然是增加几倍了。,垂直切分的优缺点,垂直切分的优点, ,数据库的拆分简单明了，拆分规则明确； 应用程序模块清晰明确，整合容易； 数据维护方便易行，容易定位；,垂直切分的缺点, ,部分表关联无法在数据库级别完成，需要在程序中完成； 对于访问极其频繁且数据量超大的表仍然存在性能瓶颈，不 一定能满足要求； 事务处理相对更为复杂； 切分达到一定程度之后，扩展性会遇到限制； 过读切分可能会带来系统过渡复杂而难以维护。,数据的水平切分,水平切分可理解为是按照数据行的切分，就是将表中的某些行 切分到一个数据库，而另外的某些行又切分到其他的数据库中。, ,为了能够比较容易的判定各行数据被切分到哪个数据库中了， 切分总是都需要按照某种特定的规则来进行的。 如根据某个数字类型字段基于特定数目取模，某个时间类型 字段的范围，或者是某个字符类型字段的 hash 值。, ,如EXAMPLE数据库，所有数据都是和用户关联的，那么我们 就可以根据用户来进行水平拆分，将不同用户的数据切分到不 同的数据库中。 唯一有点区别的是用户模块中的 groups 表和用户没有直接关 系，所以 groups 不能根据用户来进行水平拆分。对于这种特 殊情况下的表，则可以独立出来，单独放在一个数据库中。,EXAMPLE数据库-水平划分,大部分的表都可以根据用户 ID 来进行水平的切分。不同用户相关的数据 进行切分之后存放在不同的数据库中。如将所有用户 ID 通过取模（模5） 然后分别存放于两个不同的数据库中。每个和用户 ID 关联上的表都可以 这样切分。这样，基本上每个用户相关的数据，都在同一个数据库中，即 使是需要关联，也可以非常简单的关联上。,水平切分的优缺点,水平切分的优点, ,表关联基本能够在数据库端全部完成； 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题； 应用程序端整体架构改动相对较少； 事务处理相对简单； 只要切分规则能够定义好，基本上较难遇到扩展性限制；,水平切分的缺点, ,切分规则相对更为复杂，很难抽象出一个能够满足整个数据 库的切分规则； 后期数据的维护难度有所增加，人为手工定位数据更困难； 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分 造成一定的困难。,利用 MYSQL PROXY 实 现数据切分及整合, ,MySQL Proxy 是 MySQL 官方提供的一个数据 库代理层产品，和 MySQL Server 一样，同样 是一个基于 GPL 开源协议的开源产品。可用来 监视、分析或者传输他们之间的通讯信息。他的 灵活性允许你最大限度的使用它，目前具备的功 能主要有连接路由，Query 分析，Query 过滤 和修改，负载均衡，以及基本的 HA 机制等。 实际上，MySQL Proxy 本身并不具有上述所有 的这些功能，而是提供了实现上述功能的基础。 要实现这些功能，还需要通过我们自行编写 LUA 脚本来实现。 MySQL Proxy 实际上是在客户端请求与 MySQL Server 之间建立了一个连接池。所有客 户端请求都是发向 MySQL Proxy，然后经由 MySQL Proxy进行相应的分析，判断出是读操 作还是写操作，分发至对应的 MySQL Server 上。对于多节点 Slave 集群，也可以起做到负载 均衡的效果。,高可用性,HIGH AVAILABILITY,SINGLE MYSQL SERVER,WHY HA?, Something can and will fail, Service Maintenance Downtime is expensive, Adding HA to an existing system is complex, 墨菲定律（Murphys Law）, Anything that can go wrong will go wrong,高可用性HA-IBM定义 业务连续性是指企业的一种能力，有了此能力，企业能够抵御中断，并根据预定义 的服务级别协议正常且连续不断地经营重要服务。要实现期望的给定级别业务连续 性，必须选择一系列服务、软件、硬件和过程，用文档计划加以描述，付诸实现并 定期实践。业务连续性解决方案必须解决有关数据、运营环境、应用程序、用于主 管环境的应用程序以及最终用户接口的问题。所有这些都必须予以提供，才能交付 完整的业务连续性解决方案。 业务连续性包括灾难恢复 (DR) 和高可用性 (HA)，是指抵御所有中断（预期中断、 意外中断以及灾难），并为所有重要应用程序提供连续处理的能力。最终目标是让 中断时间少于总服务时间的 0.001%。与灾难恢复方案相比，高可用性环境通常包 括要求更为苛刻的恢复时间目标（数秒到数分钟）和恢复点目标（零用户中断）。,可用性级别 90% 95% 99% 99.9% 99.99% 99.999%,每年的停机时间 36.5 天 18.25 天 3.65 天 8.76 小时 50 分钟 5 分钟,需要 100% 可用性的应用 程序吗？,在大多数情况下，可以通过实施合理的处理和系统管理实务来实现 高级别的可用性。当所需要的越接近连续可用性，则必须作出的投 资就越大。在作出这种投资之前，应该确信需要该级别的可用性。 下列数字显示不同技术所能提高可用性的程度，但是需要付出的成 本可能会随之增加。,系统可用性的定义, ,在特定时间内和特定条件下系统正常工作的相应程度。 可用性的测量方式：, ,系统的可用性(availability)，即利用率。 可用性的平均值即平均利用率，其计算方法为： A = MTBF / (MTBF + MTTR) MTBF(MeanTime Between Failures),故障间隔平均时间,MTTR(MeanTime To Repair),系统平均修复时间,A=uptime/(uptime+downtime),系统可用性的获得 可用性 ,容错性 (fault tolerance) ,完美性 (perfection) ,冗余技术硬件冗余 (redundancy)软件冗余,完美硬件 整机完美性,完美软件 ,可信软件,| |,时间冗余 信息冗余,部件完美性 器件完美性,| 静态冗余（部件冗余）,| 可用硬件,动态重组 |-被动重组（后备 stand-by） |-主动重组（优美降级 graceful degradation),完美性与避错技术 完美性追求一种避错技术，即避免出错。要求组成系统的各个部件、 器件具有高可用性，不允许出错，或者出错率降至最低。,硬件的可用性与完美性,指元器件的完美性、部件的完美性、整机与系统的完美性,软件的可用性与完美性是指软件的正确性、,完美性、兼容性。,容错性与容错技术, ,容错技术：在一定程度上容忍故障的技术 容错系统：采用容错技术的系统,当系统因某种原因出错或者失效，系统能够继续工作，程序 能够继续运行，不会因计算机故障而中止或被修改，执行结 果也不包含系统中故障引起的差错。,容错技术也称为故障掩盖技术(fault masking)。,容错性与容错技术, ,冗余技术是容错技术的重要结构，它以增加资源的办法换取可 用性。由于资源的不同，冗余技术分为硬件冗余、软件冗余、 时间冗余和信息冗余。资源与成本按线性增加，而故障概率则 可按对数规律下降。 冗余要消耗资源，应当在可用性与资源消耗之间进行权衡和折 衷。,双CPU容错系统,当一个 CPU板出现故障时，另一个 CPU保持继续运行。这个过程 对用户是透明的，系统没有受到丝毫影响，更不会引起交易的丢失， 充分保证数据的一致性和完整性。系统的容错结构能够提供系统连 续运行的能力，任何单点故障不会引起系统停机，系统提供在线的 维护诊断工具可在应用继续运转的情况下修复单点故障。,冗余类型,1.硬件冗余：,增加线路、设备、部件，形成备份。,2.软件冗余：,增加程序，一个程序分别用几种途径编写， 按一定方式执行，分段或多种表决。,3.时间冗余：,指令重复执行，程序回卷技术。,4.信息冗余：,增加信息数据位数，检错、纠错。,容错系统工作方式 自动侦测(AUTO-DETECT),自动侦测(Auto-Detect),通过专用的冗余侦测线路和软件判断系统运行情况，发现可能的 错误和故障，进行严谨的判断与分析。确认主机出错后，启动后备 系统。 侦测程序需要检查主机硬件（处理器与外设部件）、主机网络、 操作系统、数据库、重要应用程序、外部存储子系统（如磁盘阵列） 等。, ,为了保证侦测的正确性，防止错误判断，系统可以设置安全侦 测时间、侦测时间间隔、侦测次数等安全系数，通过冗余通信 连线，收集并记录这些数据，作出分析处理。 数据可信是切换的基础。,自动切换(AUTO-SWITCH), ,当确认某一主机出错时，正常主机除了保证自身原来的任务继 续运行外，将根据各种不同的容错后备模式，接管预先设定的 后备作业程序，进行后续程序及服务。 系统的接管工作包括文件系统、数据库、系统环境（操作系统 平台）、网络地址和应用程序等。 如果不能确定系统出错，容错监控中心通过与管理者交互进行 有效的处理。 决定切换基础、条件、时延、断点,自动恢复(AUTO-RECOVERY),故障主机被替换后，离线进行故障修复。修复后通过冗余通信 线与正常主机连线，继而将原来的工作程序和磁盘上的数据自 动切换回修复完成的主机上。这个自动完成的恢复过程用户可 以预先设置，也可以设置为半自动或不恢复。,常用方法,双机双工热备份(MUTUAL BACKUP),两机同时运行，分不同作业，各自资源负载，故障、接管、修 复、交还。, ,双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联 双主机各自通过一条SCSI电缆线与RAID磁盘阵列相联 双主机各自运行不同的作业，彼此独立，并相互备援 主机A故障后，主机B自动接管主机A运行。 主机A的作业将在主机B上自动运行。 主机A修复后，主机B将把A的作业自动交还主机A。 主机B故障时，主机A接管主机B的作业和数据。 主机B修复时,主机A再将原来接管的作业和数据交还主机B 。,主从热备份 (MASTER/SLAVE),主从式（M/S），M运行，S后备，M故障，S接管并升级为M, 原M修复后作为S。, ,双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联。 双主机各自通过一条SCSI电缆线与RAID相联。 主机A为Master，主机B为Slave。 主机A处理作业和数据，主机B作为热备份机。 主机A故障后，主机B自动接管主机A的作业和数据。 主机B同时接管A的主机名(Host)及网络地址(IP)。 主机A的作业将在主机B上自动运行。 主机A的客户(client)可继续运行，无需重新登录。 主机B现为Master,主机A修复后作为Slave，作为热备份机。,热备份(HOT-STANDBY), ,M运行，S后备 M故障，S接管作M 原M修复，S归还M。,RULES OF HIGH AVAILABILITY, ,Prepare for failure Aim to ensure that no important data is lost Keep it simple, stupid (KISS) Complexity is the enemy of reliability Automate it Test your setup frequently!,高可用常用方法,主机硬件高可用, 硬件冗余（冷备/热备）, 主机冗余、电源冗余、网络环境冗余.,数据高可用, 基于共享数据存储的数据高可用, SAN、NAS、iScsi 、SAS, 基于数据库软件的数据复制冗余, MySQL Replication、Oracle Data Guard . 基于第三方（或自行设计）的数据复制冗余, Tungeten、DBMoto、MMM .,SHARE STORAGE,REPLICATION,REPLICATION,通过 MySQL 的 Replication，可以将一台 MySQL 中的数据完整 的同时复制到多台主机上面的 MySQL 数据库中，并且正常情况下 这种复制的延时并不是很长。当我们各台服务器上面都有同样的数 据之后，应用访问就不再只能到一台数据库主机上面读取数据了， 而是访问整个 MySQL 集群中的任何一台主机上面的数据库都可以 得到相同的数据。,整个复制过程实际上就是Slave从Master端获取该日志然后再在自 己身上完全顺序的执行日志中所记录的各种操作,REPLICATION 机制的实现原理, ,MySQL的 Replication 是一个异步的复制过程，从一个 MySQL instance（我们称之为 Master）复制到另一个 MySQL instance（我们称之 Slave）。在 Master 与 Slave 之 间的实现整个复制过程主要由三个线程来完成，其中两个线程 （SQL线程和IO线程）在 Slave 端，另外一个线程（IO线程） 在 Master 端。 首先必须打开 Master 端的Binary Log（mysql-bin.xxxxxx） 功能,MYSQL 复制的基本过程,1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置（或者,从最开始的日志）之后的日志内容；,2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO 线程根据 请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。 返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端 的 Binary Log 文件的名称以及在 Binary Log 中的位置；,3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的 Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候 能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容， 请发给我”,4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并 在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同 样的 Query，所以两端的数据是完全一样的。,复制实现级别,Row Level：Binary Log 中会记录成每一行数据被修改的形式，然后在 Slave 端 再对相同的数据进行修改。, ,优点：在 Row Level 模式下，Binary Log 中可以不记录执行的sql语句的上下 文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以 Row Level 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易 理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调 用和触发无法被正确复制的问题。 缺点：Row Level下，所有的执行的语句当记录到 Binary Log 中的时候，都将 以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条 update语句：UPDATE group_message SET group_id = 1 where group_id = 2， 执行之后，日志中记录的不是这条update语句所对应的事件（MySQL以事件的 形式来记录 Binary Log 日志），而是这条语句所更新的每一条记录的变化情况， 这样就记录成很多条记录被更新的很多个事件。自然，Binary Log 日志的量就 会很大。尤其是当执行ALTER TABLE 之类的语句的时候，产生的日志量是惊 人的。因为MySQL对于 ALTER TABLE 之类的 DDL 变更语句的处理方式是重 建整个表的所有数据，也就是说表中的每一条记录都需要变动，那么该表的每 一条记录都会被记录到日志中。,复制实现级别,Statement Level:每一条会修改数据的 Query 都会记录到 Master的 Binary Log 中。 Slave在复制的时候 SQL 线程会解析成和原来 Master 端执行过的相同的 Query 来再 次执行。, ,优点：Statement Level下的优点首先就是解决了Row Level下的缺点，不需要记 录每一行数据的变化，减少 Binary Log 日志量，节约了 IO 成本，提高了性能。 因为他只需要记录在Master上所执行的语句的细节，以及执行语句时候的上下文 的信息。 缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行， 那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息， 以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结 果。另外就是，由于Mysql现在发展比较快，很多的新功能不断的加入，使mysql 得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容 易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制 出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现， 比如：sleep()函数在有些版本中就不能真确复制，在存储过程中使用了 last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化，所以不会出现类似的问题。,常规复制架构(MASTER - SLAVES),对于数据实时性要求不是特 别 Critical 的应用，只需要 通过廉价的pc server来扩 展 Slave 的数量，将读压 力分散到多台 Slave 的机 器上面，即可通过分散单台 数据库服务器的读压力来解 决数据库端的读性能瓶颈,DUAL MASTER 复制架构 (MASTER - MASTER),1. 2. 3. 4. ,一些特定的场景下进行 Master 的切换 Slave 节点切换成 Master 来提 供写入的服务 Master 节点的数据就会和实际的 数据不一致 反转原 Master - Slave 关系，重 新搭建 Replication 环境 Dual Master 环境就是两个 MySQL Server 互相将对方作为 自己的 Master，自己作为对方的 Slave 来进行复制。这样，任何 一方所做的变更，都会通过复制 应用到另外一方的数据库中。,级联复制架构(MASTER - SLAVES - SLAVES .),有些应用场景中，可能读写压力差别比较大，读压力特别的大，一 个 Master 可能需要上10台甚至更多的 Slave 才能够支撑注读的压 力。复制就会消耗较多的资源，很容易造成复制的延时。,DUAL MASTER 与级联复制 结合架构(MASTER - MASTER - SLAVES),MMS同时解决 Master 因为所附属的 Slave 过多而成为瓶颈的问 题，及解决人工维护和出现异常需要切换后可能存在重新搭建 Replication 的问题。,CLUSTER,MYSQL CLUSTER SQL服务器节点 MySQL Cluster实际上是在无共享存储设备的情况下实现的一种完全分布 式数据库系统，其主要通过NDB Cluster（简称NDB）存储引擎来实现。 MySQL Cluster的环境由以下三部分组成：,SQL层的SQL服务器节点（后面简称为SQL节点），也就是我们常说 的MySQL Server。 主要负责实现一个数据库在存储层之上的所有事情，比如连接管理， Query 优化和响应，Cache 管理等等，只有存储层的工作交给了 NDB 数据节点去处理了。也就是说，在纯粹的MySQL Cluster环境 中的SQL节点，可以被认为是一个不需要提供任何存储引擎的 MySQL服务器，因为他的存储引擎有Cluster环境中的 NDB 节点来 担任。所以，SQL层各MySQL服务器的启动与普通的 MySQL Server 启动也有一定的区别，必须要添加ndbcluster参数选项才行。 我们可以添加在f配置文件中，也可以通过启动命令行来指定。,NDB 数据节点,Storage 层的 NDB 数据节点，也就是NDB Cluster。, ,最初 NDB 是一个内存式存储引擎，当然也会将数据持久化 到存储设备上。最新的 NDB Clus