• DG 物理Standby角色转换


    角色转换前的准备工作

    • 检查各数据库的初始化参数,主要确认对不同角色相关的初始化参数都进行了正确的配置
    • 确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式
    • 确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
    • 检查主备数据库的standby redo log文件(最大保护和最高可用性模式)
    • 确保standby 数据库的RAC 实例只有一个处于open 状态。(对于rac 结构的standby 数据库,在角色转换时只能有一个实例startup。其它rac 实例必须统统shutdown,待角色转换结束后再startup)

    切换又分了:switchover和failover,前者是无损切换,不会丢失数据,而后者则有可能会丢失数据,并且切换后原primary 数据库也不再是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同。

    一、物理Standby的switchover

    1. 检查是否支持switchover操作 --主数据库操作

      查询v$database视图的switchover_status列

    SQL> select switchover_status from v$database;

    如果该列值为"To Standby"则表示Primary数据库支持转换为standby角色,如果显示的是Session active说明还其他的session存在关闭所有打开的session或者database设置为mount状态,如果都不是这些值就需要重新查检一下Data Guard配置。

    2. 启动switchover --主数据库操作

    首先将Primary转换为standby的角色:

    SQL> alter database commit to switchover to physical standby;

    3. 重启动到时mount --原主数据库操作

    SQL> shutdown immediate
    
    SQL> startup mount

    4. 检查是否支持switchover操作 -待转换standby数据库操作
    等原Primary切换为standby角色之后,检查待转换的standby数据库switchover_status列是否支持角色转换

    SQL> select switchover_status from v$database;

    5. 转换角色到primary --待转换standby数据库操作

    SQL> alter database commit to switchover to primary;

    注意:待转换的物理standby可以处于mount模式或open read only模式,但不能处于open read write模式。
    6. 完成转换,打开新的primary数据库

    SQL> alter database open;

    注意:如果数据库处于open read-only模式的话,需要先shutdown然后直接startup即可

    7. 验证数据库

    二、物理standby的failover

    需要注意以下几点:

    • failover之后,原primary数据库默认不再是data guard配置的一部分
    • 多数据情况下,其它物理standby数据库不直接参与failover的过程
    • 某些情况下,新的primary数据库配置之后,需要重新创建其它所有的standby数据库
    • 如果待转换角色的standby 处于maximum protection 或maximum availability 模式的话,归档日志应该是连续存在的,这种情况下你可以直接从第3 步执行,否则建议你按照操作步骤从第1 步开始执行。

    一般情况下failover 都是表示primary 数据库瘫痪,最起码也是起不来了,因此这种类型的切换基本上不需要primary 数据库做什么操作。所以下列步骤中如果有提到primary 和standby 执行的,只是建议你如果primary还可以用,那就执行一下,即使它能用你却不执行,也没关系,不影响standby 数据库的切换

    1. 检查归档文件是否连续

    SQL> select thread#,low_sequence#,High_sequence# from v$archive_gap;

    如果返回的有记录,按照列出的记录号复制对应的归档文件到行转换的standby服务器,必须确保所有已生成的归档文件均已存在于standby服务器,不然可能会数据不一致造成转换时报错

    文件复制之后,通过下列命令将其加入数据字典:

    SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';

    2. 检查归档文件是否完整

      分别在primary/standby执行下列语句:

    SQL> select distince thread#,max(sequence#) over(partition by thread#) a from v$archived_log;

    如果primary与standby最大序号不一致,则必须将多出的序号对应的归档文件复制到待转换的standby服务器。

    3. 启动failover

    SQL> alter database recover managed standby database finish force;

    FORCE关键字将会停止当前活动的RFS进程,以便立刻执行failover。

    4. 切换物理standby角色为primary

    SQL> alter database commit to switchover to primary;

    5. 启动新的primary数据库

    如果当前数据库已mount,直接open即可,如果处于read-only模式,需要首先shutdown immediate然后直接startup.

    SQL> alter database open;

    角色转换工作完成。剩下的是补救措施(针对原primary 数据库),由于此时primary 数据库已经不再是data guard 配置的一部分,我们需要做的就是尝试看看能否恢复原primary 数据库,将其改造为新的standby服务器。具体操作方式可以分为二类:1.重建2.备份恢复。

  • 相关阅读:
    docker学习
    Http协议
    docker常用命令
    TCP协议
    HTTPS揭秘
    biz
    幂次方
    hashmap如何得到数组下标
    sql 逗号取交集
    海明码
  • 原文地址:https://www.cnblogs.com/landexia/p/2621561.html
Copyright © 2020-2023  润新知