问题描述:情形是当主库真正出现异常之后,才会执行的操作,那么我们执行过failover 之后,如何在重新构建DG,这里我们利用flashback database来重构.模拟前主库要开启闪回区,否则要重新搭建DG了 1.由于主库已经不可访问,下面所有的操作都在备库完成,先取消实时同步 SQL> alter database recover managed standby database cancel; 2.强制取消redo接收 3.确认一下备库 4.切换为物理主库,然后open,确认一下切换成

Oracle DG测试failover和后续恢复报告 一.概述 二.验证过程: 2.1 A库异常关闭 2.2 B库进行failover切换为新主库 2.3 要求C库成为新主库的备库 2.4 要求A库成为新主库的备库 三.结论 一.概述 本文是针对在DG灾备环境进行failover操作以及后续恢复的报告. 我这里的测试环境是: 数据库版本:Oracle 11.2.0.4 Site A:主库 db_unique_name=jyzhao Site B:备库(实时应用)db_unique_name=my

------------------方法1在主库上使用备份的进行恢复丢失的归档日志-------------------------1.发现主库备份后删除了归档,但是这些归档从库还没应用,也没有传到从库从库应用的最新的归档日志为592SQL> connect / as sysdbaConnected.SQL> Select Max(t.SEQUENCE#) From V$archived_Log t; MAX(T.SEQUENCE#)---------------- 592 主库的归档日志SQ

​ 案例说明: KingbaseES V8R3集群failover时两个cluster都会触发,但只有一个cluster会调用脚本去执行真正的切换流程,另一个有对应的打印,但不会调用脚本,只是走相关的流程去修改状态. 那么你需要确认一点,到底是主库还是备库的cluster在执行脚本,关键字:failover_stream.sh ,看cluster.log中有没有这个的名称.本案例通过主库系统宕机,分析了failover 切换过程. 适用版本: KingbaseES V8R3 集群节点状态信息:

Oracle Dataguard中,角色转换包含两类:Switchover和Failover.上文<Oracle Dataguard之switchover>中,我们已经谈过了switchover,本文将谈谈failover以及如何将failed primary database转换为physical standby database. failover 一. 主库挂掉  在这里我们杀掉lgwr进程模拟实例崩溃. [oracle@node2 ~]$ ps -ef | grep lgwr   --

[DATAGUARD]物理dg的failover切换(六) 一.1  BLOG文档结构图 一.2  前言部分 一.2.1  导读 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① 物理dg的failover切换演练过程 ② 物理dg管理和维护的一些sql ③ 利用duplicate搭建物理dg ④ 注意:本篇BLOG中代码部分需要特别关注的地方我都用黄色背景和红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33,t

PostgreSQL 三节点集群故障模拟及恢复 (postgreSQL9.5.1) 正常状态: 10.2.208.10:node1:master 10.2.208.11:node2:standby1同步 10.2.208.12:node3:standby2异步 10.2.208.13:node4:备用机 故障模拟及恢复 1 主库故障 1 停止主库(master)[M]服务[10.2.208.10] pg_ctl –D ../data stop –m fast 2 更改S1的postgresql.

背景: 最近后端基于mongo的项目越来越多,MySQL基于冷备份+binlog可以恢复至任意时间点,那么mongo是否有同样的功能呢?经过调研发现可以通过dump+oplog可以实现粒度更细致的恢复. 官方文档关于oplog的说明 : <a class="mongo-link" href="https://docs.mongodb.com/manual/core/replica-set-oplog/"></a> 以下是实验步骤,附脚本内容.

FAILOVER详细步骤 1.Flush主库任何未传输的redo到目标备库 如果primary可以mount,则可以flush任何主库的未传输redo到备库,如果操作成功返回,则可以保证failover的零数据丢失. 1)确保standby数据库启用日志应用 2)mount primary数据库,执行以下SQL语句,命令等待standby应用redo完成后返回. SQL> alter system flush redo to target_db_unique_name; 如果成功返回,则转第5步

1.增量备份: 增量数据是从上次全量备份之后,更新的新数据,对于mysql来说,binlog日志就是mysql的增量数据: (1)按天进行备份: 周一00点全量备份 周二00点全量备份 ...... 01.sql.gz 02.sql.gz ...... 周一增量备份 周二增量备份 ...... mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.index mysql-bin.000004 mysql-bin.000005 m

生产环境搭建高可用Harbor(包括恢复演练实操) 前言 因资源成本问题,本Harbor高可用架构为最小开销方案,如果资源充足,可以将PG.Redis全部使用使用云厂商集群模式. 同时为了配置简单,并没用使用keepalived与heartbeat等高可用开源组件. 准备工作 阿里云SLB 阿里云ECS 共享存储 Redis 最小实例SLB 2c4g 俩台 阿里云NFS 阿里云Redis 操作系统为Ubuntu18.04,在俩台ECS上搭建主从PG,如果不想用阿里云redis,也可以使用ECS搭

场景7  Data Guard 官方文档 :Oracle Data Guard Concepts and Administration 用于数据容灾,通过主备库同步(主库将redo日志传送到备库,一个主库可对应多个备库(30)),实现异地容灾 1. 构建测试库 2. 构建读写分离的环境 3. 实现滚动升级 4. 数据备份 数据容灾 : 1. 基于存储复制 2. 基于逻辑卷复制(镜像) 3. 基于应用(redo log) redo log : DML/DDL, 记录数据块变化,用于recovery

一.DataGuard总体结构 总体目标 1.   描述计划和非计划停机的不同因数 2.   DataGuard的主要组件 3.   物理以及逻辑DataGuard的异同 4.   建立DataGuard的好处 5.   在高可用环境下HA的用处 数据损失原因 1.   硬件与系统故障 2.   人为错误 3.   计算机病毒 4.   软件故障 5.   自然灾难        具调查表明,目前一般情况下,数据损失的主要原因是硬件故障和人为的原因而不是自然灾害等. 系统当机 计划当机 1.  

Oracle 10gR2 Dataguard搭建(非duplicate方式) 我的实验环境: 源生产库(主库): IP地址:192.168.1.30 Oracle 10.2.0.5 单实例 新DG库(备库): IP地址:192.168.1.31 Oracle 10.2.0.5 单实例 1.源生产库开启归档 2.rman备份源生产库 3.修改源生产库参数 4.配置tnsnames.ora 5.同步密码文件 6.配置pfile文件 7.创建备库控制文件 8.还原备库 9.开启日志应用 10.swit

背景 在上一篇「MySQL高可用复制管理工具 —— Orchestrator介绍」中大致介绍了Orchestrator的功能.配置和部署,当然最详细的说明可以查阅官方文档.本文开始对Orchestrator的各方面进行测试和说明. 测试说明 环境介绍 服务器环境: 三台服务器 :MySQL实例(3306是orch的后端数据库,3307是MySQL主从架构「开启GTID」) Master : Slave : Slave : :hosts(etc/hosts): 192.168.163.131 te

一.环境说明 主库:10.110.96.88 备库:10.110.96.87 数据库实例:gisc 二.主库操作 1.开启force logging ALTER DATABASE FORCE LOGGING; 2.开启日志归档 a.查看日志归档是否开启 ARCHIVE LOG LIST; b.如果没有开始归档则开启 SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; 3.创建stan

一.DataGuard总体结构 总体目标 1.   描述计划和非计划停机的不同因数 2.   DataGuard的主要组件 3.   物理以及逻辑DataGuard的异同 4.   建立DataGuard的好处 5.   在高可用环境下HA的用处 数据损失原因 1.   硬件与系统故障 2.   人为错误 3.   计算机病毒 4.   软件故障 5.   自然灾难        具调查表明,目前一般情况下,数据损失的主要原因是硬件故障和人为的原因而不是自然灾害等. 系统当机 计划当机 1.  

V$LOG 显示CONTROLFILE记录的LOG FILE信息. 列名          描述 GROUP#        日志组号 THREAD#       日志线程号 SEQUENCE#     日志序列号 BYTES         日志文件大小(单位bytes) BLOCKSIZE     11.2新增字段,logfile的块大小 MEMBERS       日志组成员数 ARCHIVED      归档状态(YES/NO) STATUS        日志状态: ·UNUSED :

一.MHA简介 作者简介 松信嘉範: MySQL/Linux专家 2001年索尼公司入职 2001年开始使用oracle 2004年开始使用MySQL 2006年9月-2010年8月MySQL从事顾问 2010年-2012年 DeNA 2012年~至今 Facebook 软件简介 MHA能够在较短的时间内实现自动故障检测和故障转移,通常在10-30秒以内;在复制框架中,MHA能够很好地解决复制过程中的数据一致性问题,由于不需要在现有的replication中添加额外的服务器,仅需要一个manag

一.概述 本文将介绍mysql的MM+Keepalived方案.该方案由两个mysql服务器组成,这两个mysql互为主备.其中一台主作为写服务器,另一台主作为读服务器.通过keepalived软件管理写vip,当承担写服务器的mysql出现故障时,将写vip漂移到读服务器上,实现高可用. 二.节点介绍 本次实验采用2台虚拟机,操作系统版本Centos6.10,mysql版本5.7.25 node1    10.40.16.61  主库  提供写服务 node2    10.40.16.62