OBCP第八章 OB运维、监控与异常处理-常见异常处理

简介: OBCP第八章 OB运维、监控与异常处理-常见异常处理

问题排查概述:数据库连接问题排查

在遇到连接问题时,需要清楚整个系统的架构,对整个连接链路进行排查。通常情况下应用连接到数据库的完整链路是从应用服务器到 OBProxy 再到 OB 集群,此外还可能涉及负载均衡、DNS 解析、网络等。一般连接问题如连接失败、连接断开、连接报错异常等问题排查,从以下两个方向入手:


OBProxy和应用之间的连接异常

OBProxy和OBServer之间连接异常

排查方式:

首先可以通过尝试连接,缩小问题链路的范围:


通过OBProxy连接数据库


直连OceanBase数据库


查看报错信息,常见报错类型有:


数据库事务状态异常,OB主动断开连接


应用端连接报错。如果报错信息涉及Get connection timeout及连接数,应查看应用是否有流量突增或DB连接数设置;如果报错信息涉及Communications link failure,连接可能被异常中断


问题排查概述:OBServer进程异常退出

当正在运行的OBServer异常退出时,通过操作系统(ps -ef命令)查询不到 OBServer进程的存在,此时,如果不是硬件损坏或者操作系统的问题,可尝试拉起observer进程作为应急手段;OBServer 在退出时会生成core dump文件,可以此为依据进行 OBServer 的异常退出根因分析(版本不同,core dump排查的方法不同)



Lbt后的地址信息可以填入 addr2line -pCfe $observer $symbol_addr 命令中的$symbol_addr以获得CRAS原始信息和线程栈信息。( addr2line 可用于V2.2.76 版本之后)


问题排查概述:合并问题排查


进行合并问题排查时,首先要确定当前集群中的合并配置项,确定当前的合并状态,然后根据查询得到的情况,对不同的合并问题类型进行分析后再寻找根因


确认合并配置项:


需确定enable_manual_merge,zone_merge_concurrency,zone_merge_order,

enable_merge_by_turn,major_freeze_duty_time,enable_auto_leader_switch等配置项

确定合并状态:

SELECT * FROM __all_zone WHERE name = "frozen_version" or name = "last_merged_version";
SELECT * FROM __all_zone WHERE name = "merge_status"; 



根据上面查询到的信息,可以将问题归于未合并问题、合并超时问题、合并慢问题,并做具体的分析

问题排查概述:合并问题排查

合并问题细分

判断步骤

未合并问题

ZONE未合并:SELECT * FROM __all_zone WHERE name = "global_broadcast_version" or name =


"broadcast_version"; 如果broadcast_version 等于 last_merged_version,且 last_merged_version 落后于


global_broadcast_version,说明 RootService 没有发起相关 Zone 的合并


副本未合并:SELECT * FROM __all_virtual_meta_table WHERE data_version != 25 LIMIT 10; 查询哪个主机上的


副本为合并(假设当前要合并的目标版本是25)

合并超时问题

定位未合并到指定版本的 partition


判断该 partition 的合并任务是否在执行中:SELECT * FROM __all_virtual_sys_task_status;


如果该 partition 没有调度合并任务,判断该 partition 的最新的转储 sstable 的 snapshot_version 有没有推过freeze_info 点,如果没有推过 freeze_info 点,说明转储有问题

合并慢问题

通过SELECT /*+ query_timeout(10000000)*/* FROM __all_virtual_partition_sstable_merge_info WHERE


merge_type = “major merge” and version = “<merge_version>” ORDER BY merge_cost_time desc


limit 5; 语句找到合并耗时最多的几个 partition 来具体分析


通过表 __all_virtual_partition_sstable_merge_info 查看宏块重用情况


查看合并开始时间是否合理

问题排查概述:事务问题排查

在运行 OceanBase 的过程中,OceanBase 会执行数据库事务,在执行后将执行返回的结果返回给发出请求的客户端;如果事务执行失败或者异常,会产生事务报错,常见的事务报错大体分为两大类:


事务执行过程中对客户端展示的错误


通过日志或内存表查询发现的环境异常


排查方式:


通过__all_virtual_trans_stat表可以查询到当前还未结束的事务上下文状态


进一步根据 trans_id搜索对应时间段内的 observer.log 日志,找到相应事务报错信息:


可以根据错误标识位(4038)判断问题是否属于事务回滚类、执行超时类、等待锁超时类等类型

问题排查概述:事务问题排查


问题排查概述:副本迁移问题排查

在进行副本迁移问题排查时,首先确定副本迁移是否不符合预期情况,然后再根据具体的迁移情况进行处理

确定副本迁移是否存在问题步骤:

确定问题partition:

SELECT * FROM __all_unit WHERE migrate_from_svr_ip != "" or 
migrate_from_svr_port !="";

查看RootService调动副本迁移任务的状态是否符合预期:


在 RootService 所在机器 grep “root_balancer” rootservice.log 获取线程号 LWP_ID,获取线程号后去grep “LWP_ID” rootservice.log 看 RS 的负载均衡线程正在执行的任务


检查系统虚拟表: __all_virtual_sys_task_status

检查存储层调度的状态:

SELECT * FROM __all_virtual_sys_task_status;

问题排查概述:副本迁移问题排查

副本迁移问题细分

步骤

迁入目标端磁盘满

排查有迁移异常的 server:


SELECT * FROM __all_server WHERE block_migrate_in_time > 0 \G临时设置block_migrate_in_time解除block状态:


ALTER system SET migration_disable_time = "600s";


查询磁盘使用空间

迁移过慢问题

查看迁移相关配置项:


server_data_copy_out_concurrency ,该项为单个节点迁出数据的最大并发数


server_data_copy_in_concurrency ,该项为单个节点迁入数据的最大并发数


sys_bkgd_io_low_percentage 该项表示 sys_io_percent 的下限,如果下限太低则可能导 致合并的 I/O 很慢,可以通过适当调大这个值来调大 I/O (检查 I/O 是否达到磁盘瓶颈)


sys_bkgd_net_percentage 该项表示后端网络带宽占用(检查网络配置)

迁移失败问题

确认常见错误码。

检查是否存在硬件问题。

检查内核问题。

相关文章
|
1月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第26天】Prometheus与Grafana是智能运维中的强大组合,前者是开源的系统监控和警报工具,后者是数据可视化平台。Prometheus具备时间序列数据库、多维数据模型、PromQL查询语言等特性,而Grafana支持多数据源、丰富的可视化选项和告警功能。两者结合可实现实时监控、灵活告警和高度定制化的仪表板,广泛应用于服务器、应用和数据库的监控。
254 3
|
3天前
|
Prometheus 运维 监控
Prometheus+Grafana+NodeExporter:构建出色的Linux监控解决方案,让你的运维更轻松
本文介绍如何使用 Prometheus + Grafana + Node Exporter 搭建 Linux 主机监控系统。Prometheus 负责收集和存储指标数据,Grafana 用于可视化展示,Node Exporter 则采集主机的性能数据。通过 Docker 容器化部署,简化安装配置过程。完成安装后,配置 Prometheus 抓取节点数据,并在 Grafana 中添加数据源及导入仪表盘模板,实现对 Linux 主机的全面监控。整个过程简单易行,帮助运维人员轻松掌握系统状态。
35 3
|
1月前
|
消息中间件 数据采集 运维
一份运维监控的终极秘籍!监控不到位,宕机两行泪
【10月更文挑战第25天】监控指标的采集分为基础监控和业务监控。基础监控涉及CPU、内存、磁盘等硬件和网络信息,而业务监控则关注服务运行状态。常见的监控数据采集方法包括日志、JMX、REST、OpenMetrics等。Google SRE提出的四个黄金指标——错误、延迟、流量和饱和度,为监控提供了重要指导。错误监控关注系统和业务错误;延迟监控关注服务响应时间;流量监控关注系统和服务的访问量;饱和度监控关注服务利用率。这些指标有助于及时发现和定位故障。
152 1
|
2月前
|
运维 Prometheus 监控
运维之眼:监控的艺术与实践
在信息技术飞速发展的今天,运维监控已成为保障系统稳定运行的关键。本文将探讨运维监控的重要性,介绍常用的监控工具和方法,并通过实际案例分析,展示如何有效地实施监控策略,以确保系统的高可用性和性能。
|
2月前
|
运维 监控 测试技术
构建高效运维体系:从监控到自动化的实践之路
【10月更文挑战第9天】 在当今信息技术飞速发展的时代,运维作为保障系统稳定性与效率的关键角色,正面临前所未有的挑战。本文将探讨如何通过构建一个高效的运维体系来应对这些挑战,包括监控系统的搭建、自动化工具的应用以及故障应急处理机制的制定。我们将结合具体案例,分析这些措施如何帮助提升系统的可靠性和运维团队的工作效率。
62 1
|
2月前
|
运维 监控 安全
构建高效运维体系:从监控到自动化的全面指南在当今数字化时代,运维作为保障系统稳定性和效率的重要环节,其重要性不言而喻。本文将深入探讨如何构建一个高效的运维体系,从监控系统的搭建到自动化运维的实施,旨在为读者提供一套完整的解决方案。
本文详细介绍了高效运维体系的构建过程,包括监控系统的选择与部署、日志分析的方法、性能优化的策略以及自动化运维工具的应用。通过对这些关键环节的深入剖析,帮助运维人员提升系统的可靠性和响应速度,降低人工干预成本,实现业务的快速发展和稳定运行。
|
1月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第27天】在智能运维中,Prometheus和Grafana的组合已成为监控和告警体系的事实标准。Prometheus负责数据收集和存储,支持灵活的查询语言PromQL;Grafana提供数据的可视化展示和告警功能。本文介绍如何配置Prometheus监控目标、Grafana数据源及告警规则,帮助运维团队实时监控系统状态,确保稳定性和可靠性。
213 0
|
2月前
|
运维 Linux Apache
,自动化运维成为现代IT基础设施的关键部分。Puppet是一款强大的自动化运维工具
【10月更文挑战第7天】随着云计算和容器化技术的发展,自动化运维成为现代IT基础设施的关键部分。Puppet是一款强大的自动化运维工具,通过定义资源状态和关系,确保系统始终处于期望配置状态。本文介绍Puppet的基本概念、安装配置及使用示例,帮助读者快速掌握Puppet,实现高效自动化运维。
68 4
|
27天前
|
机器学习/深度学习 运维 监控
智能化运维:从自动化到AIOps的演进之路####
本文深入探讨了IT运维领域如何由传统手工操作逐步迈向高度自动化,并进一步向智能化运维(AIOps)转型的过程。不同于常规摘要仅概述内容要点,本摘要将直接引入一个核心观点:随着云计算、大数据及人工智能技术的飞速发展,智能化运维已成为提升企业IT系统稳定性与效率的关键驱动力。文章详细阐述了自动化工具的应用现状、面临的挑战以及AIOps如何通过预测性分析和智能决策支持,实现运维工作的质变,引领读者思考未来运维模式的发展趋势。 ####
|
27天前
|
机器学习/深度学习 数据采集 人工智能
智能化运维:从自动化到AIOps的演进与实践####
本文探讨了智能运维(AIOps)的崛起背景,深入分析了其核心概念、关键技术、应用场景及面临的挑战,并对比了传统IT运维模式,揭示了AIOps如何引领运维管理向更高效、智能的方向迈进。通过实际案例分析,展示了AIOps在不同行业中的应用成效,为读者提供了对未来智能运维趋势的洞察与思考。 ####
68 1

热门文章

最新文章