租户备份失败

【 使用环境 】生产环境 or 测试环境 生产
【 OB or 其他组件 】 4.0
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于开源文档检索的论坛助手开放试用!如需论坛小助手参与答复,请输入 [@论坛小助手]

  1. ob 4.0 环境下,调用租户下 备份恢复菜单执行租户级别备份,失败,报错代码
    2024-08-13 10:40:38.370 INFO 1057922 — [pool-manual-subtask-executor14,d5670a36ebe24368,f316a8682939] c.o.o.c.t.e.runner.JavaSubtaskRunner : Run subtask, id=25735700, context=Context{parallelIdx=-1, stringMap={ob_tenant_id=1052, tenant_id=2014596, checkBeforeDataBackup=true, tenant_name=core_bt, ob_version=4.2.1.7-107030032024062709, startClusterCompact=false, task_instance_id=14845619, task_operation=execute, ob_cluster_id=1666082002, startLogBackup=true, backupDim=TENANT, cluster_id=27, storageBaseInfo=******, tenantName=core_bt, backupMode=physical, triggerType=BACKUP_NOW, latest_execution_start_time=2024-08-13T10:40:38.332+08:00, sub_task_instance_name=Start log backup if necessary, backupNow=true, sub_task_instance_id=25735700, dataBackupMode=FULL_BACKUP, obClusterName=obclu_test_ncore2}, listMap={}}, executor=10.241.223.148

2024-08-13 10:40:38.425 INFO 1057922 — [pool-manual-sub

2024-08-13 10:40:38.540 WARN 1057922 — [pool-manual-subtask-executor14,d5670a36ebe24368,f316a8682939] c.o.ocp.obsdk.connector.ConnectTemplate : [obsdk] update failed, sql:[ALTER SYSTEM ARCHIVELOG], error message:[PreparedStatementCallback; SQL [ALTER SYSTEM ARCHIVELOG]; (conn=1639483) Already in ARCHIVELOG mode; ne

2.咨询同事, 原因是 租户归档模式没有开启,临时规避方法 在备份任务,日志备份,开启备份

3.我的问题,这个租户的归档应该是一直开启状态,应该是碰到异常中断了,我的问题是
这种异常中断的归档,如何通过Sql和日志定位异常原因,请给出实操手册,谢谢

针对您遇到的租户备份失败问题,特别是报错显示已处于归档模式但实际上归档并未开启的情况,我们可以使用 obdiag 工具来帮助您收集必要的日志信息,以便进一步定位问题。

日志采集场景: 数据备份问题
日志采集命令: obdiag gather scene run --scene=observer.backup

该命令将会收集与备份相关的日志和配置信息,包括但不限于归档模式的状态和配置,这将有助于我们理解为什么系统报告处于归档模式但实际上归档并未启用。

此外,为了更准确地定位问题,请提供以下信息:

  1. 您是否尝试过手动开启或关闭归档模式?如果是,请提供具体的命令和执行时间。
  2. 备份失败的具体错误信息是什么?请提供完整的错误消息。
  3. 您是否有修改过与归档相关的任何配置项?如果有,请详细说明。
  4. 是否有其他操作或事件发生在备份失败前后?例如系统升级、硬件故障等。
  5. 您可以提供备份失败时的系统时间吗?这有助于我们从日志中找到相关线索。

附上敏捷诊断工具 obdiag 使用帮助链接

select

a.tenant_id,

a.tenant_name,

a.tenant_type,

a.log_mode,

b.status,

b.path

from

DBA_OB_TENANTS a,

CDB_OB_ARCHIVELOG b

where

a.tenant_id = b.tenant_id;

看log_mode和status字段。

status字段说明,可能参考https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001050237

1 个赞

可以参考下
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000818724
image

1 个赞

看log_mode和status字段。

log_mode =NOARCHIVELOG

status=STOP

能否查看stop 原因?

CDB_OB_BACKUP_JOB_HISTORY 或 DBA_OB_BACKUP_JOB_HISTORY

select * from CDB_OB_BACKUP_JOB_HISTORY where status=‘FAILED’

SELECT * FROM DBA_OB_BACKUP_JOB_HISTORY where status=‘FAILED’

->我是0813 昨天备份失败的,我理解是归档任务没发起,所以db不会记录这两个表CDB_OB_BACKUP_JOB_HISTORY 或 DBA_OB_BACKUP_JOB_HISTORY,所以当我查询昨天的备份失败记录,查询结果为空,

能告诉我怎么检查Db 归档停下的原因么?

再向您确认几个问题:

  1. 您提到归档模式被设置为 NOARCHIVELOG 并且状态为 STOP,请问您是在哪个时刻注意到这些设置的
  2. 在归档模式变为 NOARCHIVELOG 之前,是否进行了任何系统操作或者配置更改
  3. 您能否提供最近一次归档模式从 ARCHIVELOG 变更为 NOARCHIVELOG 的具体时间
  4. 除了归档模式的变化外,您是否观察到系统层面的任何异常或者警告信息

暂时没有,所以想问问,有无方法可以查询?

要定位归档模式为何从 ARCHIVELOG 变更为 NOARCHIVELOG 以及状态为何变为 STOP,您可以尝试以下几个步骤:

1. 查看归档模式变更记录

OceanBase 并不直接记录归档模式的变更历史,但是可以通过查看系统日志来间接了解归档模式的变更情况。您可以通过以下方式来查找相关信息:

方法一:检查系统日志

  • 登录到 OceanBase 集群:使用管理员权限登录到 OceanBase 集群。
  • 查看系统日志:通过查看系统日志文件来寻找归档模式变更的相关记录。通常情况下,归档模式的变更会在系统日志中留下记录。日志文件的位置取决于您的部署环境,一般位于 /home/admin/oceanbase/log/ 目录下。

方法二:使用 obdiag 工具

  • 运行 obdiag:使用 obdiag 工具来收集与归档模式相关的日志和配置信息。这可以帮助您找到归档模式变更的时间点以及可能的原因。
  • 命令示例
    obdiag gather scene run --scene=observer.log_archive
    

2. 检查归档任务状态

  • 查询归档任务状态:使用 DBA_OB_ARCHIVE_DEST 视图来查看归档目的端的状态。
    SELECT * FROM DBA_OB_ARCHIVE_DEST WHERE STATUS = 'STOP';
    
  • 查看归档任务历史:使用 DBA_OB_ARCHIVE_HISTORY 视图来查看归档任务的历史记录。
    SELECT * FROM DBA_OB_ARCHIVE_HISTORY WHERE STATUS = 'STOP';
    

3. 查看归档参数

  • 查看归档参数:使用 DBA_OB_PARAMETERS 视图来查看与归档相关的参数设置。
    SELECT * FROM DBA_OB_PARAMETERS WHERE PARAMETER_NAME LIKE '%ARCHIVE%';
    

4. 检查系统告警

  • 查看系统告警:使用 DBA_OB_ALERT_HISTORY 视图来查看系统告警信息,这有助于了解是否有与归档模式变更相关的告警。
    SELECT * FROM DBA_OB_ALERT_HISTORY WHERE MESSAGE LIKE '%ARCHIVE%';
    

5. 分析归档任务日志

  • 分析归档任务日志:归档任务的日志文件通常位于 /home/admin/oceanbase/log/ 目录下,您可以查看这些日志文件来了解归档任务的状态变化。

6. 联系技术支持

如果您仍然无法确定归档模式为何变为 NOARCHIVELOG 以及状态为何变为 STOP,建议联系 OceanBase 的技术支持团队以获得进一步的帮助。他们可以提供更深入的技术支持和解决方案。

具体信息可参考以下文档:

(小助手的答复已结束,如未能解决您的问题,请继续提问并等待其他同学的回复,谢谢!)

DBA_OB_TENANTS视图中的log_mode字段为:NOARCHIVELOG, 说明当前租户处于非日志归档模式。

  1. V4版本,日志归档是针对租户而言的,请确保租户没有弄错? 确定该租户以前开启了日志归档?

  2. 正常情况下,没有人为干预,不太可能从ARCHIVELOG 变为 NOARCHIVELOG,可以尝试在OceanBase的日志目录下执行如下命令:
    grep -i “alter system archivelog” *
    grep -i “alter system noarchivelog” *
    看看有没有日志归档模式变换的相关日志。

检查错误日志:

/home/admin/oceanbase/log/observer.log
grep -i “alter system archivelog” *
grep -i “alter system noarchivelog” *

没有发现,可能observer.log日志保留时间为2天,

我感觉是clog 磁盘空间不够用导致的,
我应该如何查询该租户每天产生的日志量大小?是否有SQL 可以查询?

没有直接的视图记录每天的clog量,可以使用SQL或者脚本计算,你参考下这篇文章
OceanBase 社区dmqtk5_gaMTIwMjU5NTAzNC4xNzE0OTc1MTY1_ga_T35KTM57DZ*MTcyMzcwMDAxNy4xMzUuMS4xNzIzNzAwNTI2LjI2LjAuMA…

谢谢