环境:RHEL 6.5 + Oracle GI 11.2.0.4 + Oracle DB 11.2.0.4 Primary RAC(2 nodes) + Standby RAC(2 nodes)
一个DG环境中只有两种角色:Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换,切换也分两种:Switchover和Failover,关于角色切换需要注意以下几点:
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库,然后在备用数据库上应用这些重做数据,以确保数据的一致性。
但是,如果去查v$archive_dest_status,就会发现问题,说有可解决的GAP:
DG的主备角色转换分为:Switchover和Failover。Switchover适用于某些场合,需要将备库转为主库,Failover则是在主库故障无法使用情况下,将备库提升为主库。
Oracle DataGuard;简称DG。是由一个Primary Database(主库)和一个或者多个Standby Database(备库)组成。对Oracle来说;本身不能提高性能。通过数据冗余来保护数据。由Primary Database对外提供服务;用户操作在Primary Database上操作;其操作的数据库Redo Log或者Archive log通过网络传输到Standby Database。Standby Database在重做这些日志。从而实现Primary Database和Standby Database数据同步。
data guard的主要功能就是作为备库来同步主库的数据变化,一般使用中物理standby使用的比较多。data guard显示威力的一个场景就是swithover了,即主备切换。这种切换方式执行时间很短,能够在一些灾难场景中极大的提高系统的可用性和稳定性。 自己在本地的环境中搭建了一套data guard的环境,开始比较生疏,切换中碰到了不少的问题,最后搭建完成,把切换中的一些细节信息都总结起来,整理成了一个初步的脚本。能够很方便的实现swithover 这个脚本适用于物理standby,在本地环境中
测试环境:RHEL 5.4 + Oracle 11.2.0.3 DG 现象:起初是在使用DG Broker进行switchover切换测试时,报错ORA-16775,提示有可能有数据丢失,不允许switchover.
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节,也是最关键的处理过程。 假设你半夜正在睡觉,被报警电话惊醒,得知某个服务器产生了故障宕机,在这种情况下,我们大体会有下面的处理流程: 1)检查原来的节点是否可用,需要查看ILO和存储,是否存在异常 2)如果原来的节点可以重启,可以尽量马上恢复业务,然后分析根本原因,是否是硬件老化,硬件故障导致,如果发现问题影响较大,可以使用Switchover 3)如果原来的节点无法重启,这个时候需要考虑Failover,如果在同机房可以直接替
假设SwitchA和SwitchB两台交换机组成堆叠系统,现SwitchA发生了故障,需要使用SwitchC替换掉SwitchA。建议参照如下步骤进行替换操作。
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了。这个工具就不那么需要了,我们完全可以脱离开这些工具来直观的使用命令行的方式来维护,这个观点也没错,不过从与时俱进的角度来看,本来能够让你更轻松的一个工具,如果不用实在是太可惜了。 DG Broker在数据库端需要启用一个后台进程dmon来维护,这个后台进程启动,需要设置dg_broker_start为true即可,如果要停止,只需
场景1:数据库SWITCHOVER切换之前停止OGG CLASSIC EXTRACT进程,切换之后修改OGG访问新主库,OGG EXTRACT进程RBA不移动也不会报错.
在数据库环境中,一主一备是比较传统的使用方式,在灾难发生的时候,可以灵活的切换主备角色,依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤,一主一备似乎还是不够稳妥,如果主备出现问题,如果有另外一个备库还是有可选的余地,这种情况不是不可能发生,正是因为核心业务的需要还是需要保证数据的安全。 很多场景下,一主两备会保持这样的场景,一主一备在同一个区域内,这样在出现问题的时候方便切换,如果区域出现故障,可以保证异地的机房可以顺利承接服务。 比如下面的这种方式是比较传统的一主一备的方式。因为是在1
背景: 环境未配置DG Broker,手工切换ADG,19c也要比11g时代的切换更简单。 使用自己的测试环境,具体可参见: 单实例Primary快速搭建Standby RAC参考手册(19.16 ADG)
杨廷琨,云和恩墨CTO,Oracle ACED,ITPUB Oracle 数据库管理版版主 ,人称"杨长老”,十数年如一日坚持进行Oracle技术研究与写作,号称"Oracle的百科全书”,迄今已经在自己的博客上发表了超过3000篇技术文章。与 Eygle 共同主编出版了多本《Oracle DBA手记》系列图书。
Oracle 12cR2中有一个不错的特性,那就是Active Data Guard会话保留,原本的叫法是Preserving Active Data Guard Application Connections 怎么理解呢,比如在Active Data Guard上的连接会话,在switchover的过程中会话连接会始终保持不会中断。这一点听起来就很有特点,能够提高用户体验度,而且是一种相对透明的方式。 到底怎么样呢,我们来简单测试一下,先看看默认情况下的ADG会话情况,切换的过程就直接使用DG
客户的一套生产环境采用的架构是Oracle ADG + Keepalived,近期需要进行切换演练,要求我这边保障。ADG本身切换倒没啥可说的,但引入keepalived软件,就需要提前研究下这个架构。其实看了下环境配置,整体思路也非常简单,说白了就是利用keepalived软件引入一个VIP,应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
通常情况下习惯使用sqlplus命令对数据库primary以及dataguard进行switchover、failover.虽然oracle很早在10g时候就推出dg broker命令行进行快速切换,由dgmgrl对数据库状态检查、延迟检查、是否可以切换进行封装命令输出,所以可以很快捷简单检查整个主从配置和切换,个人觉得dg broker报错排除之类不是太友好,,另外dataguard切换2条命令,dgmgrl封装成一条命令,整体切换相对简单,使用dgmgrl需要配置静态监听、standby log、延迟等要求比较多,另外broker可以配合em操作,实现web化操作数据库切换。总的来dg broker操作简单,配置相对复杂(对于sqlplus进行切换来说)下面跟大家分享下dg broker以及12c一些新的变化。
参考官方文档12c:Using DBCA to Create a Data Guard Standby 12C
11g的dataguard相比于10g来说,最优越的特性应该算就是active dataguard了,这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华,而且在后台会根据需要进行数据的同步,相比于使用10g,想读数据的时候把数据库启动到read only 阶段,但这个时候不接受日志同步数据,如果需要同步数据还需要把数据库再启动到mount阶段,感觉还是比较繁琐的。 11g的active dataurad功能很强大,同时搭建的时候使用rman 的duplicate选项
Oracle RAC 11g DG Broker配置和测试 本篇在实验环境中实际配置 环境: RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC(2 nodes)+ Standby RAC(2 nodes)
VERITAS Cluster Server(VCS) connects, or clusters, multiple, independent systems into a management framework for increased availability. Each system, or node, runs its own operating system and cooperates at the software level to form a cluster. VCS links commodity hardware with intelligent software to provide application failover and control. When a node or a monitored application fails, other nodes can take predefined action to take over and bring up services elsewhere in the cluster.
最近在做的项目是智慧屏项目,用于公司的电视屏展示,它采用的技术栈是vue+js+sass,项目很多采用的都是组件化,用组件化的优点就是可复用性高,减少代码冗余,组件化的思想在开发中很常见也很重要。下面将这次项目中自己做的不足的点以及需要注意的点列举出来。感兴趣的朋友可以看看。
最近对一个统计库做了计划内的容灾切换,即主备切换。操作的过程其实还是蛮顺利的。但是灾难切换中如果出现在问题,那就是灾难中的灾难了。 按照计划对配置信息做了同步,然后使用DG Broker做了SwitchOver操作。 这一次切换速度还是蛮快,我开了几个窗口看到日志都在不断输出,角色已经替换过来了。DG Broker切换的日志如下: DGMGRL> switchover to test29; Performing switchover NOW, please wait... New primary datab
编辑手记:前文我们分享了DG 中Far Sync Instance的创建和配置,今天一起来学习当Far Sync Instance出现问题时,日志传输的情况,并介绍在配置Far Sync Instance的情况下,switchover的过程。 上文中Oracle12c DataGuard Far Sync的配置和使用简介(上)提到了Far Sync Instance的配置,配置在参数中配置了max_failure=1 alternate=log_archive_dest_3 参数。当dest_2出现问题时会
最近又试了下Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的大体思路就是,在主库我们标记一下数据状态,然后做
今天看到有一个网友提了一个问题,描述很简短 测试DG时,主库不能宕机,如何测试failover? 其实这个需求从业务层面来说是合理的,一个数据量很大的核心数据库,如果需要做灾难演练,就
对于Oracle Data Guard中的Switchover一般是计划内的操作,自己其实也处理了不少的故障,也算是轻门熟路。复杂的事情简单做,简单的事情重复做,重复的事情用心做,想必很多事情都是这个理吧。 发现很多事情虽然做了很多遍,但是每次都会有不同的体会,而这些积累下来的经验才让我们的经验更加宝贵。 一般来说Oracle的Switchover需要考虑的细节较多,大体有以下的流程。 1.在迁移之前明确目标服务器IP,发出维护公告 这个无需多说,本身就是跨部门,多部门的协调工作,说简单简单,说复杂复
dataguard broker是在dataguard使用基础上提供的一个工具,可以把原本复杂的命令控制语句集成起来,比如switchover,failover等等,可能在多个备库的情况下需要敲不少的命令,这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的,比如需要设置local_listener,需要在spfile的基础上,需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
今天在 Oracle 原厂公众号上看到了一篇描述 Oracle 21c ADG 新特性的文章,基于 PDB 级别的 ADG 可以实现自由切换,非整个 CDB 级别的 ADG 及 Switchover 十分不错,值得推荐,故分享给大家。
当用户在设备上存储了电子标签信息时,可以通过命令将电子标签信息保存到文件中。该文件既可以保存在设备的存储介质中,也可以通过FTP协议保存在FTP服务器上,还可以通过TFTP协议保存在TFTP服务器上。
1.3.2 备库切换到open状态,启用Real-time query A physical standby database instance cannot be opened if Redo Apply is active on a mounted instance of that database. Use the following SQL statements to stop Redo Apply, open a standby instance read-only, and restart Redo Apply:
今天在做一套RAC DG的switchover演练,将备库两个节点都开启时查询v$database的switchover状态报如下错误
环境:Linux + Oracle 11.2.0.1 ADG 现象:发现备库没有应用日志
徐晨亮,MySQL DBA,知数堂学员。热衷于数据库优化,自动化运维及数据库周边工具开发,对MySQL源码有一定的兴趣。 一、切换流程图: 二、核心代码: 主要实现逻辑在cluster_fail.
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。 今天来说下Oracle的DG和MySQL的方案对比,相比来说,可能这方面MySQL会单薄一些,所以文末会说下InnoDB Cluster。 在灾备的概念中,Oracle DBA喜欢叫做主备,即为Primary,Standby,而MySQL喜欢叫做主从,即为Master,Slave 首先在Oracle中,数据是基于物理复制(此处说的都是physical standby),所以对于数据库的状态和角色就很好定位,从库正常状况下是
ADG单实例搭建系列之(Active Database Duplicate Using Image Copies)
参考:http://www.cnblogs.com/jyzhao/p/4332410.html
本文比较基础,主要介绍postgresql开源高可用工具repmgr的部署和使用,初学者可以根据本文步骤一步一步做下去,废话不多说,直接进入主题,本文以两台机器为例。
我的实验环境: 源生产库(主库): IP地址:192.168.1.30 Oracle 10.2.0.5 单实例
目前遇到了一个问题,目前的是一主两备的环境,但是主库,备库中的存储空间都不足。而且硬件环境相对要老旧一些。想扩容难,系统版本老旧想升级也难。 数据库是基于10gR2,有异地灾备。但是因为10gR2的dataguard没有灾备的感觉,其实感觉和一个主库没有什么明显的差别。而且一旦发生问题,切换以后,硬件的限制瓶颈还是解决不了,所以化被动为主动,可以提前预警,提前规划和考虑。 现在是一主两备,但是备库目前的情况不容乐观,所以需要扩容一下,升级操作系统版本,目前为6U5,重新规划
很多时候,大家工作中都会有一种被动的思维,那就是能不动就不动,从求稳的角度来看无可厚非,但是从风险的角度来说,还是有待商榷的。如果存在风险,还保持原样很可能就是一个不定时炸弹。 这不手头有一套环境,按照以前的标准是根本入不了我的法眼的,但是因为是测试环境,小问题比较多,存在容灾风险,但是这么多年一直这样,也就默然接受了。 这套环境硬件配置很低,基本上和我的笔记本配置差不多,可能还略差一些,在上面跑着3个数据库实例,其中一个是11g的,2个是10g的。两个10g的数据库实例数据量都不大,几十G而已。 看起来是
1.SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=/data/u01/app/oracle/archive/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db1';
今天在琢磨几件事情,也是和工作相关。 数据灾难切换的几点认识: 在unix中可能会碰到在处理网络问题时,超时时间会远远高于linux的情况,这个时候如果尝试做failover是非常消耗时间的,而且日志没有任何输出,看不到进展,相比于linux的处理,我感觉要更简洁一些。 鉴于unix中的处理方式,我还是建议直接使用命令行来做failover,使用下面两个命令即可。 alter database recover managed standby database finish force; alter data
我这里用的是dbdeployer部署的mysql 5.7单机多实例的主从架构。 宿主机地址: 192.168.2.4 复制用的账号和密码: rsandbox rsandbox 准备给replication-manager用的账号密码: rep-manager rep-manager
第二次执行时不再提示输入yes,并且可以成功执行命令,则表示SSH对等性配置成功。
在公众号后台收到一条问题,就是h3c的75交换机如何切换主控板的主备?首先解释一下什么是主控板?如下图,这是一个典型的交换机主控板,从硬件来说,很像我们电脑的主板,上面各种单元控制着整台机器的运转。当然我们今天所讲的东西不涉及硬件,h3c有专门的命令可以进行切换。
作者简介 李真旭 Oracle ACE 专家,拥有超过10年的 Oracle 运维管理使用经验,参与过众多移动、电信、联通、银行等大型数据库交付项目,具有丰富的运维管理经验,对 Oracle 数据库管
领取专属 10元无门槛券
手把手带您无忧上云