分布式数据库总结

1、分布式数据库总结简介第一篇：分布式数据库总结分布式数据库系统及其应用复习大纲 第一章分布式数据库系统概述 1、理解分布式数据库系统的特点分布式数据库系统的定义： 分布式数据库系统，通俗地说，是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位（通常是集中是数据库系统）连接起来，共同组成一个统一的数据库系统。 分布式数据库系统的特点：物理分布性：数据不是存放在一个站点上逻辑整体性：是与分散式数据库系统的区别站点自治性：是与多处理机系统的区别数据分布透明性集中与自治相结合的控制机制存在适当的数据冗余度事务管理的分布性 2、能

2、够按照不同标准描述分布式数据库系统的分类 按局部数据库管理系统的数据模型分类：同构性（homogeneous）（分为同构同质型和 同构异质型）ddbs和异构性(heterogeneous)ddbs 按分布式数据库系统的全局控制系统类型分类：全局控制集中型ddbs，全局控制分散型ddbs，全局控制可变型ddbs。 3、理解分布式数据库中数据的独立性和分布透明性 所谓数据独立性是指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关心全局数据的分布情况，包括全局数据的逻辑分片情况、逻辑片段站点位置的分配情况，以及各站点上数据库的数据模型等。也就是说，全局数据的逻辑分片、片段的物理位置分配

3、，各站点数据库的数据模型等情况对用户和用户程序透明。所以，在分布式数据库中分布独立性也称为分布透明性。 分布透明性包括三个层次：分片透明性（完全分布透明性）：映像2 位置透明性（中级分布透明性）：映像3 局部数据模型透明性（低级分布透明性）：映像4 无分布透明性：异构数据 第二章分布式数据库系统设计 1、理解分布式数据库的设计目标 分布式数据库设计的目标1分布式数据库的本地性或近地性2控制数据的适当冗余3工作负荷分布4存储的能力和费用2、理解水平分片的定义、分类和应用水平分片是对全局关系执行“选择操作”，把具有相同性质的元组进行分组，构成若干个不相交的子集。水平分片的方法可归为初级分片和导出分

4、片两类。 初级分片：以关系自身的属性性质为基础，执行“选择”操作，将关系分为若干个不相交的片段。例子2.1 s（s#，sname, age, sex） define fragment s1 as select * from where sex=m define fragment s2 as select * from where sex=f 导出分片：全局关系的导出分片不是以其自身的属性性质为基础，而是从另一个关系的属性性质或水平片段推导出来的。采用导出分片可片可使片段与片段之间的“连接”变得更容易。 例2.3 设全局关系sc（，grade），s（s#，sname, age, sex）若要将划

5、分 为男生的各门课成绩和女生的各门课成绩，这就不可能从sc本身的属性性质来执行选择，必须从关系s的属性性质或水平片段来导出。 define fragment sc1 as select sc.s#,c#,grade from sc,s where sc.s#=s.s# and sex=m define fragment sc2 as select sc.s#,c#,grade from sc,s where sc.s#=s.s# and sex=f 如果s已经进行水平分片，分为sf和sm，分别为男生全体和女生全体，则上述的片段定义可以基于片段sf和导出：define fragment sc1

6、as select * from sc where s# in(select sf.s# from sf) define fragment sc2 as select * from sc where s# in(select sm.s# from sm) 3、理解垂直分片的定义和应用 一个全局关系的垂直分片是通过“投影”操作把它的属性分为若干组。确定一个全局关系r的垂直分片需要根据应用以“同样方式”（例如具有相同的使用频率）访问的属性来进行分组。 例2.4全局关系emp（e#，name，sal，tel，magnum，dept），主码为e#。主要应用有：集中在站点3上的管理性应用要求查询雇员的：

7、name，sal，tel；和从其他站点发出的应用要求查询雇员的：name，dept，magnum。 解：如果使用垂直分片：emp（e#，name，sal，tel）和emp（e#，magnum，dept） 则name属性只属于一个片段，对于上述的应用，必须进行连接操作和非本地访问。 如果使用垂直群集：emp（e#，name，sal，tel）和emp（e#，name，magnum，dept） 则对于上述应用，不需要执行连接操作，且可实现较好的本地性。 4、能够描述分片的基本原则 完备性原则：要把所有的数据映射到各个片断中 可重构原则：关系分片后的各个片断可重构整个关系 不相交原则：关系分片后的各个

8、片断不能重叠 5、掌握数据片断分配的分类和常用方法 分配的简化模型有：读代价、写代价、存储代价和目标函数。 常用方法：非冗余分配设计方法（包含最佳适应法和其他方法）和冗余分配的设计方法（包含所有得益站点法和附加复制法） 6、掌握最佳适应法和所有得益站点法的基本特点 最佳适应法是对每一种分配方式进行估算，然后选择最佳的站点。这种方法不考虑把一个片段与一个相关片段放在同一站点的“相互”影响。 特点：将片断ri分配到访问ri次数最多的那个站点上bij= kfkj*nki 所有得益站点法：首先确定非复制为题的解，然后在全部站点中确定一组站点，给这组站点中的每一个站点分配片断的一个副本，这样做所得到的好

9、处要比为此而付出的费用合算。 特点：将片断ri的副本分配到所有得益站点j上 bij= kfkj*rki -c*k jj fkj*uki 如果bij0，则站点j是得益站点，放置ri的一个副本 7、能够描述dataid-d方法设计分布式数据库的各个阶段 需求分析，概念设计，分布要求分析，全局逻辑设计，分布设计，局部逻辑设计，局部物理设计。逻辑设计分为全局逻辑设计和局部逻辑设计 8、能够根据给出的条件对关系进行具体分片，给出正确的限定关系 上边的例子。 第三章分布式数据库系统中的查询处理和优化1、掌握分布式数据库查询的分类 局部查询、远程查询和全局查询 2、理解关系代数运算的交换率 È1

10、(2 (r) =2 (1 (r) 条件:1 2 是 选择操作 时总成立，1 2 是 投影操作时要求其属性集合相等 1 与2 是投影和选择操作时:a1,an(f(r) =f (a1,an (r) 的条件是 f中的属性是 a1, . an 的子集。r s = s r r × s = s × r r s = s r r s = s r r s È s r r r 3、掌握直接连接优化算法的分类 利用站点依赖信息的算法，分片与复制算法，站点依赖和数据复制结合算法，hash划分算法 4、掌握半连接运算 见例子 5、掌握半连接和直接连接查询优化算法的区别 取决于数据传输和局部

11、处理的相对费用；如果传输费用是主要的，采用半连接；如果本地费用是主要的，采用直接连接, 6、理解hash划分算法的特点 数据传送量是r；索引方面, 比片段复制算法更低，每个站点的连接数据量同站点依赖 7、能够描述基于半连接算法查询优化的基本原理和步骤 基本原理是在传到另一个站点做连接前，消除与连接无关的数据，减少做连接操作的数据量，从而减小传输代价 步骤：计算每种半连接方案的代价，并从中选择一种最佳方案选择传输代价最小的站点，计算采用全连接的方案的代价比较两种方案，确定最优方案 8、能够描述基于关系代数等价变换的查询优化算法原理、算法实现步骤 原理：1查询问题关系代数表达式2分析得到查询树3进

12、行全局到片段的变换得到基于片段的查询树4利用关系代数等价变换规则的优化算法，尽可能先执行选择和投影操作 算法：1连接和合并尽可能上提（树根方向）2选择和投影操作尽可能下移（叶子方向） 实现步骤：转换一：1查询问题关系代数表达式。2转换二：关系代数表达式查询树。3转换三：全局查询树分拆成片段查询树。4优化：利用关系代数等价变换规则的优化算法，优化查询树，进而优化查询 9、能够根据提供的条件完成分片和复制算法应用，通过计算判断哪个关系保持分片最优 p88例3-6 考试 第四章分布式数据库中的事务管理和恢复 1、掌握事务的四大特性 原子性（atomicity）,一致性（consistency）,持久

13、性（durability）.隔离性（ isolation）2、能够描述两阶段提交协议的工作流程 两阶段提交协议的基本思想是：将本地原子性提交行为的效果扩展到分布式事务, 保证了分布式事务提交的原子性, 并在不损坏log的情况下, 实现快速故障恢复, 提高ddb系统的可靠性. 2pc把事务的提交过程分为两个阶段：第一阶段：表决阶段，目的是形成一个共同的决定 首先，协调者给所有参与者发送“准备”消息，进入等待状态 其次，参与者收到“准备”消息后，检查是否能够提交本地事务 如能，给协调者发送“建议提交”消息,进入就绪状态 如不能，给协调者发送“建议撤销”消息，可以单方面撤销 第三，协调者收到所有参与

14、者的消息后，他就做出是否提交事务的决定， 只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态 否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态 第二个阶段：执行阶段，实现表决阶段的决定，提交或者撤销 3、掌握事务故障的分类 分布是数据库的故障 分布是数据库的故障分为站点故障和通信故障。站点故障包括事务故障、系统故障和介质故障。 事务故障包括计算溢出。完整性被破坏、操作员干预、输入或输出出错等。 通信故障分为报文故障和网络分割故障。 4、掌握分布式数据库事务执行的控制模型的分类 分为三类：主从模型，三角模型，层次控制模型 5、理

15、解日志文件的特点 日志文件保存到磁盘上。日志 log：记录所有对db的操作 事务标识：每个事务给定一个具有惟一性的标识符 log记录项 : start_transaction, t write_item, t, x, 旧值, 新值 read_item, t, x commit, t abort, t 写动作：写log比写数据优先 log存储：一般存在盘上, 还会定期备份到磁带上 6、理解分布式数据库数据更新常见方法 多站点数据更新、主文本更新法、快照方法 7、理解故障恢复时检查点知识 检查点（checkpoint）：设置一个周期性（时间/容量）操作点 a) log buffer内容写入log数

16、据集 b) 写检查点log信息：当前活动事务表, 每个事务最近一次log记录在log文件中的位置 c) db buffer内容写入db d) 将本次检查点log项在log文件中的地址记入“重启动文件” 8、能够描述两阶段提交协议的特点：2pc协议的重要特点：1允许参与者单方面撤销事务 2一旦参与者确定了提交或撤销协议，它就不能再更改它的提议3当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态4协调者根据全局提交规则做出全局终止决定5协调者和参与者可能进入互相等待对方消息的状态，使用定时器，保证退出消息等待状态 第五章分布式数据库中的并发控制 1、理解封锁的基本准

17、则 1事务t在执行任何read_item（x）操作之前，必须先执行read_lock(x)或者write_lock(x)操作 2事务t在执行任何write_item（x）操作之前，必须先执行write_lock(x)操作 3如果事务t执行read_lock(x)操作,数据项x必须没有加锁或者已经加了读锁，否则事务t的这个操作不能进行 4如果事务t执行write_lock(x)操作,数据项x必须没有加锁，否则事务t的这个操作不能进行 5事务t在完成所有read_item（x）和write_item（x）操作之后，必须执行unlock(x)操作6如果事务t已经持有数据项x上的一个读锁或者一个写锁，

18、那么它不能再执行read_lock(x)操作 7如果事务t已经持有数据项x上的一个读锁或者一个写锁，那么它不能再执行write_lock(x)操作 8如果事务t没有持有数据项x上的一个读锁或者一个写锁，那么它不能执行unlock(x)操作 2、理解基于时标的并发控制方法 并发控制方法包含全局时标和局部时标 3、掌握死锁检测的方法分类 局部死锁：仅在一个站点上发生的死锁 全局死锁：涉及多个站点的死锁(即等待圈由多个站点组成) 4、理解一致性调度和可串行化调度的特点 一致性调度：调度可以使得数据库从一个一致性状态转变为另一个一致性状态，则称调度为一致性调度 可串行化调度：如果一个调度等价于某个串行

19、调度，则该调度称为可串行化调度。 也就是说，该调度可以通过一系列非冲突动作的交换操作使其成为串行调度 5、能够描述死锁发生的四个必要条件：会考试 互斥条件：事务请求对资源的独占控制 等待条件：事务已持有分配给它的资源, 又去申请并等待别的资源 非抢占条件：直到资源被持有它的事务释放前, 不可能将资源强制从持有它的事务夺去 循环等待条件：存在事务互相等待的等待圈 6、能够列举并发控制算法 悲观并发控制法和乐观并发控制法 悲观并发控制法有基于封锁的算法、基于时标排序的算法和混合算法。乐观的方法也可分为基于封锁或基于时标排序的算法。 第六章分布式数据库中的可靠性 1、理解可靠性和可用性的含义与关系

20、可靠性：指数据库在一给定时间间隔内不产生任何失败的概率。它强调数据库的正确性，要求数据库正确运行。通常用来描述不可修复的系统。 可用性：强调的是当需要访问数据库时，它是可用的。指在给定的时间点系统可以正常运行的概率。通常用于描述那些可以修复的系统。 两者关系：通常认为构建可用性的系统比可靠性的系统容易。两者是统一的，可靠性高的系统可用性自然是好的。 两者又是矛盾的，增加错误风险的情况下，可提高可用性;采用太谨慎的策略会降低可用性 2、理解两阶段提交协议如何转为三阶段提交协议 2pc中的状态： c(提交)状态是可提交状态, 其它为不可提交状态。ready 状态是不可提交状态。wait状态是不可提

21、交状态。它们都侵犯了非阻断协议的充要条件, 从而考虑改变2pc, 使其满足非阻断协议条件。在wait 和 commit 之间, 或者在ready和commit之间加入另一种状态作为缓冲状态, 从而有了3pc协议 3、掌握分布式可靠性协议的组成。简答 可靠性协议组成 ：包括提交、终结、恢复协议。提交和恢复协议详细说明提交命令和恢复命令是如何执行的。终结协议是分布式系统特有的协议。在执行一个分布式事务时，若一个site故障，希望其它site也停止该事务。处理这种情况的技术就称为终止协议。 4、理解发生网络分割时冗余分布式数据库和非冗余数据库采用的处理协议 非冗余数据库：任何需要访问存储在另一网络区

22、域里的数据项的新事务都被阻断, 等待网络修复。位于同一区域里的数据项的并发访问由并发控制算法处理。网络分割时由提交协议处理 冗余数据库：分割时, 副本可能位于不同的区域。由复制协议处理 5、能够描述三阶段提交协议中事务协调者和参与者的状态转换 p188页图6.4 考试 6、能够采用版本号法进行不一致性检测，并且应用于实际。大题 需要首先发现哪些数据部分已经不一致（不一致性检测） 然后根据发生的情况，给这些部分赋予一个最合理的值（不一致性的解法） 检测方法：采用版本号 p200页例子 第七章分布式数据库的安全性与目录管理1、理解分布式数据库的动态授权语句的形式 1用户对自己生成的关系拥有全权,

23、通过授权和收权语句完成对数据开放, 保密的存取权授予(grant, revoke)。授权语句授权语句：granttowith grant option 2访问表(at)法 2、理解数据库的安全性含义 数据库安全性包括两个方面的内容：数据库数据的保密性和安全性。 第二篇：分布式oa系统的数据库同步复制技术分布式oa系统的数据库同步复制技术 一、背景概述 随着政府上网、电子政务的不断普及和深入，ibm公司的lotus domino系统在国内得到广泛的应用。其中不乏大型的、跨地域的企事业单位或集团公司应用案例。这些案例一般采用分布式系统结构，即分布在全国各地的分支机构分别设有独立的数据库服务器，各地

24、数据库服务器采用数据库同步复制的方式更新本地数据库复本内容。从而使得各地终端用户及时、快捷、可靠地访问到最新公告、新闻等。 本文结合呼和浩特铁路局客运公司办公自动化系统案例讨论基于ibm公司的lotus domino技术构建的分布式oa系统中数据库之间的同步复制技术。 二、几个概念 ibm公司的lotus产品包含lotus domino server ，lotus notes，lotus domino administrator和lotus domino designer。lotus domino server为后台数据库平台，lotus notes为客户端，lotus domino admi

25、nistrator为系统管理平台，lotus domino designer设计开发工具。先介绍几个domino中和同步复制有关的概念。1、复制 notes允许在多个服务器或工作站上保存数据库的多个拷贝，这些拷贝称做“复本”。它们使各个地方的不同网络上的用户共享相同的信息。复本与文件的拷贝不同之处在于在复制时源文件与其复本具有相同的复本标识符。 复制是在复本之间共享更改信息的过程。复制时，notes通过把更改信息从一个复本拷贝到另一个复本来更新复本。最终，notes 使所有复本保持一致。可以选择在复本拷贝之间进行复制，这时两个复本都发送并接收更新信息，或者选择仅从一个复本复制到另一个复本。 也

26、可以定期安排复制，或者根据需要手动进行复制。复制可以在两台服务器之间或者在服务器和工作站之间进行。如果设定为定期进行完整复制，那么 notes会根据时间使所有复本保持同步。 2、复本标识符 复本与源文件或数据库有相同的复本标识符。这是数据库的复本与拷贝的区别所在，因为有共同的标识符才能使复本与源数据库之间可以复制更改信息。如果数据库的两个拷贝具有不同的复本标识符，则不能在它们之间进行复制。 3、复制冲突和保存冲突 在复制之间，如果有两个或多个用户对相同文档的不同复本进行了编辑，就会导致复制冲突。而保存冲突则是在两个或多个用户同时编辑服务器上同一个数据库的同一个文档时发生。当发生复制冲突或保存冲

27、突时，notes 将在视图页面左边把发生冲突的文档标注出来。 notes对复制冲突的处理是这样的，在两个或多个用户编辑并保存同一个文档之后，下次进行复制时，notes 将编辑和保存最频繁的文档指定为主文档，而将其他文档显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。如果用户在一个复本中编辑并保存了某文档，然后另一个用户将该文档删除，则认为该文档是被删除的。然而，如果文档被编辑和保存了多次，或者在该文档被删除之后又被另一个用户编辑和保存过，则把编辑过的文档作为主文档。 note对保存冲突的处理如下，当多个用户同时打开相同的文档进行编辑时，notes指定最先保存的文档为主文档。当另

28、一个用户试图保存同一文档时，notes 就会提示该用户把它作为“保存冲突”文档来保存。如果用户这样做了，那么 notes 将它显示为主文档的答复文档，并在视图页面左边用一个菱形符号标注出来。 根据笔者的经验，在实际开发过程中，我们应该通过设计控制保存冲突，避免文档产生“保存冲突”的答复文档。对于复制冲突可以设置数据库合并复制冲突，这样如果产生增量改动，服务器在复制过程中会自动合并冲突。需要说明的是，notes在进行复制时，并不是传统意义上的完全拷贝，而是一系列的规则进行增量的合并。 4、复制类型 domino中支持四种不同的复制方式 拉入推出：是一个双向过程。此过程进行时，呼叫服务器从响应服务

29、器拉入更新，然后向响应服务器推出自己的更新。使用“拉入推出”时，呼叫服务器上的 replicator 任务执行所有的工作。拉入推出是系统缺省的复制方式。 分别拉入：是两个服务器交换更新的双向过程。使用“分别拉入”时，两个复制器（一个在呼叫服务器上，另一个在响应服务器上）共同进行复制工作。 只推出：是呼叫服务器向响应服务器推出更新的单向过程。单向复制总是比双向复制耗时少。 只拉入：是呼叫服务器从响应服务器拉入更新的单向过程。单向复制总是比双向复制耗时少。 三、案例 笔者曾经参与呼和浩特铁路局客运公司办公自动化系统的设计、开发和实施工作。呼和浩特铁路局客运公司包括三个信息中心，分别在呼和浩特市、包

30、头市和东河区三个地方，三地之间通过64k的ddn专线连接。因为带宽的限制，用户远程访问速度成为本系统的瓶颈，经过再三论证，我们决定构建分布式数据库存储架构，采用后台数据库实时同步复制技术使三个异地服务器内容一致，将远程访问转化为本地访问，从而提高终端用户访问速度。 详细步骤如下。 1、安装服务器 在三地信息中心分别安装domino服务器，服务器的详细配置并不复杂，读者可以参阅相关资料，一般情况下按照安装配置向导四步就可以快捷配置完毕。注意三台domino服务器不要同名，其简单拓扑结构如下： 图中呼市处于相对中心的位置，所以呼市和包头之间，呼市和东河之间分别建立了互推复制机制，为了降低网络负担和

31、流通环节，没有建立包头和东河之间的复制，各地直接通过与呼市同步来保持三地数据的一致。一般而言，如果各分支机构处于平等位置，互相之间的数据流量相当，也可以两两之间建立复制机制。 2、建立服务器之间的连接 对于两个服务器之间进行的复制，应创建一个“连接”文档来指定进行信息交换的方式和时间。“连接”文档存储在“domino 目录”中。一次仅使用一个“连接”文档来处理每对服务器之间的所有复制。创建不必要的“连接”文档会增加网络传输量和阻塞。 缺省情况下，邮件路由和复制都已被启用，但是可以更改此设置并使用单独的“连接”文档来安排每项任务。这样，就可以分别控制复制和邮件路由的特定时间、时间范围或重复间隔，

32、并根据需要增加或减小这些设置。 怎么保证服务器之间的连接能顺利的连通？实际上对于物理连接形式domino并不关心，也就是说物理上无论通过什么连接方式，专线、光纤、x.25、电话拨号等，只要tcp/ip通，简单说只要能ping通，就能够保证服务器之间顺利连接。 下面给出了建立服务器之间连接的操作步骤和主要参数的设置说明： a）在 domino administrator 中单击“配置”附签。 b）在“使用目录”域中选择连接服务器的“domino 目录”。 c）单击“服务器”，然后单击“连接”。 d）单击“添加连接”。 f）关键域配置描述：域输入 源服务器连接服务器的名称 使用以下端口连接服务器或

33、源服务器使用的网络端口（或协议）名称 使用优先级选择一个：“一般”（缺省）“低” 目标服务器响应服务器的名称 可选网络地址与所选协议相适应的目标服务器的地址。对于 tcp/ip，应使用完全有效的网络域名称（首选）或 ip 地址（例如：hr-e.a 或者 192.22.256.36）。 对 tcp/ip 或其他需要特定网络地址的协议，建议填写此域。 复制类型缺省情况下，domino 的复制方向为“拉入推出”。但根据实际情况，为了平衡服务器之间的负载，充分发挥每个服务器的性能，我们可以设定双方互推或者互拉，本例中我们采用服务器双方互推的方式，即每个服务器上的连接复制类型都是由源服务器向目标服务器推

34、出。 复制文件/目录如果为空，则服务器将data目录下的所有存在复本的数据库全部进行复制，否则填写哪个库系统就复制哪个库。 安排在安排中可以设置连接时间、重复间隔、每周复制日期等参数。可根据实际情况设定，本例设置为每日8：00到晚上10：00连接，连接期间每一小时进行同步复制或服务器依据增量自动复制，非连接时间服务器处理其他性能调优动作，如更新数据库索引等。 h）保存文档。 3、建立数据库复本 连接建立成功以后，保证服务器之间可以进行通讯了，下一步就是对要进行同步的数据库建立复本，当建立了复本以后，通过连接设定就能保证异地各个复本之间的数据完全一致。 这里需要说明的是，我们在第一台服务器上建立

35、了一套数据库系统，对于需要同步复制的所有数据库，在其他服务器上只需要产生他们的复本，而不能再在每台服务器上分别创建相同的数据库。在本例中我们在呼市客运公司信息中心安装配置好第一台服务器后，在包头信息中心和东河信息中心的domino服务器上则通过呼市信息中心服务器建立各自本地所有需要的数据库复本。 如果要在本地domino服务器上创建源domino服务器的复本数据库，需要本地服务器的系统管理员具有对源服务器访问和创建复本的权限，因为domino对权限控制很严格，尤其是多域用户之间的访问，其目的就是为了充分保证系统的安全性。那么怎样才能具有这样的创建复本的权限呢？需要具有两个基本的存取权限就可以在

36、本服务器上创建源服务器的数据库复本，一是源服务器配置中允许本地服务器的系统管理员访问，二是允许本地服务器的系统管理员创建数据库复本，这两个权限由源数据库的系统管理员设置给目标数据库的系统管理员。结合本例，需要在包头信息中心的服务器上建立呼市信息中心的数据库复本，则首先在呼市信息中心的服务器上配置“当前服务器”文档。 a ）在 domino administrator 中单击“当前服务器”文档。 b）单击“编辑服务器” c）选择“安全”标签页，填写以下两项：域输入 访问服务器本例为包头信息中心系统服务器名称及管理员的用户名称 创建数据库复本同样是包头信息中心系统管理员的用户名称 d保存后退出。

37、接下来就可以在包头信息中心的服务器上创建源数据库的复本了，这步动作比较简单，选择源数据库，从菜单中执行创建复本功能即可，这里不在详细描述。 同样的处理在东河的服务器上如法炮制一遍，则所有数据库复本成功建立完毕。 4、复制测试 完成以上三步，配置就全部完成，接下来就要测试一下配置是否完全成功以及配置是否生效。我们测试主要包括两个内容：一是测试连接是否成功，能否进行复制动作。二是测试设置的复制安排是否按照预定生效。 a）进行第一项测试的办法是在domino的控制台上，使用domino的系统命令，进行数据库的推、拉测试，检查复制是否能成功进行，命令格式如下： 拉入复制 语法：pull servern

38、ame databasename 描述：强制从指定服务器到本地服务器进行单向复制。通过在命令行中包括单个数据库名称，将其从特定服务器单向复制到本地服务器。发起复制的服务器从指定的服务器接受数据，但不能申请将自己的数据复制到其他服务器上。该命令重设在“domino 目录”中预定的任何复制，而强制一台服务器与发起复制的服务器立即进行复制。如果可能，请输入服务器完整的层次结构名称。 推出复制 语法：push servername databasename 描述：强制进行从本地服务器到指定服务器的单向复制。也可以通过在命令行中包括要复制的单个数据库名称，来将其从本地服务器单向复制到特定服务器。发起复制

39、的服务器将数据发送到指定的服务器，但不申请获得数据。该命令可以重设在“domino 目录”中预定的任何复制，而强制一台服务器立即与发起复制的服务器进行复制。如果可能的话，请指定服务器完整的层次结构名称。 b）第二项测试通过将连接文档的安排时间设置为两分钟进行一次，同时观察domino的系统控制台，查看服务器的动作，以确保安排设定生效。正确的结果是从控制台上能看到系统报告复制过程。 按照以上实例说明进行，没有任何问题。 四、结束语 我们同样可以在客户端利用复制技术，例如在本地客户端建立邮件文件数据库的复本，以便与我们在外出或者脱机状态下还可以访问邮件文件。本地复本要求没有在服务器之间进行复制的要

40、求那么高，本地复本的作用体现在通过本地复本，可以在没有通过网络连接服务器时对数据库进行操作。当设置 notes 为远程工作站时，就可以通过调制解调器呼叫服务器并在本地复本和服务器数据库之间交换更新信息。 第三篇：从google spanner漫谈分布式存储与数据库技术从google spanner漫谈分布式存储与数据库技术 文/曹伟 spanner 的设计反映了 google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 megastore 的数据模型，chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 bigtable 中的技术。新颖之处在于，它使用高精度和可观测误差

41、的本地时钟来判断分布式系统中事件的先后顺序。spanner 代表了分布式数据库领域的新趋势newsql。 spanner 是 google 最近公开的新一代分布式数据库，它既具有 nosql 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 sql 的查询语言、支持表连接、支持事务（包括分布式事务）。spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 spanner 集群可以扩展到上百个数据中心、百万台服务器和上t条数据库记录的规模。目前，google 广告业务的后台（f1）已从 mysql 分库分表方案迁移到了 spanner 上。 数据模型 传统的

42、 rdbms（例如 mysql）采用关系模型，有丰富的功能，支持 sql 查询语句。而 nosql 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。spanner 继承了 megastore 的设计，数据模型介于 rdbms 和 nosql 之间，提供树形、层次化的数据库 schema，一方面支持类 sql 的查询语言，提供表连接等关系数据库的特性，功能上类似于 rdbms；另一方面整个数据库中的所有记录都存储在同一个 key-value 大表中，实现上类似于 bigtable，具有 nosql 系统的可扩展性。 在 spanner 中，应

43、用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表用户表（users）和相册表（albums），并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录（一个用户）对应着相册表中的多条记录（多个相册）。此外，要求子节点的主键必须以父节点的主键作为前缀。例如，用户表的主键（用户 id）就是相册表主键（用户 id+ 相册 id）的前缀。 图 1 schema 示例，表之间的层次关系，记录排序后交错的存储 显然所有表的主键都将根节点的主键作为前缀，spanner 将根节点表中的一条记录，和以其主键作为前缀的其他表中的所有记录的

44、集合称作一个 directory。例如，一个用户的记录及该用户所有相册的记录组成了一个 directory。directory 是 spanner 中对数据进行分区、 复制和迁移的基本单位，应用可以指定一个 directory 有多少个副本，分别存放在哪些机房中，例如把用户的 directory 存放在这个用户所在地区附近的几个机房中。 这样的数据模型具有以下好处。 · 一个 directory 中所有记录的主键都具有相同前缀。在存储到底层 key-value 大表时，会被分配到相邻的位置。如果数据量不是非常大，会位于同一个节点上，这不仅提高了数据访问的局部性，也保证了在一个 dir

45、ectory 中发生的事务都是单机的。 · directory 还实现了从细粒度上对数据进行分区。整个数据库被划分为百万个甚至更多个 directory，每个 directory 可以定义自己的复制策略。这种 directory-based 的数据分区方式比 mysql 分库分表时 table-based 的粒度要细，而比 yahoo!的 pnuts 系统中 row-based 的粒度要粗。 · directory 提供了高效的表连接运算方式。在一个 directory 中，多张表上的记录按主键排序，交错（interleaved）地存储在一起，因此进行表连接运算时无需排序即

46、可在表间直接进行归并。 复制和一致性 spanner 使用 paxos 协议在多个副本间同步 redo 日志，从而保证数据在多个副本上是一致的。google 的工程师钟情于 paxos 协议，chubby、megastore 和 spanner 等一系列产品都是在 paxos 协议的基础上实现一致性的。 paxos 的基本协议很简单。协议中有三个角色：proposer、acceptor 和 learner，learner 和 proposer 分别是读者和写者，acceptor 相当于存储节点。整个协议描述的是，当系统中有多个 proposer 和 acceptor 时，每次 proposer

47、 写一个变量就会启动一轮决议过程（paxos instance），如图 2 所示。决议过程可以保证即使多个 proposer 同时写，结果也不会在 acceptor 节点上不一致。确切地说，一旦某个 proposer 提交的值被大多数 acceptor 接受，那么这个值就被选中，在整轮决议的过程中该变量就不会再被修改为其他值。如果另一个 proposer 要写入其他值，必须启动下一轮决议过程，而决议过程之间是串行（serializable）的。 图 2 paxos 协议正常执行流程 一轮决议过程分为两个阶段，即 prepare 阶段和 accept 阶段。 · 第一阶段a：propo

48、ser 向所有 acceptor 节点广播 prepare 消息，消息中只包含一个序号n。proposer 需要保证这个序号在这轮决议过程中是全局唯一的（这很容易做到，假如系统中有两个 proposer，那么一个 proposer 使用1，3，5，7，9，另一个 proposer 则使用0，2，4，6，8，）。 ·第一阶段b：acceptor 接收到 prepare 消息后，如果n是到目前为止见过的最大序号，就返回一个 promise 消息，承诺不会接受序号小于n的请求；如果已接受过其他 proposer 提交的值，则会将这个值连同提交这个值的请求的序号一同返回。 · 第二

49、阶段a：当 proposer 从大多数 acceptor 节点收到了 promise 消息后，就可以选择接下来要向 acceptor 提交的值了。一般情况下，当然选原本打算写入的值，但如果从收到的 promise 消息中发现已经有其他值被 acceptor 接受了，那么为了避免造成数据不一致的风险，这时 proposer 就必须“大义灭亲”，放弃自己打算写入的值，从其他 proposer 提交的序号中选择一个最大的值。接下来 proposer 向所有的 acceptor 节点发送 accept 包，其中包含在第一阶段中挑选的序号n和刚才选择的值v。 ·第二阶段b：acceptor 收

50、到 accept 包之后，如果n的大小不违反对其他 proposer 的承诺，就接受这个请求，记录下值v和序号n，返回一个 ack 消息。反之，则返回一个 reject 消息。 如果 proposer 从大多数 acceptor 节点收到了 ack 消息，说明写操作成功。而如果在写操作过程中失败，proposer 可以增大序号，重新执行第一阶段。 基本的 paxos 协议可以保证值一旦被选出后就一定不会改变，但不能保证一定会选出值来。换句话说，这个投票算法不一定收敛。有两个方法可以加速收敛的过程：一个是在出现冲突后通过随机延迟把机会让给其他 proposer，另一个是尽量让系统中只有一个 pr

51、oposer 去提交。在 chubby 和 spanner 系统中这两种方法都用上了，先用随机延迟的方法通过一轮 paxos 协议，在多个 proposer 中选举出一个 leader 节点。接下来所有的写操作都通过这个 leader 节点，而 leader 节点一般还是比较“长寿”的，在广域网环境下平均“任期”可以达到一天以上。而 megastore 系统中没有很好地解决这个问题，所有的 proposer 都可以发起写操作，这是 megastore 写入性能不高的原因之一。 基本的 paxos 协议还存在性能上的问题，一轮决议过程通常需要进行两个回合通信，而一次跨机房通信的代价为几十到一百毫

52、秒不等，因此两个回合的通信就有点开销过高了。不过幸运的是，绝大多数情况下，paxos 协议可以优化到仅需一个回合通信。决议过程的第一阶段是不需要指定值的，因此可以把 prepare/promise 的过程捎带在上一轮决议中完成，或者更进一步，在执行一轮决议的过程中隐式地涵盖接下来一轮或者几轮决议的第一阶段。这样，当一轮决议完成之后，其他决议的第一阶段也已经完成了。如此看来，只要 leader 不发生更替，paxos 协议就可以在一个回合内完成。为了支持实际的业务，paxos 协议还需要支持并发，多轮决议过程可以并发执行，而代价是故障恢复会更加复杂。 因为 leader 节点上有最新的数据，而在

53、其他节点上为了获取最新的数据来执行 paxos 协议的第一阶段，需要一个回合的通信代价。因此，chubby 中的读写操作，以及 spanner 中的读写事务都仅在 leader 节点上执行。而为了提高读操作的性能，减轻 leader 节点的负载，spanner 还提供了只读事务和本地读。只读事务只在 leader 节点上获取时间戳信息，再用这个时间戳在其他节点上执行读操作；而本地读则读取节点上最新版本的数据。 与 chubby、 spanner 这种读写以 leader 节点为中心的设计相比，megastore 体现了一定的“去中心化”设计。每个客户端都可以发起 paxos 写操作， 而读操作

54、则尽可能在本地执行。如果客户端发现本地数据不是最新的，会启动 catchup 流程更新数据，再执行本地读操作返回给客户端。 最后，对比下其他系统中 replication 的实现。在 bigtable 系统中每个 tablet 服务器是没有副本的，完全依赖底层 gfs 把数据存到多台机器上。数据的读写都通过单个 tablet 服务器，在 tablet 服务器出现故障的时需要 master 服务器将 tablet 指派到其他 tablet 服务器上才能恢复可用。dynamo 系统则贯彻了“去中心化”的思想，将数据保存在多个副本上，每个副本都可以写入（update everywhere）。而不同副

55、本同时写入的数据可能会存在不一致，则需要使用版本向量（version vector）记录不同的值和时间戳，由应用去解释或合并不一致的数据。尽管 dynamo 系统还提供了 nwr 的方式来支持有一致性保证的读写操作，但总的来说 dynamo 为了高可用性牺牲了一致性。zookeeper、mongodb 与 chubby、spanner 类似，通过 leader 选举协议从多个副本中选择一个 leader，所有写操作都在经过 leader 节点序列化后，同步到其他副本上。zookeeper 则是在写入大多数节点后返回，而 mongodb 主要采用异步的主从复制方式。 分布式事务 spanner

56、系统中的分布式事务通过两阶段提交协议（2pc）实现。2pc 是一类特殊的一致性协议，假设一个分布式事务涉及了多个数据节点，2pc 可以保证在这些节点上的操作要么全部提交，要么全部失败，从而保证了整个分布式事务的原子性（acid 里的a）。协议中包含两个角色：协调者（coordinator）和参与者（participant/cohort）。协调者是分布式事务的发起者，而参与者是参与了事务的数据节点。在协议最基本的形式中，系统中有一个协调者和多个参与者。 顾名思义，2pc 也包含两个阶段，即投票阶段和提交阶段（如图 3 所示）。 图 3 两阶段提交协议 · 在第一阶段，协调者向所有的参与

57、者发送投票请求，每个参与者决定是否要提交事务。如果打算提交的话需要写好 redo、undo 等日志，并向协调者回复 yes 或 no。 · 在第二阶段，协调者收到所有参与者的回复，如果都是 yes，那么决定提交这个事务，写好日志后向所有参与者广播提交事务的通知。反之，则中止事务并且通知所有参与者。参与者收到提交/中止事务的命令后，执行相应操作，如果提交的话还需要写日志。 协议过程包括两回合的通信，在协调者和参与者端需要多次写日志，而且整个过程中所有参与者都占有读锁、写锁，可见 2pc 开销不菲。 2pc 最令人诟病之处还不在于性能，而是在有些故障条件下，会造成所有参与者占有读锁、写锁

58、堵塞在第二阶段，需要人工干预才能继续，存在严重的可用性隐患。假设故障发生在第二阶段，协调者在做出决定后，通知完一个参与者就宕机了，更糟糕的是被通知的这位参与者在执行完“上级指示”之后也宕机了，这时对其他参与者来说，就必须堵塞在那里等待结果。 spanner 利用基于 paxos 协议的复制技术，改善了 2pc 的可用性问题。2pc 协议过程中的协调者和参与者生成的日志都会利用 paxos 协议复制到所有副本中，这样无论是协调者或参与者宕机，都会有其他副本代替它们，完成 2pc 过程而不至于堵塞。在 paxos 协议上实现 2pc 这一思路很巧妙，paxos 协议保证了大多数节点在线情况下的可用

59、性，而 2pc 保证了分布式协议的一致性。 事件的顺序 传统上，在设计一个分布式系统时，都会假设每个节点的运行速度和时钟的快慢各不相同的情况，并且在节点之间进行同步的唯一方法就是异步通信。系统中的每个节点都扮演着观察者的角色，并从其他节点接收事件发生的通知。判断系统中两个事件的先后顺序主要依靠分析它们的因果关系，包括 lamport 时钟、向量时钟等算法，而这一切都存在通信开销。 因此，spanner 提出了一种新的思路，在不进行通信的情况下，利用高精度和可观测误差的本地时钟 （truetime api）给事件打上时间戳，并且以此比较分布式系统中两个事件的先后顺序。利用这个方法，spanner 实现了事务之间的外部一致性（external consistency）（如图 4 所示），也就是说，一个事务结束后另一个事务才开始，spanner 可以保证第一个事务的时间戳比第二个事务的时间戳要早，从而两个事务被串行化后也一定能保持正确的顺序。 图 4 事务外部一致性的实现 truetime api 是一个提供本地时间的接口，但