在使用PostgreSQL高可用集群过程中发现一个很难解决的问题,先记录在这里. 我们知道在PG流复制集群中,如果主库死掉了,备库要提升为主库有两种方法: 1)pg_ctl promote 2)创建对应的trigger文件:touch " " /var/lib/pgsql/10/data/.tfile 但是这两种方法会使得备库提升为主的同时,时间线会+1,在pg_wal中可以看到: -bash-4.1$ ls -rlth pg_wal/ total 49M drwx------ pos

结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备库和主库的延迟时间能够控制在毫秒级.物理复制只能复制整个实例. 逻辑复制也成为选择性复制,可以做到基于表级别的复制,选择需要逻辑复制的表,而不是复制实例上的所有数据库的表,10版本不支持内置的逻辑复制,通常使用第三方逻辑复制. WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,但

一.需求 疑问?Oracle最大保护模式下,dg备库出现问题,影响主库吗? 我们都知道Oracle最大保护模式的意思是oracle不允许数据丢失,1条记录都不行! 那么备库有问题? oracle主库还能读写吗? 二.测试 2.1 现有情况查询 --查询保护模式:最大保护 SQL> select name,dbid,database_role,protection_mode from v$database; NAME DBID DATABASE_ROLE PROTECTION_MODE -----

本文主要描述Oracle备库日志与主库日志之间有gap,切主库这部分gap的归档日志已经删除或丢失,如何在不重建备库的情况下,恢复备库. 欢迎转载,请注明作者.出处. 作者:张正 blog:http://space.itpub.net/26355921  QQ:176036317 如有疑问,欢迎联系. 在dataguard环境中,由于主库archivelog丢失,且尚未同步到standby,问如何在避免 重建standby的情况下来将standby恢复成功的. 下面是我的测试过程,供参考! —-

DG之主库.备库切换 一．开库与关库顺序 开库顺序 先启备库,再启主库(启动监听.打开告警日志) 关库顺序 先关主库,再关备库 二．主备库切换 1.操作过程一览 步骤1:启动备库.监听.告警: 步骤2:启动主库.监听.告警: 步骤3:主库(bj)查询信息 SQL>selectname,dbid,database_role,protection_mode from v$database; 步骤4:备库(sh)上做recover SQL>recovermanaged standby databas

DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与DG备库接受归档有什么关系? 1. 实验环境: 类别 主库 备库 软件版本 11.2.0.4.0 11.2.0.4.0 是否RAC 否 否 Db_name ENMO Db_unique_name ENMO dage Service_name ENMO dage Listener.ora 192.168

今天遇到一个数据库同步问题,主库被关闭,重启主库后,备库不能正常同步主库数据.只有当手动切换归档日志的时候,备库才能和主库一致. 这个问题的解决方法: 重启备库,重新应用归档日志. 操作步骤如下: //关闭备库监听器 lsnrctl stop //关闭备库 sqlplus / as sysdba alter database recover managed standby database cancel; shutdown immediate; //启动备库 startup nomount; a

背景 在mysql主备环境下,主备同步过程如下,主库更新产生binlog, 备库io线程拉取主库binlog生成relay log.备库sql线程执行relay log从而保持和主库同步. 理论上主库有更新时,备库都存在延迟,且延迟时间为备库执行时间+网络传输时间即t4-t2. 那么mysql是怎么来计算备库延迟的? 先来看show slave status中的一些信息 io线程拉取主库binlog的位置 Master_Log_File: mysql-bin.000001 Read_Master

背景 在mysql主备环境下,主备同步过程如下,主库更新产生binlog, 备库io线程拉取主库binlog生成relay log.备库sql线程执行relay log从而保持和主库同步. 理论上主库有更新时,备库都存在延迟,且延迟时间为备库执行时间+网络传输时间即t4-t2. 那么mysql是怎么来计算备库延迟的? 先来看show slave status中的一些信息,io线程拉取主库binlog的位置: Master_Log_File: mysql-bin.000001 Read_Maste

1.使用快照先决条件:主备库开启闪回功能 2.把备库转为快照库 DGMGRL> convert database satest to SNAPSHOT STANDBY; Converting database "satest" to a Snapshot Standby database, please wait... Database "satest" converted successfully 3.把快照库转回物理备库 DGMGRL> conver

故障描述: 主库异常下线,需要将备库强制启动为主库,切断日志时提示需要介质恢复,执行介质恢复后,再激活日志即可进行切换 1.  执行alter database recover managed standby database finish force; 发现需要恢复介质 2.  确认归档日志目录中是否存在最近的日志 检查发现该目录中只有最开始建立时的3个日志,没有1月22日调整时的日志,检查发现是因为计划任务中有删除归档日志这个任务导致,至少说明后面的日志都已应用 3.  确认归档日志文件是否

一.参数说明 [1] db_file_name_convert db_file_name_convert 主数据库和备用数据库的数据文件转换目录对映(如果两数据库的目录结构不一样),如果有多个对映,逐一指明对映关系. 格式: *.db_file_name_convert= 主数据库数据文件目录,备用数据库数据文件目录 [2] log_file_name_convert 指明主数据库和备用数据库的log文件转换目录对映. 格式: *. log_file_name_convert=主数据库log目录

切换顺序: 先主库后备库 --查看主库可切换状态: SQL> select switchover_status from v$database; SWITCHOVER_STATUS -------------------- TO STANDBY --执行切换命令转换primary到physical standby: SQL>alter database commit to switchover to physical standby; 如果查询到的可转换状态为SESSION ACTIVE,则切

问题现象 在使用shutdown abort停DataGuard备库后.备库不能open,报ORA-01196错误. 详细例如以下: 发现一备库不能应用日志.查看备库日志没发现报错.怀疑是备库应用日志服务停止,于是尝试重新启动备库. 可能由于备库是读业务比較繁忙,在shutdown immediate关闭备库时等时间过长,于是使用了shutdown abort命令: 但后面在启动备库时发生报错,造成数据文件损坏,控制文件和数据文件的scn号不一致. --启动备库时报错 SQL> startup

搭建oracle 级联DG 现有架构:physical standby 一主二备,在此基础上,在主库下新建备库standby3.级联备库cascade 数据库版本 11.2.0.4 db_name=prod db为主库,dg1为备库,dg2为级联备库:DB_UNIQUE_NAME DATABASE_ROLEdb primary 10.100.12.10 dg1 standby1 10.100.12.11 dg2 standby2 10.100.12.12 三个库的LOG_FILE_NAME_CO

资料来自官方网站: https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/managing-oracle-data-guard-physical-standby-databases.html#GUID-B1C66720-3EA6-45A3-986E-6E510381EC79 在19c之前,oracle Data Guard备用数据库上不能执行DML操作,但是,从19c开始备库就可以进行DML操作了:个人觉得象征意思

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

DG搭建时,官方文档手册有明确提到要设置数据库为force_logging,防止有nologging操作日志记录不全导致备库应用时出现问题. 虽然是老生常谈的安装规范,但现实中总会遇到不遵守规范的场景,最近就在某客户现场遇到一则这样的案例,因为DG主库设置force_logging晚于DG搭建,导致备库出现坏块,使用dbv检查就表现为DBV-201错误. 下面我们来模拟下这个场景,同时演示下具体修复过程: 1.准备实验环境 2.构造故障场景 3.解决故障 1.准备实验环境 主库确认没有开启for

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复 环境: OS: CentOS 6.5 DB: Oracle 10.2.0.5 1.主备库环境 主库: SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database; DBID NAME LOG_MODE OPEN_MODE DB_UNIQUE_NAME DATABASE_ROLE

在物理DG主备库切换时遇到ORA-16139: media recovery required错误 SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY * ERROR at line 1: ORA-16139: media recovery required 解决办法: --如果报ORA-16139: media recovery required,