资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/物理备库failover切换的3种方法

物理备库failover切换的3种方法

IT那活儿 / 911人阅读
物理备库failover切换的3种方法

点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！


  

从oracle 12.1开始引入了新的SQL语法，用于物理备库的failover切换。

在使用过程严禁混合使用新旧两种用法。除非在切换过程中有明确的提示。

本文将介绍分别使用新旧SQL语法执行failover切换的两种操作步骤以及使用data guard broker的切换方法。


failover前准备工作

1. 检查主备库dataguard参数是否正常，如果主库还可用。
LOG_ARCHIVE_DEST_1

LOG_ARCHIVE_DEST_2

LOG_ARCHIVE_CONFIG

FAL_SERVER

STANDBY_FILE_MANAGEMENT

db_file_name_convert

log_file_name_convert

enabled_PDBs_on_standby

SQL>select group#,thread#,bytes/1024/1024 MM from v$log;

SQL>select member from v$logfile;

SQL>select group#,thread#,bytes/1024/1024 MM,status from v$standby_log;
2. 检查主备库同步是否正常，如果主库还可用。
select inst_id,dbid,name,db_unique_name,open_mode,PROTECTION_MODE,database_role,failover_STATUS,DATAGUARD_BROKER from gv$database;
select * from v$dataguard_stats;
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
3. 检查主备库alert日志是否有异常输出。
4. 检查主备库的监听状态、listener.ora、tnsnames.ora文件。
5. 执行切换前，备库最好是处于mounted状态，提高切换速度。
6. 确认主备库的补丁一致，以免切换到备库以后，遇到不可遇知的BUG。
7. 与业务侧沟通好操作时间。

8. 确认备库的硬件(CPU、内存、IO)性能能够支撑切换后的应用连接。

使用旧语法执行failover到Physical Standby Database

1. 如果主库可以mounted，则将主库中所有未到备库的归档日志和redo刷新到备库。
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
确保在目标备库上启用了redo apply。
  • 如果主库不能mounted，则转到步骤2。
  • 如果此步骤没报错，请转至步骤5。
  • 如果时间紧急，不能等待完成，请继续步骤2。

2. 查询备库上的v$archivd_log视图，以获取redo的最大sequence号。

SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
然后把主库的最新归档日志传输到备库，然后注册该文件。
SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE filespec1;
3. 然后备库上的v$archived_GAP视图，在确定备库上是否存在gap。
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

  • 如果有gap,请将gap的归档日志从主库传输到备库，然后在备库中注册文件。

SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE filespec1;
4. 重复执行第2、3步骤，直至没有gap，如果此问题不能解决，则在failover期间可能会丢失一些数据。
5. 在目标备库上执行以下SQL语句,取消redo apply。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
6. 在目标备库执行如下SQL语句应用完成所有接收到的归档日志。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
  • 如果此步骤完成并且没有任何错误，请继续执行步骤7。
  • 如果发生错误，如某些归档日志未应用。请尝试解决错误并重新执行该步骤语句。然后再继续执行一步。
  • 如果存在步骤2、步骤3和步骤4中未解决的gap。则会报错。
  • 如果无法解决错误。则仍可以通过在目标备库上执行以下SQL语句来执行故障转移（会丢失一些数据）：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
7. 确认目标备库已经准备好切换成主库。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
-----------------
TO PRIMARY
1 row selected
TO PRIMARY 或 SESSIONS ACTIVE 的值均表示目标备库已准备好切换到主库。如果返回结果不是这两个值，请确认redo apply是否已经取消。
8. 在目标备库上执行以下SQL语句将物理备库切换成主库。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
  • 如果步骤7中返回结果是"TO PRIMARY"，则SQL语句中可以不写“WITH SESSION SHUTDOWN”；
  • 如果命令执行不成功，请转到步骤9。

9. open新主库：

SQL> ALTER DATABASE OPEN;
10. 建议立即对新主库执行完整备份。
11. 如果redo apply在dataguard配置中的其它物理备库上停止，请重新启动它。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

12. FAILOVER后，有3种方法将原主库转换为备库：

A、FLASHBACK DATABSE
B、RMAN备份
C、重新搭建备库

原主库转换为备库后，可以执行switchover将其恢复成主库。

使用新语法执行failover到Physical Standby Database

1. 如果主库可以mounted，则将主库中所有未到备库的归档日志和redo刷新到备库：
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
  • 如果此步骤没报错，请转至步骤5；
  • 如果时间紧急，不能等待完成，请继续步骤2。

2. 查询备库上的v$archivd_log视图，以获取redo的最大sequence号。

SQL>SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
然后把主库的最新归档日志传输到备库，然后注册该文件：
SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE filespec1;
3. 然后备库上的v$archived_GAP视图，在确定备库上是否存在gap。
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
  • 如果有gap,请将gap的归档日志从主库传输到备库，然后在备库中注册文件。
SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE filespec1;
4. 重复执行第2、3步骤，直至没有gap，如果此问题不能解决，则在failover期间可能会丢失一些数据。
5. 在备库上执行以下SQL语句：
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
6. 在目标备库执行failover
SQL>ALTER DATABASE FAILOVER TO targe_db_name;
  • 如果此步骤完成并且没有任何错误，请继续执行步骤10。
7. 如果发生错误，请尝试解决错误的原因，然后重新执行failover语句：
  • 如果成功，请转到步骤10；
  • 如果仍有错误，而且与原主库有关，请转到步骤8；
  • 如果仍有错误，但与原主库无关，请转到步骤9。

8. 忽略与原主库交互时遇到的任何故障，并在可能的情况下继续进行failover。

SQL>ALTER DATABASE FAILOVER TO targe_db_name FORCE；
  • 如果命令执行成功，请转到步骤10；
  • 如果命令执行不成功，请转到步骤9。

9. 执行数据丢失故障转移：

  • 如果无法解决报错，则仍可以通过在备库上执行以下SQL语句来执行故障转移（并丢失一些数据。）
SQL>ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
10. 打开新主库：
SQL>ALTER DATABASE OPEN;
11. 建议立即对新主库执行完整备份。
12. 如果redo apply在dataguard配置中的其它物理备库上停止，请重新启动它。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

13. FAILOVER后，有3种方法将原主库转换为备库：

A、FLASHBACK DATABSE
B、RMAN备份
C、重新搭建备库

原主库转换为备库后，可以执行switchover将其恢复成主库。

使用data guard broker执行failover到Physical Standby Database

1. 使用dg broker检查主备库的同步状态是否正常

show database verbose 目标主库;
show database verbose 目标备库;
show configuration verbose;
返回结果中有报错，一定要处理完成才能继续下面的切换步骤。
2. 使用dg broker执行failover(主备库皆可执行)
failover to 备库名称。


本文作者：聂文峰（上海新炬王翦团队）

本文来源：“IT那活儿”公众号

云服务器 GPU云服务器 在家赚钱的十种方法 数据迁移的四种方法 Error的2种方法 js缓存的几种方法

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129267.html

相关文章

  • 19C DG Broker配置和测试

    19C DG Broker配置和测试 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...

    IT那活儿 评论0 收藏2941

  • OceanBase迁移服务：向分布式架构升级的直接路径

    摘要：年月日，迁移服务解决方案在城市峰会中正式发布。迁移服务向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案迁移服务，简称。 2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践...

    KaltZK 评论0 收藏0

  • OceanBase迁移服务：向分布式架构升级的直接路径

    摘要：年月日，迁移服务解决方案在城市峰会中正式发布。迁移服务向分布式架构升级的直接路径基于上述问题和挑战，同时经过蚂蚁十年数据库架构升级的先进经验，蚂蚁金服为客户打造了这款一站式数据迁移解决方案迁移服务，简称。 2019年1月4日，OceanBase迁移服务解决方案在ATEC城市峰会中正式发布。蚂蚁金服资深技术专家师文汇和技术专家韩谷悦共同分享了OceanBase迁移服务的重要特性和业务实践...

    gnehc 评论0 收藏0

  • DG备库读写测试方案

    DG备库读写测试方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...

    IT那活儿 评论0 收藏856

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<