OCP备份每日全备调度失败，需要手动关闭归档模式才可成功

OceanBase 技术问题
#1

【 使用环境 】 测试环境
【 OB or 其他组件 】
【 使用版本 】OCP 4.2.1.8 业务集群：4.3.3.0
【问题描述】OCP备份每日全备调度失败，报错：连接 ume_test 执行 ALTER SYSTEM ARCHIVELOG 失败，错误信息: (conn=3221655355) Already in ARCHIVELOG mode
每次都需要手动关闭归档模式（ALTER SYSTEM NOARCHIVELOG；）才可备份成功，请问如何规避此问题？
【复现路径】
【附件及日志】

image
image1686×897 45.1 KB

image
image1606×535 53.5 KB

#3

你是不是当前日志备份到路径跟备份策略里面设置的不一致？
可以尝试把日志备份先暂停下，OCP上手动发起一次备份，让他自动把日志备份的路径修改成一致。

#4

成功备份一次后，再次备份就失败 了，报错：连接 ume_test 执行 ALTER SYSTEM ARCHIVELOG 失败，错误信息: (conn=3221655355) Already in ARCHIVELOG mode。
这时手动执行： ALTER SYSTEM NOARCHIVELOG；
然后重试就备份成功了 ，每次都需要手动执行一次修改为非归档模式

#5

麻烦下载任务日志发下

#6
  1. 问题分析
  • 备份原理与归档模式关联：在 OceanBase 中，备份机制与数据库的归档模式紧密相关。全备调度通常需要考虑数据库的日志和数据状态。当处于归档模式时，数据库会记录所有的事务日志用于数据恢复和一致性维护等目的。然而，备份过程可能会受到归档日志的影响。
  • 可能的冲突点：在全备调度过程中，可能由于备份工具对归档日志的处理不当，或者备份策略与归档模式的某些设置不兼容，导致备份操作无法顺利完成。例如，备份过程可能需要对数据库进行某种程度的锁定或者数据冻结操作，而归档模式下的日志写入和应用可能会干扰这种操作。
  1. 手动关闭归档模式以成功备份的潜在风险
  • 数据恢复风险：归档模式的主要目的之一是为了在发生故障时能够完整地恢复数据。关闭归档模式后进行备份，虽然备份操作可能成功，但在后续需要进行数据恢复时，可能会因为缺少部分归档日志而无法恢复到最新的状态或者可能会丢失一些数据。
  • 一致性风险：在关闭归档模式期间，如果有事务正在进行或者数据库状态正在发生变化，可能会导致数据不一致的情况。特别是对于一些需要严格保证数据一致性的业务场景，这种风险可能会带来严重的后果。
  1. 解决方案探索
  • 检查备份策略与归档模式兼容性：
    • 深入研究 OCP 备份工具的备份策略文档，了解在归档模式下全备调度应该遵循的步骤和参数设置。可能需要调整备份策略，例如，设置备份工具对归档日志的处理方式，如在备份开始前先对归档日志进行备份或者冻结，然后再进行数据备份。
    • 检查归档模式的参数设置，如日志归档的频率、归档日志的存储位置和大小限制等。这些参数可能会影响备份操作的顺利进行。例如，如果归档日志的存储位置空间不足，可能会导致备份过程中无法正确处理日志，从而失败。
  • 升级或修复备份工具及相关组件：
    • 确认 OCP 备份工具的版本是否是最新的。如果不是，升级到最新版本，因为新版本可能已经修复了与归档模式备份相关的问题。
    • 检查 OceanBase 数据库本身以及与备份相关的组件（如备份代理等）是否存在已知的漏洞或者问题。如果发现问题，可以通过安装补丁或者更新组件来解决。
  • 监控与优化备份环境：
    • 在备份过程中，加强对数据库系统和备份环境的监控。可以使用 OceanBase 自带的监控工具或者第三方监控软件，重点关注数据库的负载、日志写入速度、备份进度等指标。通过监控发现可能导致备份失败的异常情况，如备份期间数据库负载过高或者日志归档出现异常。
    • 根据监控结果，优化备份环境。例如，如果发现备份期间数据库负载过高是由于其他业务操作导致的，可以调整业务操作的时间或者分配更多的资源给备份操作。
#7

这个问题有进展了吗？