资料库 保护您的数据库:高需求数据的高可用性

保护您的数据库:高需求数据的高可用性

Anonim

通过Techopedia Staff,2016年12月7日

要点:主持人Eric Kavanagh与Robin Bloor,Dez Blanchfield和IDERA的Bert Scalzo讨论了可用性。

您目前尚未登录。请登录或注册以观看视频。

埃里克·卡瓦纳(Eric Kavanagh):女士们,先生们,您好,欢迎再次光临。 现在是星期三的东部时间四点,这些天,如果您处于数据世界中,可能只意味着一件事:现在又是Hot Technologies的时刻了! 确实是的。

我叫Eric Kavanagh,我将主持你的表演。 它的目的是弄清楚什么是热门,正在发生的事情,在企业中使用的最酷的东西,当然,数据库是我们在整个领域中所做的一切的基础。 因此,我们将讨论保护您的数据库。 确切的主题是“保护数据库:高需求数据的高可用性”。因此,确实有一张关于您的幻灯片。 而且,关于我的足够多的信息,请在Twitter上@eric_kavanagh打我。

首先,今年很热,数据很热,大数据很热,但实际上仍然处于边缘。 如今,越来越多的尖端公司正在利用大数据,世界上大多数面包和黄油组织仍在使用传统数据,如果您的数据需求量很大,那么您要确保其可用,因为当系统崩溃,无法访问数据时,即客户不满意,前景不满意,客户流失,各种事物,合作伙伴等都不满意,因此,您就不想要那样。

我们将向当今最好的企业学习-我们将听取我们自己的Robin Bloor博士的声音,他是运行了大约三十年的数据库专家。 Dez Blanchfield从事这项工作已有很长的时间了,但是他从很小的时候就开始了,而IDERA的Bert Scalzo确实是数据库黑带。 亲爱的,所以不要退缩–向您提出宝贵的问题是,当您提出好的问题并获得好的答案时,请通过聊天窗口或控制台的问与答组件将其发送给您。

然后,我将其交给Robin Bloor –拿走。

Robin Bloor博士:好的,让我单击此按钮,看看它是否在移动–它确实在移动。 我不会特别谈论数据库。 我以为您知道,因为我正在做介绍性的首次介绍演示,所以我将讨论预期的服务水平以及当然的可用性,这是交易,这是今天节目的主题。

问题是,您知道:“真的,可用性是什么? 我注意到的一件事–我实际上是在90年代的某个时候注意到的–我在一个站点上工作,用户开始抱怨,因为他们的电子邮件因15分钟。

这很有趣,因为CTO或负责IT的人员实际上是那几天他们实际确定服务水平并且电子邮件停止发送15分钟的几个地方之一,没有违反任何人的服务水平。 实际上,我认为它可以放两个小时。 这不是无法使用电子邮件,而是因为服务器已关闭而无法发送和接收。 从那时起,我注意到我一直在前进,这一切都在加速,用户的期望也在提高,这使我警觉到人们可能拥有三种服务水平的情况,但通常他们会当实际上没有违反服务水平时,将开始抱怨。

因此,对服务级别的定义只是为了给出一个-好的,它可以完全取决于您在服务级别方面所谈论的内容。 我们已经讨论过IT系统或IT应用程序。 通常根据性能,可用性和度量标准进行定义-换句话说,除非可以衡量,否则您无法真正定义服务级别,因此通常涉及某种度量,并且通常涉及响应时间,特定事务和服务级别。在特定时间段内以及大约1994–1995年之前,系统的可用性非常罕见,几乎没有任何系统要求其正常工作时间以上可用。 因此,假设从早上八点到晚上六点,要进行正常的跨度,人们就可以构建系统,也就是说,在我看来,尤其是对于数据库,您可以按照特定的方式配置数据库批处理窗口开始缩小,在某些系统中然后再在其他系统中又出现了重新思考的需求,然后我们出现了服务或体系结构,这开始使以前不依赖的系统之间产生依赖彼此,使一切变得更糟。 就系统的可用性而言,我们受到了挤压。

我要说的是关于可用性的问题,它包括备份和恢复,还包括–就像不仅仅是我们在谈论的正常术语中的可用性; 应用程序可能会以多种不同方式失败。 您知道,您可能会遇到硬件故障,也可能会导致数据库故障,您可能会遇到软件故障,并且这些负载中有不同种类的负载,发生这种情况时,您需要能够恢复,因此还需要恢复系统。 因此,需要某种备份系统的方案,并且在当今的许多站点上,您还需要灾难恢复功能,以防整个建筑物被炸毁。 值得一提的是,我将在一分钟内对此进行细微介绍,但是业务流程也具有服务级别,实际上,业务流程的服务级别对业务确实很重要。 IT只是必须按照协议达成协议。

IT服务级别通常是业务流程服务级别的辅助,但是正如15年前对于任何组织而言,拥有明确定义的服务级别的确非常罕见,对于组织而言,对于业务流程拥有明确定义的服务级别仍然非常罕见。 那就是现在正在发生的事情。 这已经不是很长时间了。

这是加速和时间障碍,值得一提的是时间障碍。 我们逐渐进入一个事件处理世界,因此我们逐渐进入一个实时世界,因此我们逐渐转变为可用性,要求24乘7,这对于许多系统来说实际上是困难的–很难实现。 它要么非常昂贵,要么在某些情况下您可能实际上不得不更改系统,甚至移至其他数据库,我们正在使用的另一版本的数据库软件。

同样,这些时间障碍–我总是喜欢在有机会的时候提及这些–这些都是我们的应用程序遇到的时间障碍。 应用程序可能希望尽可能快,那就是软件与软件对话。 在某些情况下,实际上并没有任何可接受的许可证,您想要尽可能快,并且在商业条件下(例如市场情况),与第二次购买订单一起提供的人得到的价格比某人差谁在第一位,所以软件速度确实很重要。

但是,您知道,在与人打交道时,真正需要的最佳响应时间是十分之一秒,因为这与人的响应时间有关。 您不需要走得更快,因为人类无论如何也不会注意到。 人类通常可以忍受的等待时间为1.1到4秒钟,但是一旦您超过大约4秒钟,他们就会停止执行其他操作,因此您真的进入了批处理活动。

因此,您可以看到在某些时间范围内以及某些时间段,某天,某几周和某几个月内发生批处理行为的事情,因此您不在事件处理世界中,因此可用性在需求方面可能实际上有很大不同能够提供。 但是,一旦您进入活动世界,那么您就处于24/7全天候可用状态,随着技术的发展越来越快,技术变化是一个因素,那么可用性可能不会增加。 它只是保持原样。

这是几层复杂性,我不想深入探讨它,只是,您需要考虑三件事。 有基础设施的服务级别,这是垂直轴,然后是任何给定应用程序的服务级别,然后是业务服务级别,并且这些服务级别相互依赖,因此需要将它们考虑在内基本上,如果您实际上正在考虑创建一个满足服务水平的响应式环境。

然后,在下面的底部有了一个代表数据库,但是您可以在系统中进行任何操作,您知道您已经获得了不间断的配置,这意味着它所说的:它将永远不会停止。 您已经处于热备用状态,以一种或另一种方式实现它的方式不同,但是以一种或另一种方式,如果数据库发生故障,它将切换到热备用状态,并且几乎没有滞后时间范围,以至于用户可能会注意到,但不会注意到太多。

热备用更像是20分钟的切换,当数据库正在切换到备用数据库时,每个人都会呼叫服务台并在帮助台上bit之以鼻。 然后是重新启动的情况,这可能需要很长时间。 值得注意的是,任何给定的应用程序或任何给定的数据库在任何一种情况下都可能取决于实际发生的情况以及该应用程序实际需要的服务级别。

由此,我只想谈一谈复杂性曲线。 复杂性源自节点和连接以及相关性。 在我们所生活的世界中,涉及任何事物的节点和连接的数量一直在不断增长,因此您正在走向这种指数曲线。 如果您可以查看复杂度增加的方式以及时间维度的缩减方式,那么您会了解可用性级别,是否存在时间目标以及它们可能会减少吗?

因此,自然的发展是朝着不间断运行的方向发展,这当然是最昂贵的-至少以我的经验而言-这是您可以创建的最昂贵的配置。 无论采用哪种方式,任何正在考虑这一点的组织都确实需要不仅考虑现在正在发生的事情,而且还要考虑将来将会发生的事情。

我想说的最后一点是,服务水平的管理是一项持续的活动。 这不是您知道自己有一个项目,而是完成了它。 并非如此,因为事情一直在变化。 话虽如此,我将球传给了Dez。

Dez Blanchfield:谢谢Robin。 我喜欢你的开幕幻灯片。 我们刚刚重拍了电影,我想这是电影《海底总动员2》。 您让Nemo以9的形式搜索可用性,我认为这很可爱。 总是要遵循艰难的举动。 当我考虑正常运行时间,可用性和高性能时,想到的第一张图片是我在数据中心的一座火山喷发,因为我是在所罗门群岛靠近火山和赤道的地方长大的。 我脑海中总是有这样的印象,那就是如果发生爆炸,可能会发生这种情况。 这是可爱的富士山的照片。 埃特纳火山(Etna)是西西里岛的东北角,紧邻卡塔尼亚(Catania)。

我这样做的方法是与您进行对话,并给与您与我在董事会中定期接待高层和业务负责人的一些要点,以期我们进行对话从商业或技术的角度以及工程类型会影响您的组织的因素。

我们需要思考以及如何思考-我们从中学到的东西以及如何去应对在谈到高可用性和正常运行时间时,尤其是在自动化和平台方面,我们正在谈论的一些挑战。

因此,我们最初提出的问题是,当我们谈论数据库系统和数据库平台可用性时,实际上意味着什么? 正如Robin在服务级别协议安装的映射中谈到的,我们真正需要和想要的东西一样,谈论将某种东西提供给某个级别所面临的实际挑战实际上意味着什么?

因此,今天的现实是-实际上,在我看来这是几个高峰现实-如今,所有事情实际上都是由数据库驱动的。 如今构建的系统很少,其构建方式只能将内容存储在文件中或某种平面文件日志中。 一切都是由数据库驱动的。 因此,我们有必要停止考虑这些数据库,依赖于它们的不同系统和应用程序以及工具的可用性,并依赖它们来提供我们希望提供,出售或使用的服务。 。 以及周围的所有基础架构。

实际上,如此之多,当您考虑到最近数据的巨大破坏时,尤其是数字原生代或云原生代,出现了一些像Uber和Airbnb之类的公司,以及稍老的PayPals以及世界各地的eBay –这些组织的规模和规模只有借助现代数据库技术和现代云基础架构才能实现。 没有这些,没有所提供的附加功能,它们肯定将不存在。 想象一下一个场景,您只能在9:05到9:25之间到达eBay,因为它在一天的剩余时间内都不可用,因为它正试图做iCloud或备份之类的东西,但是根本没有工作了。

因此,当您考虑我们的日常生活时,还有其他一些关键领域,例如零售,银行业,金融业和航空公司等等。 大型行业集团,例如航空物流,运输业,整个政府,国家安全和警察等等。 所有这些行业,所有这些细分市场,所有这些机构,团体都取决于其环境是否正常运行。

因此,考虑到这一点,我们还需要考虑其他注意事项,我想让您考虑的其他建议,那就是我们现在所说的“永远在前进”。我们之间的联系是永久的,您会定期听到这个主题,我将重复一遍并重申。 现在,我们每天都可以整天使用智能手机。 我们不会关闭它们,我们将它们放在床边,我们总是将它们用作闹钟,我们将它们用作相机并拍照,然后将它们推到云端。

他们始终保持着永久联系的心态。 事实上,有一个我喜欢使用的短语硬币,那就是我们现在生活在Fitbit时代,在这里我们正在测量所有东西,我们正在监视所有东西,需要对其进行记录并那将去某个地方。

还有一个我要离开的短语,那就是一直在九点某个地方。 这是我们生活的24/7/365世界。地球不断绕着太阳旋转,在某个时间和某个时间,每天的晚上9点。 这意味着人们正在起床并尝试做东西,购买东西,安装东西等。

那么,当谈到高可用性时,我们是什么意思? 在您开始深入研究细节之前,这听起来确实很明显。 因此,当您考虑“好,高可用性意味着什么?”时,您就知道了,现实是,没有灵丹妙药。 这是一个非常复杂的概念,因为Robin与他提到的一些主题有关,例如衡量可用性和服务级别协议。 我们将其映射到类似这些问题,例如正常运行时间吗? 我们是否担心像我们所说的五个九之类的事情,我将在一分钟之内谈完。 我们是否认为自己符合服务水平协议中的内容? 例如,在服务级别协议中,我的意思是存在延迟,如今,服务级别协议的三个字母的缩写变得越来越重要。

在您完成内部部署和自托管到外包给第三方数据中心和外包托管服务的整个过程时,现在我们一直在进行云计算。 现实是,当您谈论云时,实际上就是其他人的计算机。 这意味着您没有运行基础架构,没有运行系统,并且始终没有运行云。 您正在将基础架构设置为平台,因此在销售人员服务中它甚至更为重要。 现在以销售为例,您知道自己没有接触任何基础架构,只需登录Web界面即可。

因此,在云和任何形式的外包基础架构世界中,您拥有的唯一控制机制是服务级别协议,这是您拥有的唯一机制,如果人们不满意您的安装,那么他们要么忍受罚款并减少您支付的金额或您根本不支付的金额。

因此,这让我们想到了如何管理高可用性这一整个挑战? 如果不是您的基础架构,我们如何管理可用性正常运行时间–例如,这全都与SLA有关。 从设计的角度来看,这是您的基础结构,还是其他人的基础结构。 我们在模型科学中谈到了负载平衡,这是一种容错设计专利吗?

您是否在体系结构中运行活动的活动活动或活动备用状态? 您是否有多台服务器,多个存储平台? 这些存储平台如何运行? 它们是否相互复制,是否相互镜像? 您在运行RAID吗? 您正在为冗余存储运行哪种类型的RAID? 您是否在磁盘级别运行RAID? 您是否正在运行在模型驱动器以及模型系统和驱动器之间复制的对象存储平台? 每获得一小部分基础架构,就等于N加一吗? 您添加另一个,并且是在同一数据中心还是另一个数据中心? 例如,您是否建立了不涉及单个销售点的外观设计专利?

所有这些基本的东西,现在听起来都像是简单的概念,但是当您进入这些东西中的每一个时,它们都是非常非常详细的东西。 当我们谈论可用性时,我们总是以谈论九结束。 那我们用9是什么意思? 我们都听说过这些,但是让我们考虑一下它们的含义以及它们为什么重要的原因。

因此,我们谈论的是九分之一,这仅占我们可用性的90%。 我知道这听起来很高。 因此,当我们以365的7乘24通话时,例如,如果仅看一年,当我们以90%的比例在九点钟通话时,一年的停机时间为36天半。 让我们将其舍入到一个多月。

现在考虑一下我们每天处理的任何业务-无论是在线银行,eBay,PayPal还是LinkedIn,Twitter等社交媒体平台,或者只是一家普通零售商-假设我想预订从阳光明媚的美国飞往美国的航班澳大利亚,如果我想在一周内到达美国,如果我最喜欢的航空公司停运了36天半,因为他们的服务提供商说:“看,我们90%的时间都在工作,那我会很高兴。 “? 我当然不会。

当您采用此模型时,两个九:99%。 这样就变成了3.65天,大约一年停机了三天​​半。 那有什么大不了的? 好吧,如果您正在运行黑色星期五,并且正在运行特价促销,而人们只能在这几天内购买。

三个九变成每年仅8.7个小时,但每年甚至8.7个小时,这是我们这个时间连续八个小时的连续时间。 银行和金融,卫生方面的问题–如果是医院,那可能会导致生命损失。 当您爬升时,四个九为52分钟,五个九为五分钟,六个九为30秒。 六个九的数字非常高,当您爬上这个梯子时,当您爬上这个九个圣诞树时,上升的九个数字越多,设计,环境和平台就越难。 交付服务越难,如果您考虑减少运行备份,管理,修补,维护窗口等任何形式的故障所需的时间,所有这些都是不小的挑战–有效地归结为停机百分比。

我想在此传达的关键是,正如我之前提到的,没有万灵药。 在可用性方面,没有“一刀切”的产品。您可能拥有适合关键行业的特殊类型的设计专利。 所有银行都面临着同样的挑战。 有些可能是零售银行,有些可能是高级银行。 一些银行可能专注于贸易和投资,财富管理。 有些人可能纯粹是消费者。 有些可能只在互联网上放置,甚至没有出纳员,并且只能在分配现金时处理自动柜员机。 因此,在这些情况下,甚至在整个银行,财富管理和金融服务行业中,对于每种情况,它们在可用性方面仍具有自己独特的风味或需要的东西。

因此,当我们用通俗的英语来考虑可用性时,可用性和高可用性之间的结合-我们认为它们是同一回事,但实际上它们是粉笔和奶酪。 我用通俗易懂的英语来表示可用性,它是服务器或进程正常或普遍运行的时间量度,取决于其使用情况。 那只是意味着我们描述它是否可用。 当我们谈论可用性时,我们经常会陷入这样的陷阱:“我以可用的形式提供它”,而不是在保护该基础结构的安全性方面具有高可用性。

换句话说,高可用性是一种设计,您可以在其中实现或实现某种结果和数据可用性,尤其是在几乎每年24/7/365天的所有时间中,可用性都会达到其中的某些水平九点。 并非总是100%。 从技术上讲,在任何一种环境下,现实中都不可能达到百分之一百。 对于操作系统中的一台服务器来说,要有一个数据库,一个平台正在运行,并且在该应用程序上您可以交付它并希望它运行100%,这是非常困难的。 因此,我们开始考虑设计。 我们有裁员吗,我们有多张幻灯片要复制吗? 然后,当您用通俗易懂的英语进行介绍时,有趣的是可用性与高可用性之间的区别。

我以为我会以一个真正简单的图形形式来表示它,以便让我们了解当您开始逐渐提高在保护服务正常运行时间方面的可用性方面所面临的挑战。 在左下角,我们只有一个九。 我已经列出了我们通常谈论的五个九。 六个九点有点离谱。 当我们谈论左下角的五个九,大约是停运35天时,您正在尝试提供一种低成本,低复杂度的环境,因为您有很多可能会失败的事情,并且您可以仍然符合您的服务水平协议。

但是,当您从左到右沿着底部移动时,到达图中的数字更多的点,您就会得到开始考虑系统和平台的复制的方案。 您必须考虑基础架构各个部分的群集和虚拟化。 您必须考虑这些集群的地理位置,数据中心的多个站点,并且必须考虑要针对的行业类型和细分市场。 那么您需要满足哪种类型的服务水平? 您在寻找什么服务? 实时通讯是基于卡的实时服务。 是兵役吗? 因此,该图从左下角到右上角,随着您通过该曲线,成本和复杂性都会增加。 随着环境变得更加复杂和要求更高,您将需要更多的优势。

例如,此图做的事情非常相似:它描述了成本部分与所需可用性部分之间的情况。 因此,在左上角,我们映射了高度可用的复杂系统,以及可用性下降带来的成本与零停机时间内获得可用性的收益。 因此,例如,如果我们在左侧的环境中情况有所恶化,则可能会造成财务损失。 我们的法律影响可能是商业业务战略层面的影响。

我想,在获得服务收益方面,甚至存在各种道德问题。 如果这是一个健康行业,并且他们开始经历停电,对客户的影响,客户满意度降低,员工生产力,用户生产力等方面的损失。那么,如果我们考虑设计高度复杂,高度依赖的设计,这些都会受到影响。 ,高风险的环境中,存在断电和因此而造成损失的潜在风险。

在右侧,我们尝试针对以下场景:如果我们在设计上投入大量成本和规划,则在智能实施方面进行投资。 我们投资于为人们提供技能和资源,并拥有高度重视的网络,高度重视的运营环境以及硬件和软件。 我们获得了高可用性,但是成本很高。 因此,摆动的魔术摆点位于它们交叉的中间位置的最佳位置,我们在这里稍微降低了成本,并增加了可用性,而这些可用性只是在9的水平之间变化,而高可用性是连续可用性,这是一个我们要面对的挑战依然艰巨,例如您愿意投入多少资金来获得所需的服务水平?

我们也有一个主题,我将不对其进行详细介绍,但是我只想让您将其删除并加以考虑。 设计故障之间的平均时间与恢复的平均时间之间的差。 换句话说,您是否在投资于质量更高的基础架构,质量更高的设计,质量更高的硬件和软件以及质量更高的熟练员工和资源来进行工程设计并减少平均故障间隔时间,即发现故障所花费的平均时间(相对而言)减少对基础设施,资源和设计以及盲目的专利的投资,具有较高的恢复能力? 换句话说,如果发生故障,则需要插入很多电源。如果某人拥有一台笔记本电脑而死了,那么您就有一个备用笔记本电脑。 您将其交给他们,然后在30秒内他们登录。这是两极的极端。 最上面的一个推断出您要付出高昂的成本和大量的投资来避免失败,最下面的一个则暗示:“我将接受失败的来临,因此我将围绕这一点进行设计并为失败做准备并迅速恢复。”

如前所述,我可以说:“我的可用性不是您的可用性。”因此,在数据库环境和支持基础结构,运行数据库并保护数据库并确保高可用性方面,实际上并没有一站式服务。 每个人都有自己的需求和需要。 因此,您必须问自己这些基本问题,这些问题我将留给您解决,那就是:您的组织可以负担得起什么? 我不仅在谈论美元和美分。 我说的是,作为一个组织,只要可用性水平可以提供,您可以从资源,时间和精力等方面获得什么? 另外,您的业务可以提供什么支持? 因此,您可以筹集的当前功能,当前技能,当前基础架构,当前资金。 因此,您在实际负担得起的范围和可以支持的范围之间的权衡是一个有趣的平衡。

另外,您还必须问自己一个问题:您内部拥有哪些技能和技术? 您可以外包一些挑战吗? 然后您可以将事物移动到云中吗? 如果您除了软件服务之外还拥有基础结构服务,那么在您走到更高层次时,您将没有该堆栈。 因此,您应该在平台和服务上投入更多的资金,而不用担心基础架构方面的问题,还是应该因为无需担心平台而将软件作为服务产品看待?

您为哪种类型的市场以及消费者或客户服务? 我的意思是,如果您是一家电信公司,并且有人必须拿起电话,并且始终听到拨号音,那么这是一个非常不同的挑战,这是在周一至周五(九至五点之间开设一家小型零售店)然后关闭以像壁角商店的理发师一样在午餐时间工作一小时。 因此,您必须经过漫长而艰辛的思考,它的工作原理以及对您的组织意味着什么,您需要提供什么。

然后在内部环境,外部托管环境和潜在的云环境之间进行权衡。 正如我之前所说,这同样来自时间挑战。 因此,我们剩下最后一个问题,我期待着IDERA的朋友告诉我们他们如何解决这些问题,这就是在将所需的需求和所需的可用性与性能,您的业务需求和需求之间进行细化的处理。您的市场和消费者需求。

事实是这绝非易事。 全面思考这些事情将需要花费时间,精力和金钱。 始终是对人员和技能能力的投资,以及对软件和工具的投资,以使某些流程实现自动化,并为这些人员提供正确的工具和正确的系统,以使他们的生活不仅变得更好,而且因为监控非常大规模的环境并保护环境而可能并且管理那些大型环境通常超出了个人能力。

因此,考虑到这一点,希望我为IDERA上的朋友们进行了一场精彩的交谈,以讨论他们的平台和工具,并希望最后提出一些重要的问题。 我会过去。

罗宾·布洛尔博士:好的。 伯特,我刚给你钥匙,把它拿走。

伯特·斯卡尔佐:谢谢! 谢谢Dez和Robin。 我将继续讨论数据的高可用性。 我实际上将利用Dez刚才所说的很多东西。 因此,选择,九折,权衡,承受能力。 我将尝试对数据库管理员或更接近战es的人说更多,他们将如何看待它? 他们将如何设计它? 这些选择意味着什么。

现在,我将尝试与数据库无关。 例如,我不会绘制特定于Oracle或SQL Server的解决方案,但我会绘制所有数据库供应商都提供的通用体系结构。 他们都用不同的名称来称呼它,但这是您的共同选择之一,我想从业务和技术的角度来研究它,以及它与业务需求的关系。

我想从最基本的伪高可用性解决方案开始,通过存储级解决方案,虚拟化级解决方案和数据库级解决方案中的选项开始。 然后,我还想向您介绍所有选择在云中也都可用的事实。

因此,我将再次尝试保持数据库不可知性。 现在,我要谈论的大多数事情都知道它们存在于Oracle,SQL Server,MySQL,PostgreSQL中。 还有一些第三方供应商,他们提供的工具还可以为您提供可以考虑的其他体系结构。 而且,正如Dez刚才说的,没有一个解决方案是最好的。 这一切都取决于。 但是我们要研究的是一个普遍的事实,那就是会有更多的运动部件,因此它将变得更加复杂,因此成本更高。

因此,我们都知道数据是重要的资产。 每个人都知道快速访问数据总是很不错的。 但是,可靠地访问数据至关重要。 正如他在谈论他的九个例子时所说的那样,您真的有能力承受36½天的停机时间吗? 始终保持可用数据至关重要。 因此,无论是在收入损失方面,还是在客户流失或客户商誉损失方面,停机都可能造成巨大损失。 我会给你一个很好的例子。 如果我购买的某个特定网站的速度很慢,那么我可能会尝试寻找一个新网站,该网站以类似的价格出售相似的商品,但没有缓慢的网站。 因此,不仅仅是失去客户,这是客户对您的善意。

现在,这些天硬件便宜很多,因此对高可用性的需求越来越大。 再说一遍,当我们着眼于这一点时,我将带我们进入云。 我们提供各种级别的产品:存储供应商,数据库供应商,虚拟化供应商,甚至现在还有云供应商。 因此,对云真正有趣的是,当我绘制了可以在云中构建的这些架构的所有精彩图片之后,很多时候只是选中了一些复选框。 然后您说:“我想要跨地理区域复制。”复选框。 “我要复制关键硬件组件。”复选框。 因此,如果您了解这些图片,有时在云中,只需选中几个框即可构建您想要的图片。

现在,关键是高可用性的业务需求是什么? 例如,我是否只需要担心单个站点的故障,还是必须跨多个站点进行故障处理? 换句话说,我可以拥有一个计算中心,并且不在乎该中心是否可以离线吗? 我没有提出将其扩展到多个站点的业务要求。 这是一个业务问题。 而且重要的是要知道企业如何看待该问题的答案,因为这通常会定义您的预算。

现在,您还想看一下故障保护级别。 可能是电源故障? 可能是组件故障吗? 就像NIC或HBA损坏一样,主机总线适配器也是如此。 硬盘坏了吗? 这是储物柜故障吗? 是电脑故障吗? 还是在某些情况下是站点故障? 这与在某些情况下可能会发生站点故障不同,因为站点本身处于脱机状态。 在另一种情况下,站点的很大一部分可能处于脱机状态,但从您的角度来看,这就是整个站点。

然后,正如Dez所说的,对恢复运营时间的期望是什么? 这是一个商业问题。 如果企业说您必须能够在两分钟内恢复运行,那么很明显,这将定义一些我要向您展示的图片,这些图片将起作用,而其中一些将不是您的选择。可以选择。

在高可用性期间出现的另一个问题是,但通常人们会忘记问:“嘿,业务,如果在我处理交易过程中发生了某些事情,恢复系统后我会损失什么? ” 换句话说,如果我可以在两分钟内恢复系统,并且损失的时间不会超过10秒(例如正在进行的交易),那是可以接受的业务吗? 再一次,这将定义企业愿意为此花费的资金,然后再一次,这可能会定义我要向您展示的哪些图片适用或不适用。

因此,让我们从最基本的伪高可用性解决方案开始。 这确实不是高可用性,但是我喜欢从此开始,因为它可以使人们以正确的方式思考。 如果我有一台服务器和一个存储阵列,通常我会在该服务器中放置多个NIC,网络接口卡,并将它们绑定在一起,这样,如果一个NIC出现故障,我仍然可以使用。 而且,我将对主机总线适配器执行相同的操作,我将通过不同的交换机对其进行多路径处理,以使我可以通过多种方式访问​​存储。 我有一个通用电源,并且存储阵列中有重复的控制器,也许我对磁盘做了RAID 10之类的操作。 换句话说,在这张照片中,我已经防止了多个级别的单组件故障。 因此,我不受NIC,HBA,控制器或交换机的约束。

但是,如果您注意到,则服务器为红色,存储阵列为红色。 我仍然有两个区域,如果它们出现故障,如果我的服务器坏了,那么我就死了,如果我的存储阵列柜坏了,那我就死了。 因此,虽然这不是真正的高可用性,但它使您开始查看并查看图片并说:“我想要没有红色的图片。” 这些图片的真正目的是使我们指向正确的方向。

因此,首先要发生的事情是,作为一名DBA,我可能总是想将高可用性解决方案作为数据库实现,但是它有可能可以作为存储解决方案来使用,或者可能是存储级复制。 如果是左侧的话,我会进行存储虚拟化。 发生了什么事,我的光盘在两个不同的存储柜中都有RAID 0,但在两个不同的存储柜中却都有RAID 1。 换句话说,实际上我现在可以使存储柜发生故障,而且还没有死。 因此,它比以前的图片要好,因为在前面的图片中-记​​住我们服务器上的红色和存储阵列上的红色-现在我们做了一个小的改进,现在在存储级别上不再有红色,我们曾经使用过-存储虚拟化解决了该问题。

现在,您可以执行此操作的另一种方法(并非所有供应商都提供此方法)是您可以执行存储级复制。 我不是在说数据库复制,而是在说要为存储复制块I / O。 这可以在存储级别完成。 再说一遍,现在我在右侧有另一张图片,从底部删除了红色,因为我正在使用存储复制。

因此,这是另一张可能不可用的图片。 而负责管理此事务的人可能是您的存储管理员,而不是您的数据库管理员。 我喜欢提出这一点,因为有时人们会想到:“哦!高可用性,必须由DBA来解决此问题。” 并非总是如此。 在这种情况下,它可以是存储管理员。

接下来,我们可以将服务器虚拟化作为一种​​可能的解决方案。 现在,如果您还记得的话,在第一张图片中,我在服务器上有红色,在存储阵列上有红色。 在这种情况下,我可以使用虚拟化进行重定位,并且在某些情况下,重定位是一种热重定位,在某些情况下,甚至甚至可以是热重定位。 一些虚拟化或虚拟机管理程序提供了在运行中移动虚拟机的功能。 并且一些数据库会轻易接受飞行中的移动。 现在,并非所有虚拟机管理程序都提供此功能,但这是一种可能的解决方案。 现在,我已经使顶级服务器不再是红色,但是我仍然拥有共享的存储阵列,然后猜猜该解决方案可能是数据库管理员和虚拟化管理员共同努力的结果。 甚至可能只是虚拟化管理员,具体取决于该虚拟机管理程序和数据库所支持的重定位级别。

如果您想知道,“哇,他这次搬迁是什么意思? 给我举一个具体的例子。”例如,在VM中,您可以使用VMotion将虚拟机从一台主机移到另一台主机,而无需停机。 现在,很明显,先前的照片中仍有一些红色。 我仍然将存储视为单点故障。 因此,我们进入下一个解决方案,那就是让我结合存储和服务器虚拟化。

现在,在这种情况下,再次由存储管理员和虚拟化管理员来构建此解决方案,现在看起来:我的照片中没有红色。 我具有高可用性,因为我可以将虚拟机或正在运行的应用程序或数据库从一台服务器重定位到另一台服务器,并且可以通过在两个独立的存储阵列上进行RAID 1来实现存储阵列的虚拟化。 我已经对交换机和HBA进行了多路径处理。

因此,现在我已经构建了一个HA系统,而主要不是在数据库级别上完成的。 换句话说,我已经使用其他技术来完成同一件事。 因此,这是一个解决方案。 然后,我们进入所谓的共享存储可伸缩集群。 它实际上不是HA解决方案,但是我还是想在图片中展示它。

而且这里发生的是我们有两台服务器运行一个数据库,并且它被认为是一个数据库。 它不是两个独立的数据库; 它不像是主机和从机,也不是冷热机,也不是主动和备用机。 也就是说,这两个节点一起工作以呈现一个逻辑数据库。 因此,发生的事情是,如果特定节点发生故障,则您仍然处于运行状态。 因此,它可以保护您免受服务器级故障的侵害,并且,如果可以的话,基本上可以通过分片节点资源来做到这一点,但是对于磁盘而言,仍然存在单点故障。 因此,这是一个共享存储的可伸缩群集,Oracle将其称为Real Application Cluster或RAC。

现在,另一种解决方案是使用共享存储故障转移群集。 因此,在左侧,我有一个主动节点,在右侧,我有一个被动节点,中间有心跳。 我有一个共享存储阵列,这很关键。 你必须有那个。 基本上,如果主动节点遇到问题,被动节点可以接管。 对此存在许可问题。 一些数据库供应商允许您在固定时间内使被动节点的许可证减少。 在其他情况下,您必须具有完整的重复许可。 这完全取决于您的数据库供应商。 但是它们都支持这种情况,即如果一个节点出现故障,另一节点可以接管。

通常,这是一种情况,当您从主动节点转到被动节点时,您可能会在大多数数据库中(不是全部)进入一些数据库,航班交易。 然后,我们进入数据库管理员真正可以查看的内容,即数据库复制,并且有两种不同的数据库复制方法。

这里有物理复制,最重要的是,在这张图片的中间,您可以看到绿色的星星,表明复制是由数据库完成的,但是就像存储级虚拟化一样,它是在块上完成的水平。 因此,我们正在重复从主动节点到只读或被动节点的实际块I / O。 这被认为是物理复制。

现在,让我转到下一张幻灯片,因为它几乎相同,并且是逻辑复制,并且图片中唯一改变的是在中间,而不是通过块I / O发送,我们实质上是通过日志发送其中包含SQL命令的文件。 因此,换句话说,我们要复制的不是物理I / O,而是导致物理I / O的命令。

因此,这通常称为日志传送或基于日志的复制。 一些数据库供应商本机为您提供此服务。 其他数据库供应商可能没有提供此功能,但后来第三方供应商提供了此功能,因此这是一种非常流行的HA解决方案,被认为是完整的解决方案。 但是,此解决方案主要是DBA的责任。

因此,我没有使用虚拟化来完成此任务。 我可以,但是我不依赖它。 而且我没有使用存储虚拟化。 同样,我可以,但是我不依赖它。 但是我正在建立一个以数据库为主要驱动功能的解决方案。 因此,这是逻辑复制。

现在,还可以将数据库虚拟化和存储虚拟化相结合。 可以说,在我的数据中心,我可以在左侧的蓝色中为存储进行虚拟化,这样就不会出现故障的特定存储阵列。 但是我可能正在从一个数据中心到另一个数据中心进行基于数据库级别的日志或逻辑复制,以便命令也可以在数据中心中执行,从而导致I / O,但不一定是相同的I / O,因为我m不会通过存储解决方案或数据库来发送块I / O,但我正在传送日志,因此会传送SQL命令。

因此,对于大型组织来说,这是一张非常普通的图片。 我喜欢这里的图片,因为如果必须使用Oracle这样的数据库在内部进行设置,则可以做到; 这是相当多的工作,非常复杂,有很多活动部件。 如果我在云中执行此操作,我可以直截了当地说:复选框,我想要两个地理区域,我想要被不同大陆所隔开的区域(在不同的洲),我想要特定地理区域的存储级虚拟化。 我什至可以说我想要进行虚拟化类型分配或高可用性定义的功能,再次,这是另一个复选框。

我喜欢在云中进行的另一件事是,还有一个复选框经常会说:“我不想处理补丁,只需要对其进行补丁,”您知道,只需将其用于工作流中您在后台进行的其他所有工作即可场景,随时让我打补丁。 因此,尽管其中一些图片变得非常复杂,并且可能很难在内部进行处理,但实际上它们在云中变得相当容易。

现在,有趣的是,很容易检查所有复选框,但是猜猜是什么,每月花费更多的钱。 因为,如果您正在运行两个数据中心,那么您知道正在使用的云中有两个数据中心,那么与仅使用一个数据中心相比,您将支付更多的费用。 同样,如果将存储级别或虚拟化高可用性作为附加层使用,则可能还会产生额外费用。

因此,有趣的是,尽管很难在现场进行操作,但您可能会想得太多,但在云中却很容易做到,但您可能会想不到。 因此,始终知道图片是什么样子,并且始终知道要生成的图片对成本造成的影响。 现在,有比我在这里显示的更多的组合。 这不是一个完整或详尽的示例。 有定期定期出现的新技术,所以谁知道–我可能没有显示最近三个月才出现的新技术。 高可用性比十年前更为普遍。

实际上,对于大多数大型组织而言,如今这已成为一项强制性的业务要求,对此我不敢苟同。 我喜欢回到这张幻灯片,因为我只是说这是强制性的业务要求。 我在右边找到了这两张桌子。 上面的一个不在SQL Server文档中,而下面的一个不在Oracle文档中。 这些是什么,这些表可以帮助您选择要使用的复制方法。

并且请注意,您从一些非常简单的问题开始。 我可以使用多少数据? 如果答案为零,则您只能在该顶部图表中选择第一行或第四行。 然后,您问另一个问题。 好吧,我允许康复多长时间? 如果有人说几秒钟或几分钟,那就为您做出了选择。 然后,故障转移必须是自动的还是需要手动进行? 这是另一个业务问题。 他们可能会说他们想要自动,因为他们不想依靠升级程序,然后有人分配了票证然后解决了问题。 他们只是希望将其修复。

这些都是业务问题,如果我拒绝为Oracle做同样的事情,它们都是相同的问题。 我问,好吧,我允许什么样的故障,什么样的持续时间,我可以损失什么,恢复程序是什么? 这些都是业务选择,因此,如果业务告诉我三个或四个问题的答案,我的工作真的很容易,我只是来这里,我选择其中最匹配的一个,然后就建立了那个。 记住,在云中,实际上可能只是几个复选框。

这样一来,我就可以读完材料,并抽空提出问题了。

埃里克·卡瓦那(Eric Kavanagh):好吧,戴兹(Dez),也许您是第一个,然后是罗宾(Robin)?

Dez Blanchfield:好的 。 实际上,对于那些不在Twitter上的人来说可能有点不公平,但我只是在推特上发布了一张想在每个人的脑海中可视化的图形图片,然后想在此处致电给我们博学的朋友。 当我想到这个领域的专有和开放源代码时(我们经常谈论的是甲骨文和微软等公司的专有数据库,而不是开放源代码),您将面临挑战,其中专有世界互联网软件供应商或软件开发人员或公司投资于这些机构以建立这种复杂性。因此,最终您会遇到这样的情况:您购买了该软件,而无需投资太多人,因为您正在购买具有内置和开放源代码的功能–可以说,您无需为软件付费或价格低廉,但您无需为软件付费,但您必须在车身上进行投资。

而且,我非常想知道您的想法,特别是现在我们正在进入可以获取“或”的云模型。 您可以转到AWS或Azure和Rackspace,然后购买提供数据库平台的服务,也可以通过开放源代码来实现。 以及我们刚才所说的,专有和开放源代码之间的冲突是什么,您正在谈论的设计模式如何生效,随着我们的前进,尤其是在提供可用性方面,您对此主题有何一般想法?

Bert Scalzo:当我尝试解决该问题时遇到的一大问题就是,我回头向客户询问他们的性能要求。 我这样做的原因是,至少从历史上和我自己的经验来看,我发现,对于需要高吞吐量复制的客户,我几乎总是可以从数据库提供的复制中受益供应商,因为它本质上是内置的,并且处于较低的级别,因此有时甚至使用开源解决方案也无法使用的机制。

我会给你一个很好的例子,说明我遇到过的一个案例。 我有一家基于互联网的公司,该公司正在使用MySQL作为数据库,并且它们使用的是旧版本的MySQL(例如Version 4.0),并且节点之间的复制是它们可扩展数据库规模的限制因素。 他们正在考虑购买第三方解决方案,然后他们正在考虑:“好吧,也许我们可以使用其中一种开源解决方案。” 真正归结为,他们要做的就是将MySQL升级到Version,我认为是5.5,因为这两个数据库版本之间的区别在于MySQL复制的4.0 Version没有线程化,在5.0版中确实如此,这实际上是他们的最佳途径。

现在,我们研究了其他选择,但是决定性因素是性能,并坚持使用数据库供应商的解决方案,而实际上进行数据库升级最终成为我们的最佳解决方案,以最大可能地获得他们需要的性能更高的可用性。

Dez Blanchfield:是的,老实说,这反映了我的想法。 仅作全面披露,我不会涉足品牌领域,但我来自于OEM,软件供应商和IOC的专有背景,这绝对是我的经验,同时我非常专业-open-source,我是很多项目的代码贡献者,但我们不会透露姓名,但是我同意您的看法,如果您是一个大型组织-假设您是一家银行,或者可能是任何人是–始终都不想成为IT商店。 您知道,例如,如果您是报纸发行人或零售商,则不想成为出版报纸的IT商店,而想成为实际上只是利用IT的报纸商店。

因此,投资专有功能,使软件开发人员可以在该工具中构建所有功能,负载平衡等,这比起像.com初创公司之类的公司而言,意义非凡。这样可以投资人体。 您如何看待这种情况?

在我交给罗宾·布洛尔博士之前,可能是我的最后一个问题,因为我知道我们的时间不多了。 从趋势的角度看,您从哪里看? 因此,您一直无所不在,处在事物的前沿,是否看到人们已经坐起来并关注并唤醒了将其作为日常业务的一部分的必要性,一天的谈话回到董事会会议室? 还是您仍然看到它是极客农场,技术人员和帽衫在考虑可用性,因为这会使它们在凌晨4点钟醒来而导致某些设备离线时呢?

您是否认为这种趋势现在正在向各种规模的组织转移,而不是像航空公司,银行和金融业这样的明显组织,而是整个企业? 您是否认为人们真的已经失去了保护数据库环境并提供高可用性并为此进行投资的价值主张,或者您认为我们还有路要走? 市场上的一般意义是什么?

伯特·斯卡尔佐(Bert Scalzo):现在,我认为仍然存在差距,但这并不是差距,因为企业没有要求,而是栅栏两侧之间沟通水平的差距。 换句话说,业务人员非常清楚地说:“这些应用程序需要高可用性,而当我们说高可用性时,它们具有这些特定要求。”

某种程度上,这种信息并没有清楚地传达给技术人员。 否则,技术人员会回来说:“哦,那很复杂,这将花费您更多的钱,”或者其他。 我认为将要发生的事情最终将逐渐消失,因为说实话,例如,在云中,只需在此处或此处选中几个框,然后说:“为我构建这个非常复杂的技术结构,”确实没有充分的理由让技术人员返回并向业务人员说:“哦,这很昂贵”或“很难做到”,或如此或那样,而业务人员开始知道这就是事实。

而且,我什至在自己的IT人员会来的环境中看到,他们说:“哦,您无法拥有想要的东西。 这太贵了。”他们将聘请第三方咨询公司,然后该公司会说:“不,那是不正确的。 这是您的方法。 因此,我认为我们在双方之间的通信级别之间仍然需要一点时间,然后这才变为自动静止。

Dez Blanchfield:是的,这肯定反映了我在澳大利亚和亚太地区看到的情况。 我敢肯定这是全球性的事情。 那就是董事会下层的许多关键决策者,所有业务部门的负责人,他们在技术上都更加精通–他们在阅读博客,观看网络研讨会,收听各种文章和播客,他们将参加活动,论坛和聚会,现在他们知道了自己的选择,并且知道云是一种选择。

他们还知道,他们可以像您所说的那样,将内部能力带给他们,所以我认为现在面临着一个有趣的挑战,即必须进行对话,这基本上就是我们今天在人们, ,从内部开始做事,然后只吃棕色午餐,并向内部简要介绍我们的当前状态,理想的状态以及我们应该去哪里? 然后,将它们组合在一起。

我有一个私人留言,我现在要快速讲一下。 有人问一个问题:“获得100%的可用性是否现实?”您也许可以在这里纠正我,但我要说的是。 我已经建立了一个用于电子资金转帐的平台,快速银行业务平台和EFTPOS终端之间的EFTPOS网关。 我是在2000年代初期建立的。 实际上,17年中100%的时间都在网上。 实际上,它是在2000年代之前制造的,但仅在2000/2001年才投入生产。

因此,从开发到测试再到生产的17年已经过去了。 在那17年中,运行开放源代码操作系统但专有数据库的成本非常低廉的现成PC每90天进行一次主动/被动交换,并申请了不同的设计专利,并复制了每个服务器中的磁盘,模型服务器之间的数据复制,多个数据中心的复制,以及从数据中心A进行生产90天的转换,然后转换到数据中心B进行生产。

而且,当它翻转时,它会自动进行补丁和更新,因此仅针对我刚刚私下提出的问题,是的,这是可能的,但是从设计的角度来看,对该项目进行了大量投资。 因此,基础架构实际上并没有那么昂贵,但是要获得该基础架构,设计,测试和实施却非常昂贵。 因此,我们不必在硬件和基础架构上花费很多钱,但是在云还不是造币厂的那一天,我们使用了非常智能的工具。

因此,答案是肯定的,它可以完成,甚至现在使用云可以完成,正如我们刚刚听到的那样,单击按钮即可启用该功能。 我要把它交给罗宾,因为我确信他也有问题。 但是非常感谢您回答我的问题,我真的很喜欢今天听到您的消息。 完全具备所有这些功能,因为它反映了我近30年来一直在做的所有事情。

Robin Bloor博士:好吧,我来接。 使您着迷的我的一件事是,当我以前不得不为这些东西而苦苦挣扎时,现在没有可用的选项数量。 我对谁来设计这些配置还是现在谁来设计这些配置感兴趣? 过去发生的事情,或者我习惯的世界是,将有一个相当繁重的交易系统,而您将对高正常运行时间,高可用性感兴趣。 因为,您知道交易系统,如果它以任何方式崩溃,那将是昂贵的。 而且,您将不会拥有刚刚提供给我的所有选项,但您可以通过一种或多种方式找到一种方法,主要是通过复制来创建一个热备用数据库,该备用数据库不会引起明显的点击。它会给您降级的服务,直到您回来。

而且,我正在某种程度上,正在查看您向我展示的内容并对此进行思考,而这已经有15年没有完成任何此类设计工作了,现在是谁在做这项工作? 就像我今天一样,这是您在项目开始时所做的事情,使基础架构正常运行吗? 还是这是组织内部正在进行的活动? 因为随之而来的是新技术的选择。

伯特·斯卡尔佐(Bert Scalzo):在大型公司中,包括其IT部门在内的所有运营都非常高效,他们通常会拥有一个集中式架构小组,或者他们会因此而得名,我听说它被称为“建筑集团”很多次。 他们有责任了解所有这些不同的图片,优缺点和成本。 然后将发生什么,当一个特定的应用程序在查看时说:“嘿,我必须满足X,Y和Z的业务需求。嘿,架构团队,我有什么选择?”

他们将给他们答案,例如,这里提供了两个或三个,然后在那一刻,决策将移交给应用程序团队或应用程序的业务发起人。 但通常情况下,有一个集中的小组负责此事务,并随时准备和预先构建该信息。

现在,它不是那么正式的中型公司。 往往会发生这种情况,您将获得一到两名高级DBA或系统管理员,而他们将以这种专业知识非正式地被称为“领域专家”。 因此,即使是在中型公司中,它也发生在非正规的结构中。

Robin Bloor博士:真的很有趣。 在我这一天,除了交易系统之外,我们再也不会考虑高可用性。 好吧,如今,当然,您的流系统可能会在可用性方面受到更大的要求。 但是,在基于查询的后端,分析,数据仓库,DI类环境中,您是否看到过那里对高可用性的要求?

Bert Scalzo:是的,很高兴您提出了这个问题。 我为一家零售公司做过一些工作,他们的业务战略决策很大程度上基于他们将要从数据仓库进行的分析。 而且,事实上,他们接受了《福布斯》杂志的采访,该公司的首席执行官说:“嘿,过去五年来我们的股价上涨了250%,这是一个非常重要的原因,因为我们知道如何有效利用我们的数据他们非常擅长制定业务决策,以至于对他们来说,数据仓库并能够进行这些分析,能够每天根据其运营数据做出决策,实际上对他们而言,生产系统。

我会给你一个很好的例子,说明它的重要性。 在这个特殊的零售供应商(负责啤酒销售的那个人)那里,他是公司中第三重要的高管,因为他带来了60%到70%的收入。 因此,他必须能够在该市场中保持竞争力,必须每天知道我应该进行哪些促销活动。 而且,这可能不仅基于一年中的时间,还基于可能影响啤酒等产品销售的天气,模式和其他关键数据。

Robin Bloor博士:嗯,我想肯定会有这样的事情。 我们有点没时间了,我想我应该去找Eric,以防他收到听众的一些问题。 埃里克?

埃里克·卡瓦纳(Eric Kavanagh):是的,伯特,这一切都是好东西。 我认为您在演讲中回答了我们听众提出的所有问题。 但是观看很有趣。 我很高兴您能谈论存储虚拟化及其带来的影响。 所以,这都是好东西。

好的,伙计们,我们会将所有这些网络广播存档,以供以后查看。 因此,请跳至Techopedia.com,以查找网络广播部分。 所有这些热门技术都将在此处列出。 非常感谢我们的朋友Bert的专业知识。 当然还有Dez和Robin。 伙计们,我们借此向您告别。 照顾自己。 下次我们会与您联系。 再见。

保护您的数据库:高需求数据的高可用性