新炬运维避坑指南连载（十九-数据库信创专题）

IT那活儿 2024-11-11

504

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

指南一分钟速览：

OceanBase 误操作删除表处置
OceanBase 业务反馈集群上脚本效率下降处置
OceanBase ocp密码箱没有proxyro@sys的密码，导致已有proxy无法纳管集群处置
OceanBase 磁盘使用率忽然升高问题分析
OceanBase 某租户CPU 100%问题
OceanBase oms全量迁移卡住问题分析
OceanBase oms迁移数据中全量组件异常中断问题分析
OceanBase 数据库主机宕机问题分析
goldendb 部分计算节点偶发性连接失败问题分析
goldendb 备库主备DN切换后备dn宕机解决

一

OceanBase误操作删除表处置

1.1 现象

（OceanBase）业务误操作删除表。

1.2 处置过程

1）检查集群回收站是否设置（OB官方不太建议开启）

2）确认备份和归档是否正常

3）依赖备份和归档进行单表恢复到一个新的临时租户（3.x）

4）通过obdump/datax/oms/outfile的方式把数据导回原库

1.3 新炬建议

1）及时沟通与透明处理

在发现误操作导致数据丢失时，必须立即通知相关的业务方和管理部门，以便他们能及时知晓事件情况并参与决策。这不仅有助于透明处理问题，还能使得在恢复数据的过程中得到更有效的支持和资源协调。此外，透明的沟通也能帮助业务方理解问题的严重性，避免将来再次发生类似的误操作。

2）权限管理的原则：最小化授权

权限管理是防止误操作的重要手段之一。应定期审查和调整数据库用户的权限，确保每个用户只拥有其工作所需的最小权限。

特别是对生产环境中的关键操作权限，应严格控制并设定必要的审批流程。通过最小化授权，减少高权限用户的数量和权限范围，可以有效降低误操作的可能性，并提高系统的安全性。

3）备份与归档策略的健全性

本次故障处理依赖备份和归档进行了数据恢复，这说明了健全的备份与归档策略的重要性。定期检查备份和归档的执行情况，确保它们能够在数据丢失时有效恢复是至关重要的。备份策略应覆盖所有关键数据，并且要定期进行恢复测试，验证备份数据的完整性和可用性，确保在紧急情况下能够快速恢复。

4）多种数据恢复手段的准备与熟练掌握

在本次数据恢复过程中，使用了obdump、datax、oms、outfile等多种工具将数据导回原库。运维团队应熟练掌握这些数据恢复工具和方法，并根据不同的场景选择最合适的工具进行操作。

二

OceanBase集群执行脚本效率下降

2.1 现象

业务反馈其他数据量类似的集群一个脚本大概执行3/4分钟，这个集群执行要5/6分钟，因数据处理慢，导致业务当天处理不完数据。

2.2 处置过程

业务反馈其他数据量类似的集群一个脚本大概执行3/4分钟，这个集群执行要5/6分钟，因数据处理慢，导致业务当天处理不完数据，手工介入处理。

从gv$plan_cache_plan_stat看到计划虽然比其他集群多几条，但是效率还算正常。

检查了audit信息，该集群对于这个sql，每一条sql都生成了一个planid，这些plan_id在plan_stat视图里没有显示。后续检查了_enable_partition_level_acs 参数，出现问题的这个集群参数是打开的，关闭后，现象恢复正常。但是产生这么多非重复plan与_enable_partition_level_acs功能不相符。

2.3 新炬建议

1）深入理解并合理配置系统参数

参数评估与测试
在处理此类性能问题时，应首先深入理解涉及的系统参数（如_enable_partition_level_acs）的作用、默认设置及潜在影响。在做出修改前，应在测试环境中评估参数变更的效果，确保变更不会对系统稳定性和性能产生负面影响。
文档与知识库查询
当遇到不常见的系统行为或参数配置时，应积极查阅官方文档、社区论坛及知识库，了解其他用户的经验和解决方案。这有助于快速定位问题根源，并找到最合适的解决方案。
谨慎操作
对于生产环境中的关键参数修改，应采取谨慎态度，确保有充分的回滚计划和应急方案。在修改过程中，应密切关注系统性能和稳定性变化，及时调整策略。

2）加强监控与日志分析

实时监控
建立完善的监控体系，对系统性能、资源使用情况及关键业务指标进行实时监控。这有助于及时发现性能问题，并快速定位问题源头。
详细日志记录
确保系统日志和审计日志的详细记录，以便在问题发生时能够回溯操作历史、分析问题原因。对于性能问题，应特别关注SQL执行计划、锁等待情况、磁盘I/O等关键指标。

三

（OceanBase）proxy无法纳管集群处置

3.1 现象

资源新增弱读proxy，现有一个计费的弱读proxy，计划添加可连接集群到资源。但是因为ocp密码箱没有资源集群的proxyro的密码，导致已有proxy无法纳管集群。

3.2 处置过程

资源新增弱读proxy，现有一个计费的弱读proxy，计划添加可连接集群到资源。但是因为ocp密码箱缺失资源集群的proxyor用户密码，所以无法实施。

直接修改proxyor密码会造成proxy与ob集群无法连接，需要窗口操作，并同步更改root@proxysys的密码配置以及增加ocp的密码箱配置。

后来跟工单确认，ob4.x前版本有默认密码，proxyro@sys 默认密码是 xxx，测试可行。

3.3 新炬建议

1）默认密码与版本兼容性

明确版本差异
在处理OceanBase（OB）或任何数据库系统的密码和权限问题时，首先要明确不同版本之间的兼容性和默认设置差异。特别是在升级或迁移过程中，应特别注意这些变化，以避免因默认密码或行为差异导致的意外问题。
文档与最佳实践
对于关键的用户账户和密码，应参考官方文档或最佳实践指南，了解每个版本的默认设置和推荐做法。这有助于在出现问题时快速定位并解决问题。
备份与恢复
在修改密码或进行任何可能影响系统稳定性的操作之前，应确保有完善的备份和恢复策略。这样，在出现意外情况时，可以快速恢复到操作前的状态，减少损失。

2）密码修改的影响评估

全面评估
在修改任何关键账户的密码之前，都需要进行全面的影响评估。这包括考虑哪些服务或组件依赖于该密码，以及修改密码后可能引发的连锁反应。通过提前规划和测试，可以最大限度地减少意外中断和故障。
版本窗口操作
如果修改密码确实需要停机或影响业务运行，那么最好选择在低峰时段或版本更新窗口进行操作。这样可以减少对业务的影响，并确保有足够的时间来应对可能出现的问题。
配置一致性
在修改密码或权限时，必须确保所有相关的配置和参数都得到同步更新。这包括数据库内部的权限设置、代理服务器的配置、以及OCP（OceanBase Cloud Platform）等管理平台的密码箱配置。任何遗漏都可能导致系统无法正常工作。
自动化与工具
利用自动化工具和脚本来管理密码和配置更新可以大大提高效率和准确性。这些工具可以自动检测配置差异、执行更新操作并记录更改历史，从而减轻人工操作的负担和错误风险。

四

OceanBase磁盘使用率忽然升高

4.1 现象

oceanbase数据库磁盘使用率忽然升高。

4.2 处置过程

1）查看磁盘空间使用情况

__all_virtual_disk_stat

2）查看临时空间的使用情况

__all_virtual_macro_block_marker_status

data_count 为数据文件占用的宏块数量，hold_count 为临时文件占用的宏块数量。

3）查看当前占用临时表空间大小的sql信息

__all_virtual_sql_workarea_active

4）对占用临时空间大的sql进行限流或者kill session

5）将query_timeout参数调小

临时磁盘空间的释放和query_timeout参数大小设置有关，kill session后，超过该参数的设置时间后会自动释放磁盘空间。

4.3 新炬建议

1）深入理解系统内部机制

掌握系统表与视图
在处理过程中，我们充分利用了OceanBase提供的系统表（如__all_virtual_disk_stat、__all_virtual_macro_block_marker_status、__all_virtual_sql_workarea_active）来诊断问题。这要求我们对这些系统表和视图有深入的理解，知道它们能提供哪些信息以及如何解读这些信息。
理解查询优化与资源管理
了解SQL查询优化、临时表空间管理以及query_timeout等参数对系统性能的影响，是高效解决此类问题的关键。通过调整这些参数和优化SQL查询，可以显著提升系统性能和稳定性。

2）灵活应对与快速响应

迅速定位问题
在发现磁盘使用率异常升高后，我们迅速通过系统表和视图定位到问题SQL和临时表空间的使用情况。这种快速定位问题的能力对于减少系统停机时间和恢复业务运行至关重要。
灵活调整策略
针对占用临时空间大的SQL，我们采取了限流或kill session的措施。同时，根据实际需要调整query_timeout参数和data_disk_usage_limit_percentage比例，以平衡系统性能和资源使用。这种灵活应对的策略有助于我们更好地控制问题的影响范围。

3）持续优化与预防

定期审查与优化SQL
对于频繁占用大量临时空间的SQL，应定期进行审查和优化。通过优化查询逻辑、减少不必要的数据扫描和排序等操作，可以降低对系统资源的消耗。

五

OceanBase某租户CPU 100%问题

5.1 现象

某现场某租户出现CPU 100%问题。

5.2 处置过程

通过processlist抓取当时sqlid（EE7641A6834AF923F447DF03A78C2B44）。发现当时时间点存在sql并发很高，而且执行时间长，影响了当时cpu使用率异常增长。

5.3 新炬建议

1）SQL优化

避免全表扫描
全模糊匹配（如LIKE '%keyword%'）和函数转换（如UPPER）经常导致数据库无法利用索引，从而引发全表扫描。这极大地增加了数据库的负载，特别是在大数据集上。理解这一点并尽可能避免这些操作，或者通过其他方式（如文本搜索引擎）来实现类似的功能，是提升查询性能的关键。
优化索引策略
确保为查询中频繁使用的字段建立索引，并定期检查索引的有效性。对于需要进行大小写不敏感查询的字段，考虑在数据插入时统一存储为小写或大写，以避免在查询时进行转换。此外，也可以考虑使用数据库特有的功能，如函数索引或表达式索引，来优化这类查询。

2）高并发场景下的性能优化

限流与负载均衡
在高并发场景下，合理的限流和负载均衡策略是防止系统过载的关键。通过限制同时处理的请求数量，并使用负载均衡器将请求分散到多个服务器或数据库实例上，可以显著提高系统的整体性能和稳定性。
缓存策略的应用
对于频繁查询且数据变动不大的结果，使用缓存机制可以大大减少对数据库的访问次数，从而降低数据库的负载。同时，缓存还可以提供更快的响应时间，提升用户体验。然而，需要注意的是，缓存也需要合理的管理和维护，以避免数据不一致或缓存击穿等问题。

六

OceanBase oms全量迁移卡住

6.1 现象

oms迁移过程中，全量迁移卡住，链路没有报错但是实时流量为0KB/s。

6.2 处置过程

1）查看全量导入组件中的日志，显示查询sql超时

2）将执行超时的SQL语句拿到源端执行，显示超时

3）查看了这条语句的执行计划explain sql 中显示耗时

4）可以在上面的执行超时的租户下按照这个命令调整一下这个租户级别的参数，使用__oceanbase_inner_drc_user用户登录：

select * from __tenant_parameter where name like '%_xsolapi_generate_with_clause%';
alter system set "_xsolapi_generate_with_clause"=0;

6.3 新炬建议

1）深入理解SQL执行计划与优化器行为

执行计划的重要性
在处理数据库迁移或优化性能时，了解SQL的执行计划是至关重要的。执行计划展示了数据库如何执行查询，包括使用的索引、连接方法、排序操作等。通过EXPLAIN命令查看执行计划，可以清晰地看到哪些步骤可能成为性能瓶颈。
优化器行为的影响
在本案例中，OceanBase数据库V3.x版本引入了新的优化器行为，特别是TEMP TABLE TRANSFORMATION算子，它改变了查询的执行方式。这种变化可能在不兼容旧版本或特定查询模式的情况下导致性能问题。了解并适应不同数据库版本间的优化器差异是确保迁移成功和性能稳定的关键。

2）参数调优与系统配置

租户级参数调整
在OceanBase等分布式数据库中，租户级参数的调整可以显著影响查询性能和系统稳定性。通过调整_xsolapi_generate_with_clause等参数，可以关闭某些优化器的特定行为，从而避免执行超时等问题。然而，这种调整需要谨慎进行，因为关闭某些优化功能可能会在其他方面引入新的问题或降低整体性能。
系统配置与兼容性
在迁移过程中，确保源端和目标端数据库的系统配置兼容也是至关重要的。不同的配置可能导致查询执行方式的不同，进而影响迁移性能和结果。

3）问题诊断与排查流程

日志分析
在迁移过程中，及时查看和分析全量导入组件中的日志是快速定位问题的关键。日志中可能包含有关SQL执行超时、数据一致性检查失败等关键信息。
分步验证
将问题SQL在源端单独执行并观察结果，可以排除迁移过程中其他潜在因素的影响。同时，这也有助于确认问题是否确实由SQL本身或数据库配置引起。
执行计划对比
对比不同数据库版本或不同配置下的执行计划，可以帮助理解性能差异的原因。在本案例中，通过对比V3.x版本和之前版本的执行计划，可以发现TEMP TABLE TRANSFORMATION算子的引入对查询性能的影响。

七

OceanBase oms迁移数据中全量组件异常中断

7.1 现象

oms迁移数据中全量组件异常中断。

7.2 处置过程

1）部署背景

oms迁移全量业务表，单条链路表数量40张；
操作oms版本4.1.0；
涉及链路结构迁移+全量迁移+增量迁移+反向增量。

2）报错内容

链路终止，全量组件异常退出；
日志提示内容。

caused by:com.oceanbase.oms.record.exception.DataExeption:rowid is not a valid filed name

3）排查过程

过滤日志中相关报错的涉及的用户及表信息，定位报错表；
在源端侧锁定迁移割接范围中包含的rowid字段的全部表，未发现；
确认是否oms版本bug,链路重新复制，在预检查阶段未发现rowid 的排除提示，说明割接对象中未包含rowid字段的表；
确认迁移中的表是否包含索引组件表，即iot_type显示IOT类型，目前oms不支持索引组织表的全量迁移，发现其中涉及此表，在组件中拉黑处理并恢复链路。

4）故障分析

当前oms版本中，暂不支持索引组织表的全量迁移策略，在源端数据库中dba_tables\all_tables中字段iot_type字段确认。

7.3 新炬建议

1）OMS版本与目标数据库结构的兼容性检查至关重要

在数据迁移前，应详细检查OMS工具与目标数据库中的特殊表结构是否兼容，尤其是针对OMS版本不支持的表类型（如索引组织表IOT）。在迁移计划中应提前过滤和排查这些不兼容的表，避免在迁移过程中发生异常中断。对迁移工具进行版本兼容性测试和功能评估也是提升迁移效率的关键。

2）全面的预检查步骤是确保迁移稳定性的基础

迁移开始前的预检查非常重要，应确保OMS能准确识别所有迁移表的结构，特别是对于含有特殊字段或不常见数据类型的表结构（如rowid）。通过预检查可以提前发现潜在问题，避免迁移过程中出现中断或数据丢失。预检查应尽量覆盖所有表、索引和字段，以确保迁移的一致性和完整性。

3）迁移过程中的日志监控和分析是问题排查的有效手段

在迁移过程中，日志文件的详细记录对于快速定位问题至关重要。

通过日志可以精准分析错误信息，如表结构、字段名称等。定期检查和分析日志可以帮助提前发现迁移中的潜在问题，并有助于及时采取应对措施，避免问题扩大化。建议在关键迁移阶段，设置自动化的日志监控和告警系统，提升问题处理效率。

4）OMS迁移工具的限制和已知问题应在迁移前充分了解和测试

OMS工具在特定版本下可能存在某些功能上的局限性或已知问题（如不支持索引组织表的全量迁移）。

在进行业务迁移时，应对迁移工具的功能边界有充分了解，并在迁移前做好全面的功能测试。通过对工具的深入了解，可以避免不支持的功能导致迁移中断，且可以及时采取替代方案。

5）对于不支持的表类型应制定合理的迁移策略和补救措施

当遇到OMS不支持的表类型（如IOT表）时，应事先制定好绕过或补救措施。

例如，在迁移过程中提前将不支持的表类型标记拉黑，避免其影响迁移链路的正常运行，或采用其他工具完成这类表的迁移。合理的迁移策略不仅能够确保迁移的连续性，还能最大限度减少对业务的影响。

八

OceanBase 数据库主机宕机

8.1 现象

主机的raid卡驱动固件版本低，导致数据库主机宕机。

8.2 处置过程

某日14:48分接到生产系统OB集群（2-2-2架构）41主机cpu load过高告警。立即登录OCP平台检查集群状态显示41节点离线，从后台登录主机发现只能ping通，但无法登录。

15:15-15:30,尝试从array剔除故障节点，经协调业务测试发现无效果。
15:32-15:50联系OB原厂确认人工切ZONE操作，zone切换挂死，无法停止，手动切主失败。
16点发现44主机也异常，决策重启41和44，于16:30完成重启，16:35完成重启故障节点OBSERVER后，集群恢复正常，业务恢复正常。

某日17:37分接到业务负责人反馈OB数据库报错。立即登录OCP平台检查集群状态发现显示41主机状态不可用，从后台登录主机发现只能ping通，但无法登录。跟4月7日故障现象一样。

17:45分检查表分区分布情况，发现集群leader节点没有自动切主。
于是决策在17:53进行手动切主至zone3;zone2;zone1。
于17:55分切主完成。
18:02用局方账号登录云启平台，对41主机进行重启。
18:06分完成重启。
18:10分检查41节点恢复正常。

经OB原厂工程师、一级云主机工程师定位为主机raid卡固件驱动版本低导致，优先完成备集群驱动升级成功；

尝试升级主集群主机失败，核查原因为主集群内核版本为：2111，备集群内核版本为2211，驱动升级包只支持2211内核版本，由于一级云推荐的欧拉稳定版本为：2107，最后通过重装操作系统(内核版本4.19.90-2107.6.0.0192.8.oe1.bclinux.x86_64)解决。

服务器机型均为ZTE R5300 G4，操作系统版本均为BigCloud Enterprise Linux For Euler 21.10 LTS

一级云主机工程师回复：

固件版本的选择依据驱动版本，驱动版本高时建议固件版本也高，驱动版本低时建议适当降低固件版本；建议将已升级RAID卡固件驱动的主机操作系统当前内核版本2211降级至推荐版本2107。

8.3 新炬建议

1）组织真实的应急演练

针对网格通OB集群单节点CPU耗尽的混沌演练场景，以及OB集群主备切换场景，建议组织真实的应急演练。通过模拟实际故障场景进行演练，能够提高团队的应急处理能力和熟练度，确保在真实故障发生时能够迅速有效地应对，减少业务影响。

2）明确故障处理流程

在处理OB数据库故障时，建议根据《OB数据库故障处理流程》进行详细的处理和沟通。确保DBA和云侧团队的沟通流程明确、步骤清晰，能够快速定位问题并采取有效措施，避免因沟通不畅或处理流程不明确而导致故障处理延误。

3）补充数据库故障的检查项目

在OB数据库故障处理中，需要补充相关的检查项目。例如，检查RAID卡驱动和固件版本是否与操作系统内核版本兼容，确保底层硬件和软件的兼容性，防止因固件版本不匹配导致的系统宕机问题。加强对数据库故障的检查和诊断项目，确保能够全面覆盖常见故障原因，提升故障排查的效率和准确性。

4）确保固件和驱动版本的匹配

本次故障的根因是主机RAID卡驱动固件版本低，导致系统不稳定。建议在进行固件和驱动版本升级时，确保版本匹配，并且在操作系统升级或更换时，核查和更新相关的固件和驱动版本，以避免版本不兼容带来的故障。应定期检查和更新固件驱动，以保持系统的稳定性和兼容性。

5）处理方案的准备和验证

在实施系统升级和维护操作前，建议进行充分的准备和验证。例如，测试不同内核版本与驱动和固件版本的兼容性，确保升级过程中的操作步骤正确无误，从而避免因操作系统内核版本不兼容导致的故障。通过预先验证和测试，减少生产环境中的故障风险。

九

goldendb 部分计算节点偶发性连接失败

9.1 现象

监控发现部分计算节点偶发性连接失败，手动测试连接时时不时地连不上。

9.2 处置过程

1）查看dbproxy.log未见异常报错，只有少量的warn告警，但是指向也不明确

dbtool -p -x -c 查看计算节点的连接数，发现对应cn节点的连接均未达到最大连接数，
数据节点、gtm节点均运行正常，只有cn节点时不时的报连接失败；主机资源使用也未见异常；

2）通过dbtool 命令查看对应节点执行时间超过10s的慢sql语句时，发现有少量执行时间超过10s的SQL语句

dbtool -p -x -sqi 10000命令发现有少量正在执行的慢SQL语句；
dbtool -p -thdmsg命令查看线程的积压情况时，发现有部分execthread的处于积压状态，执行线程的编号ID正好和上面的慢SQL的线程ID对应；

3）经过和原厂同事核实后发现由于dbproxy本身是无状态的，它本身无法处理用户连接的认证，需要将连接转发到后端数据节点去认证，在这个过程中它会从64个执行线程中通过hash算法取出一个进程来处理这个用户的认证操作

当一个执行线程如果正在处理一个慢sql语句，而此时又调度过来一个用户认证的请求，这时候认证请求就会直接返回失败。
如果是执行SQL语句则会进入执行线程的队列，进入队列中进入等待状态；

在这个过程中执行线程主要负责相关核心功能：

a.负责前端sql语句的词法解析
b.负责前端sql语句的语法解析
c.负责生成前端sql语句的执行计划
d.负责计算执行计划中子语句的分发策略，即计算相关分片
e.负责组装下发到DB的语句
f.负责处理下发的子语句的执行结果，包括汇聚计算

4）通过和业务侧沟通后kill慢SQL对应的会话后，问题消失

参数调整：

execthread_busy_threshold 10s
该参数表示对正在执行时间超过10s的执行线程按execthread_disable_rule执行操作；
execthread_disable_rule的选项值有以下几个：
0：不做处理
1：只是终止当前导致积压的SQL，对对应线程的队列不做处理；
2: 只做线程隔离，后续新的连接不再分配至该线程；
3：终止队列中的其余连接，并隔离线程（让正在执行的SQL继续执行）

具体原因：

goldendb dbproxy的处理连接的方式是由于dbproxy本身是无状态的，它本身无法处理用户连接的认证，需要将连接转发到后端数据节点去认证，在这个过程中它会从64个执行线程中通过hash算法取出一个进程来处理这个用户的认证操作；
当一个执行线程如果正在处理一个慢sql语句，而此时又调度过来一个用户认证的请求，这时候认证请求就会直接返回失败。如果是执行SQL语句则会进入执行线程的队列，进入等待状态。

9.3 新炬建议

1）重视慢SQL的监控与优化

经验教训
慢SQL是导致执行线程积压和连接认证失败的主要原因。未能及时发现和优化慢SQL，会严重影响系统的整体性能和稳定性。
改进措施
建立定期审查慢查询日志的机制，使用SQL优化工具（如EXPLAIN）分析慢SQL的执行计划，并针对性地进行索引优化、查询重写等改进措施。

2）合理配置系统参数

经验教训
系统参数的配置对系统性能有直接影响。不恰当的参数设置可能导致资源利用不均、线程积压等问题。
改进措施
根据系统实际负载和性能需求，合理配置执行线程的相关参数（如execthread_busy_threshold和execthread_disable_rule）。同时，建立参数调整的监控和评估机制，确保参数调整后的系统性能符合预期。

3）加强监控与告警

经验教训
缺乏有效的监控和告警机制，使得问题难以及时发现和处理。
改进措施
增加对执行线程状态、系统资源使用情况等关键指标的监控，并设置合理的告警阈值。当监控指标达到告警阈值时，及时通知相关人员进行处理。

4）增强系统容错与恢复能力

经验教训
系统在面对慢SQL等异常情况时，缺乏足够的容错和恢复能力，导致问题影响范围扩大。
改进措施
优化系统的容错机制，如通过隔离慢SQL执行线程、限制单个线程的最大执行时间等方式，减少异常对系统整体的影响。同时，建立快速恢复机制，确保在问题发生后能够迅速恢复系统正常运行。

十

goldendb备库主备DN切换后备dn宕机

10.1 现象

主备DN切换背景：

insight平台告警：DN同步不一致。

10.2 处置过程

联系原厂后告知的解决方案是对主备DN进行一次切换，可以解决。

10.2.1 容灾集群切换DN主备节点后，原主节点，现备节点宕机

10.2.2 查看insight平台有新告警：主备gtid不一致

查看备节点dn日志也有相关报错:current gtid:xxxx is not subset of master gtid:xxxx,CN general日志里显示容灾集群有FLUSH PRIVILEGES命令执行记录。

10.2.3 问题分析

因为4A在容灾CN上也执行了FLUSH PRIVILEGES命令，FLUSH PRIVILEGES会在备库写binlog，就导致容灾和生产集群GTID不一致，然后容灾集群的DN 主备切换后，主DN会根据生产集群的gtid回滚gtid，让容灾主DN的gtid和生产集群保持一致。但是备DN这时就和主DN不一致了，直接就会报错GTID不一致。

10.2.4 应急解决方案

1）停止宕机节点的的dbagent

对生产无影响，可能会有告警，关闭原因是为了防止人工操作过程中dbagent干扰。

dbmoni -stop -dbagent

2）恢复dbagent对主备关系的探测

修改~/etc/dbagent.ini中monitor_interval为5。

3）清除备机的原主备关系，登录备dn库,执行

stop slave;reset slave all;

4）启动dbagent，利用dbagent自动修复主从关系，回滚多的事务

dbmoni -start -dbagent

10.3 新炬建议

1）充分测试与验证

分片测试与观察
在进行主备DN切换等重大操作时，不应仅局限于单一分片，而应至少对多个分片进行测试，并延长观察时间以确保系统稳定。同时，应记录每个分片的操作过程与结果，以便后续分析。
模拟环境验证
在正式环境执行前，应在模拟环境中充分验证操作步骤和预期结果，减少因操作不当导致的风险。

2）深入理解系统行为与命令影响

命令影响分析
对于像FLUSH PRIVILEGES这样的命令，需要深入理解其对系统（尤其是分布式系统）的具体影响。在分布式数据库环境中，此类命令可能会触发binlog的写入，进而影响主备同步的GTID一致性。

3）加强监控与告警

实时监控
增强对数据库集群的实时监控能力，确保能够及时发现并响应各类异常事件。
告警优化
针对关键指标和常见问题设置合理的告警阈值和规则，确保告警信息的准确性和有效性。

新炬运维避坑指南连载合集链接：

https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect

END

本文作者：秘而不宣(上海新炬中北团队）

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

sql优化数据库系统数据库集群 oceanbase 数据迁移

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

新炬运维避坑指南连载（十九-数据库信创专题）

新炬运维避坑指南连载合集链接：

本文作者：秘而不宣(上海新炬中北团队）

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

评论