3回答
容灾切换时,在数据库层面主要是要保证可用性,对于核心交易系统来说对重要的是数据的一致性校验。针对容灾切换,主要有以下几个建议和经验:
- 通常使用集中存储技术进行容灾切换时,存储层面都提供了RPO的记录,最后的更新时间。可以通过存储系统的复制管理工具和相关的API即可以实现;
- 数据库启动之后需要通过应用手段进行校验,存储切换、数据库切换、应用切换的流程建议通过自动化切换平台进行,将切换过程的日志进行详细记录并进行展示;
- 网络层的切换是切换经常发生问题的阶段,需要针对各种类型的接入点进行详细的切换流程的监控,判断应用启动之后的服务状态;
- 建议形成切换的各种操作手册,并定期进行切换演练;
OceanStor BCManager eReplication容灾产品,了解一下,支持一键式容灾保护、恢复,简化客户操作,提高操作效率。
支持Oracle、DB2、SQLServer等多种应用,及VMWare、FusionCompute虚拟化平台的容灾保护恢复。
产品文档:
兼容性列表:
技术原理:
https://support.huawei.com/enterprise/zh/doc/EDOC1000090710?section=l004
1.容灾切换主要涉及到网络层、应用层和存储层的切换,切换过程中制定好完整的流程和体系可以保障切换的顺利完成。如:切换流程、切换涉及到的步骤、切换对象、容灾演练(这个环节非常重要),建议切换前进行演练。
2.存储和数据库的切换,常见问题:
(1)生产站点和灾备站点数据不一致:
- 第一个可能的原因是生产站点未将redo日志发送给容灾站点,l解决方案 p登录dgmgrl,使用show database pripcc命令,排查生产站点的状态为TRANSPORT-ON,不是TRANSPORT-OFF。参考命令:EDIT DATABASE <database name> SET STATE = <state> [WITH APPLY INSTANCE = <instance name>]; p使用show database dripcc LogShipping确认容灾站点数据库的LogShipping属性为ON p使用show database pripcc LogXptStatus确认redo传输服务的状态,如果状态错误,则根据错误原因和信息进行修复。
- 第二个可能的原因是,容灾站点未apply生产站点传输过来的redo日志;l解决方案 p确认容灾站点数据库未异常,如果异常,则查看alert日志,确认Redo应用停止的原因。 p登录dgmgrl,使用show database dripcc命令,排查容灾站点的状态为APPLY-ON,不是APPLY-OFF。参考命令:EDIT DATABASE <database name> SET STATE = <state> [WITH APPLY INSTANCE = <instance name>];p使用show database dripcc delaymins确认该值没有设置为过大。 (2)容灾端切换为主用端失败 ,原因是DGMGRL客户端没法自动拉起容灾端实例。解决方案:确认StaticConnectIdentifer配置正确: SHOW INSTANCE VERBOSE 'instance_name' ON DATABASE db_unique_name; p确认StaticConnectIdentifer对应的服务已经注册到监听器中,且是静态注册方式:lsnrctl status LISTENER (3)Apply停止且无法恢复 如果容灾端未提前创建好表空间目录,或者没有权限创建目录,则会导致容灾端没法正常应用Redo数据,最终导致Apply进程停止。可通过查看alert日志确认是否为该原因,日志中会有如下类似错误:
ORA-01186: file 5 failed verification tests
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/opt/oracle/product/11gR2/db/dbs/UNNAMED00005'
解决方案
p以sys用户登录生产端数据库,执行如下命令查看当前数据文件:select file#,name from v$datafile;
p以sys用户登录容灾端数据库,执行如下命令查看当前数据文件:select file#,name from v$datafile;
p此时容灾端将会有以UNNAMEXXX格式的数据文件,通过如下方式重新创建进行恢复。
n执行命令关闭文件自动管理功能:alter database set STANDBY_FILE_MANAGEMENT=MANUAL;
n使用如下命令依次重新创建数据文件,正确的数据文件如今参考生产端的位置:alter database create datafile '/opt/oracle/product/11gR2/db/dbs/UNNAMED00007' as '/opt/oradata/db_uidb/rdata12';
n执行命令重新开启文件自动管理功能:alter database set STANDBY_FILE_MANAGEMENT=AUTO;
n执行命令恢复容灾端数据库:recover automatic standby database;
p容灾端数据库恢复完成后,重新登录dgmgrl控制台,恢复apply状态:edit database dripcc set state = 'APPLY-ON';
注意:临时表空间文件不会自动同步,需要手工添加进行同步