如何在2个HA节点上分别运行不同的Oracle数据库实例

是不是要连2个oracle数据库，如果是的话

可使用DBlink 可以链接远端个数据库

create database link

然后调用远程的数据表的，在数据表后面加上

@DBlink_name

补充回答：在tnsnamesora配置2个

ora_db_1 =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 105187)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ora_db_1)

)

修改相应的IP和数据库名称即可

Hadoop HA（High Available）经过同时配置两个处于Active/Passive模式的Namenode来解决上述问题，分别叫Active Namenode和Standby Namenode。 Standby Namenode做为热备份，从而容许在机器发生故障时可以快速进行故障转移，同时在平常维护的时候使用优雅的方式进行Namenode切换。Namenode只能配置一主一备，不能多于两个Namenode。

它与被认为是不间断 *** 作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。高可用性（HA）的功能1、软件故障监测与排除2、备份和数据保护3、管理站能够监视各站点的运行情况，能随时或定时报告系统运行状况，故障能及时报告和告警，并有必要的控制手段4、实现错误隔离以及主、备份服务器间的服务切换HA的工作方式：HA有主从方式和双工方式两种工作模式高可用性方案则利用更少的冗余部件同时由软件检测故障，一旦故障发生立即隔离损坏部件，通过提供故障恢复实现最大化系统和应用的可用性。容错技术随着处理器速度的加快和价格的下跌而越来越多地转移到软件中。未来容错技术将完全在软件环境下完成，那时它和高可用性技术之间的差别也就随之消失了。

天融信工程师来答一发：

首先你要确认是否都变成主了，直观确认方法是看是否两台设备的MA指示灯都亮了，一般主备模式下只会有一台亮MA灯；

如果确认都亮了，那么可以得出结论：此时两台设备都运行了HA协议，且都为主；

原因可能有：中间的心跳线断了，或者是2台墙之间无法通信，导致都认为对方宕机了，所以都变成主设备，

还有可能是两台墙都设置为主设备，并且都开启抢占模式了

解决方法是先将备墙退出HA状态，然后确认主墙为主后，并确认主备墙之间通信正常后，再将备墙加入HA中，并且建议只让主设备开启抢占，或者都不开启抢占

1 你说的备机慢的情况肯定不会是HA造成的，问题在其他地方！

2 假设A机正常，切到B机慢，如果切回A呢，是不是又快了

3 给下HA的配置，首先应该让我们知道你是怎么配的，不然什么都是白谈的

以下引自新浪 sunny的博客

原文链接：>

delxu原创

想写一篇关于VMware HA的博客由来已久，曾经做了些功课，查了不少资料，写了点笔记，但是终于因为各种原因没有成文。随着vSphere 5的发布，HA机制作出了不少调整，很有必要写一些了。本文（或许我可能还会就ESX4的HA机制和 *** 作写上几篇，凑成一个系列）就是我的一点读书笔记整理而成。

什么是HA

HA的英文是High Availability，高可用性。从字面上的意思就是一种让服务中断尽可能少的技术。VMware的HA和微软的MSCS(Win2008以后改称Failover Clustering)类似，都是将多台主机组建成一个故障转移集群(Cluster)，运行在集群上的服务(或VM)不会因为单台主机的故障而停止。

用一个图来简单说明HA的工作原理：图中橙色的主机ESXi01宕机了，其上的2台虚拟机VM1和VM2就根据HA的调度被ESXi-02和ESXi-03这2台主机接管，并重启运行起来。

注：本文均截取自《VMware vSphere 5 Clustering Technical Deepdive》

但是要注意的是，HA(无论是VMware的HA还是MSCS)不是通常意义上的完全不中断服务的高可用性，HA只是一种自动的故障切换机制，当某一主机发生故障时，服务或VM（就配置了MSCS的Hyper-V来看，VM其实也被看作是一个服务）自动到另外的可用的主机上重启。这其实是一个中断然后重启的过程。就VM来说，看上去就好像是一台服务器突然被拔掉了电源线，然后又重新加电开机。这个故障然后重启的过程其实是比较长的，根据不同的VM而不同，少则1-2分钟，多的则可能达到5-6分钟。如果运行在一台缺乏资源的的主机上，这个时间可能更长。

创建一个VMware HA

创建一个VMware Cluster并启用HA的方法很简单。谷歌百度一下很容易找到一堆。这里不再赘述，过几天有空了我另外截些图单独写一篇Cluster创建图解的blog。

这里我想重点讲的是HA的原理。

创建HA的前提

一个通用的HA的集群通常有这么几个必要的条件组成：

2台或者更多台主机

这些主机共享一个外部存储

VM是运行在共享存储上的

主机上至少有2个以上的网卡，其中一个需要负责传递“心跳”信号。

上面这些条件是大多数高可用性集群都需要的一致的。

此外，要成功配置VMware HA，还必须具备这么几个必要条件：

必须有vCenter Server（虽然没有vCenter HA也能发挥作用，但是创建Cluster的时候必须有vCenter的参与）

所有Host都必须有相同的vSwitch配置

特别要注意的是，对于ESX 4x或之前版本，DNS是建立HA必要前提，所有Host都必须能够正确的解析其他node的DNS名字，将主机加入到一个集群也必须用其FQDN名。但是从vSphere 5开始，这已经不是必要的了，IP地址被直接用作HA集群的通信，这样减少了HA的依赖性，加快了HA的响应速度。

但是，因为VMware vSphere 5的其他一些服务和组件仍然需要DNS，使用FQDN虽然仍然是推荐做法。

HA的组成部分

vSphere 5的HA的组件有以下三个：

FDM

hostd

vCenter

FDM是Fault Domain Manager的缩写，它的前身在ESX4叫作AAM，是用来管理HA的最重要的一个组件。它负责cluster的心跳、主机之间的通信，和vCenter的通信、协调虚拟机的位置、调度虚拟机的重启、记录日志等等。

hostd负责监控直接和虚拟机打交道，例如让虚拟机开机、监控虚拟机的状态等。FDM需要hostd的帮助来完成对虚拟机的 *** 作（例如开机）。简而言之，FDM依赖hostd，如果hostd失效了，FDM也会暂停工作。

vCenter是企业中虚拟架构的集中管理平台，HA虽然不依赖它运转，但是在组建HA cluster的时候必须通过vCenter来发起。它的主要作用是，在主机上安装HA的Agent（指FDM和hostd agent），在Cluster配置更改的时候通知各主机。

Master和Slave

ESX4的时候，节点分成Primary和Secondary，最先加入cluster的5个节点成为Primary，并各自存有一份AAM Database。

vSphere 5对此进行了简化。现在不再有Primary和Secondary的概念了，取而代之的是Master和Slave。一个Cluster中只有一台Master，其余都是Slave。

Master的作用是管理整个集群，作为集群的主要管理者，它监控虚拟机的运行状态，判断某一个主机是否宕机，它监控每个VM的位置，并判断VM是否需要在其他主机上重启。对于一个集群来说，Master是其上所有虚拟机的“主人”。

在哪里可以看出主机是否Master？参见下图

没有Master的集群就会群龙无首，群龙无首的集群就fail了。

当Master失效时怎么办？集群不能没有Master，因此Master的选举会马上被触发。

Master的选举

选举会在以下情况被触发：

HA创建时；

Master宕机；

Master处于isolated或者集群出现了partitioned状态；

Master被置于维护状态或Standby状态；

集群被重新配置时；

Master和vCenter失去了联系；

选举需要15秒时间。选举通过UDP协议（端口8182）进行。

选举的规则是：拥有最多的datastore的主机当选。如果主机拥有的datastore一样多，那么Managed Objective ID号最大的那台主机当选。

(注：这里的最大不是数值最大，而是从左向右比较依次比较每一位上的数字的大小，例如99就比100大，因为第一位的数字首先比较，9大于1）

Master伸张其主权

当选后，新的master会伸张其主人的权力，试图接管所有datastore。

Q: 如何接管？（或者说怎样才算接管了datastore）

A: 通过锁定(lock)一个文件的方式，这个文件存在每个datastore上，名字叫“protectedlist”

该文件的位置是：

//vSphere-HA//protectedlist

这个文件里面存放的是受HA保护的VM列表。

若Master坏掉，则其lock会过期，新当选的master就可以接管这个文件，并重新上锁。

Master还负责监控Slave的状态，如果发现slave不响应其心跳，则会判断是否要重启slave上的虚拟机。

Slave之间是不相互通信的，除了选举Master的时候。

如何应对数据库CPU打满？最优解在这里

阿里云数据库

2020-04-26 16:48·字数:4996·阅读:129

如何用好数据库，调校数据库使其发挥最优的性能？

如何快速诊断和应对各种原因导致的突发数据库性能问题？

如何以最低资源成本满足业务需求？

这些复杂的运维难题最优解到底是什么？

今天（4月22日）15:00数据库自治服务DAS重磅发布会

现场为你揭晓答案！

数据库自动驾驶时代一触即发点击这里

即可预约直播

今天提前为大家揭秘数据库自治服务DAS的一个创新功能 —— AutoScale，基于数据库实例的实时性能数据作为输入，由DAS完成流量异常发现、合理数据库规格建议和合理磁盘容量建议，使数据库服务具备自动扩展存储和计算资源的能力。

01背 景

为业务应用选择一个合适的数据库规格，是每个数据库运维同学都会经常面临的一个问题。若规格选的过大，会产生资源浪费；若规格选的过小，计算性能不足会影响业务。

通常情况下，运维同学会采用业务平稳运行状态下，CPU可处于合理水位（例如50%以下）的一个规格（如4核CPU配8G内存）并配一个相对富余的磁盘规格（如200G）。

然而在数据库应用运维同学的日常生活里，线上应用流量突增导致数据库资源打满的情况时有发生，而引发这类问题的场景可能多种多样：

1、新业务上线，对业务流量预估不足，导致资源打满，如新上线的应用接入了大量的引流，或基础流量比较大的平台上线了一个新特性功能。

2、不可预知的流量，如突发的舆论热点带来的临时流量，或某个网红引发的限时抢购、即兴话题等。

3、一些平时运行频次不高，但又偶发集中式访问，如每日一次的上班打卡场景，或每周执行几次的财务核算业务。这类业务场景平时业务压力不高，虽已知会存在访问高峰，但为节省资源而通常不会分配较高的规格。

当上述业务场景突发计算资源不足状况时，通常会让运维同学措手不及，严重影响业务，如何应对“数据库资源打满”是运维同学常常被挑战的问题之一。

在数据库场景下，资源打满可分为计算资源和存储资源两大类，其主要表现：

1、计算资源打满，主要表现为CPU资源利用率达到100%，当前规格下的计算能力不足以应对；

2、存储资源打满，主要表现为磁盘空间使用率达到100%，数据库写入的数据量达到当前规格下的磁盘空间限制，导致业务无法写入新数据；

针对上述两类问题，数据库自治服务 DAS 进行了服务创新，使数据库服务具备自动扩展存储和计算资源的技术能力，应对上述的问题。

DAS AutoScale基于数据库实例的实时性能数据作为输入，由DAS完成流量异常发现、合理数据库规格建议和合理磁盘容量建议，使数据库服务具备自动扩展存储和计算资源的能力。

接下来，本文将对DAS AutoScale服务的架构进行详细的介绍，包括技术挑战、解决方案和关键技术。

02技术挑战

计算节点规格调整是数据库优化的一种常用手段，尽管计算资源规格只涉及到CPU和内存，但在生产环境进行规格变配的影响还是不容忽视，将涉及数据迁移、HA切换、Proxy切换等 *** 作，对业务也会产生影响。

业务有突发流量时，计算资源通常会变得紧张甚至出现CPU达到100%的情况。通常情况下，这种情况会通过扩容数据库规格的方式来解决问题，同时DBA在准备扩容方案时会至少思考如下三个问题：

1扩容是否能解决资源不足的问题？

2何时应该进行扩容？

3如何扩容，规格该如何选择？

解决这三个问题，DAS同样面临如下三个方面挑战：

21 挑战一：如何判别扩容是否能够解决问题？

在数据库场景下，CPU打满只是一个计算资源不足的表征，导致这个现象的根因多样，解法也同样各异。例如业务流量激增，当前规格的资源确实不能够满足计算需求，在合适的时机点，d性扩容是一个好的选择，再如出现了大量的慢SQL，慢SQL堵塞任务队列，且占用了大量的计算资源等，此时资深的数据库管理员首先想到的是紧急SQL限流，而不是扩容。在感知到实例资源不足时，DAS同样需要从错综复杂的问题中抽丝剥茧定位根因，基于根因做出明智的决策，是限流，是扩容，还是其它。

22 挑战二：如何选择合适的扩容时机和扩容方式？

对于应急扩容时机，选择的好坏与紧急情况的判断准确与否密切相关。“紧急”告警发出过于频繁，会导致实例频繁的高规格扩容，产生不必要的费用支出；“紧急”告警发出稍晚，业务受到突发情况影响的时间就会相对较长，对业务会产生影响，甚至引发业务故障。在实时监控的场景下，当我们面临一个突发的异常点时，很难预判下一时刻是否还会异常。因此，是否需要应急告警变得比较难以决断。

对于扩容方式，通常有两种方式，分别是通过增加只读节点的水平扩容，以及通过改变实例自身规格的垂直扩容。

其中，水平扩容适用于读流量较多，而写流量较少的场景，但传统数据库需要搬迁数据来搭建只读节点，而搬迁过程中主节点新产生的数据还存在增量同步更新的问题，会导致创建新节点比较慢。

垂直扩容则是在现有规格基础上进行升级，其一般流程为先对备库做升级，然后主备切换，再对新备库做规格升级，通过这样的流程来降低对业务的影响，但是备库升级后切换主库时依然存在数据同步和数据延迟的问题。因此，在什么条件下选择哪种扩容方式也需要依据当前实例的具体流量来进行确定。

23 挑战三：如何选择合适的计算规格？

在数据库场景下，实例变更一次规格涉及多项管控运维 *** 作。以物理机部署的数据库变更规格为例，一次规格变更 *** 作通常会涉及数据文件搬迁、cgroup隔离重新分配、流量代理节点切换、主备节点切换等 *** 作步骤；而基于Docker部署的数据库规格变更则更为复杂，会额外增加Docker镜像生成、Ecs机器选择、规格库存等微服务相关的流程。因此，选择合适的规格可有效地避免规格变更的次数，为业务节省宝贵的时间。

当CPU已经是100%的时候，升配一个规格将会面临两种情况：第一种是升配之后，计算资源负载下降并且业务流量平稳；第二种是升配之后，CPU依然是100%，并且流量因为规格提升后计算能力增强而提升。

第一种情况，是比较理想的情况，也是预期扩容后应该出现的效果，但是第二种情况也是非常常见的情形，由于升配之后的规格依然不能承载当前的业务流量容量，而导致资源依然不足，并且仍在影响业务。如何利用数据库运行时的信息选择一个合适的高配规格是将直接影响升配的有效性。

03解决方案

针对上述提到的三项技术挑战，下面从DAS AutoScale服务的产品能力、解决方案、核心技术这三个方面进行解读，其中涉及RDS和PolarDB两种数据库服务，以及存储自动扩容和规格自动变更两个功能，最后以一个案例进一步具体说明。

31 能力介绍

在产品能力上，目前DAS AutoScale服务针对阿里云RDS数据库和PolarDB数据提供存储自动扩容服务和规格自动变配服务。

其中，针对即将达到用户已购买规格上限的实例，DAS存储自动扩容服务可以进行磁盘空间预扩容，避免出现因数据库磁盘满而影响用户业务的发生。在该服务中，用户可自主配置扩容的阈值比例，也可以采用DAS服务预先提供的90%规格上界的阈值配置，当触发磁盘空间自动扩容事件后，DAS会对该实例的磁盘进行扩容；

针对需要变更实例规格的数据库实例，DAS规格自动变配服务可进行计算资源的调整，用更符合用户业务负载的计算资源来处理应用请求，在该服务中，用户可自主配置业务负载流量的突发程度和持续时间，并可以指定规格变配的最大配置以及变配之后是否回缩到原始规格。

在用户交互层面，DAS AutoScale主要采用消息通知的方式展示具体的进度以及任务状态，其中主要包括异常触发事件、规格建议和管控任务状态三部分。异常触发事件用于通知用户触发变配任务，规格建议将针对存储扩容和规格变配的原始规格和目标值进行说明，而管控任务状态则将反馈AutoScale任务的具体进展和执行状态。

32 方案介绍

为了实现上面介绍的具体能力，DAS AutoScale实现了一套完整的数据闭环，如图1：

图1 DAS AutoScale数据闭环

在该闭环中，包含性能采集模块、决策中心、算法模型、规格建议模块、管控执行模块和任务跟踪模块，各模块的具体功能如下：

性能采集模块负责对实例进行实时性能数据采集，涉及数据库的多项性能指标信息、规格配置信息、实例运行会话信息等；

决策中心模块则会根据当前性能数据、实例会话列表数据等信息进行全局判断，以解决挑战一的问题。例如可通过SQL限流来解决当前计算资源不足的问题则会采取限流处理；若确实为突增的业务流量，则会继续进行AutoScale服务流程；

算法模型是整个DAS AutoScale服务的核心模块，负责对数据库实例的业务负载异常检测和容量规格模型推荐进行计算，进而解决挑战二和挑战三的具体问题；

规格建议校验模块将产出具体建议，并针对数据库实例的部署类型和实际运行环境进行适配，并与当前区域的可售卖规格进行二次校验，确保的建议能够顺利在管控侧进行执行；

管控模块负责按照产出的规格建议进行分发执行；

状态跟踪模块则用于衡量和跟踪规格变更前后数据库实例上的性能变化情况；

接下来，将分别针对DAS AutoScale支持的存储扩容和规格变配两个业务场景进行展开介绍。

!图2 存储扩容方案](>

以上就是关于如何在2个HA节点上分别运行不同的Oracle数据库实例全部的内容，包括:如何在2个HA节点上分别运行不同的Oracle数据库实例、hadoop的ha模式出现的原因、什么是高可用性(HA)HA是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！