点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！
核心系统上线后，集群主zone三台机器轮询磁盘使用率达到 98%，且磁盘使用率增长时间固定为早上 8:00-12:00；对业务暂未发生影响。查看磁盘使用情况，确认磁盘被什么占用，发现有大量临时文件。查看后台是否有任务在运行、或者是否有索引在创建。确认都没有后，查询临时文件存放情况，发现临时文件释放时间为 6 小时。查看系统租户租户超时时间，发现ob_query_timeout设置为 6 小时，调整时间为2 小时，已占用的临时文件到时间会自动释放。通过系统日志或者数据库的审计功能，确定是哪些操作产生了大量的临时文件。这可能包括但不限于复杂查询、大数据导入、报表生成等。重点关注业务高峰期这一时间段的业务操作和计划任务，以确定是否有特定任务或查询负责生成这些临时文件。已将 ob_query_timeout 从6小时调整为2小时。进一步监控这一更改对磁盘使用率的影响，并根据需要调整。实施定期清理临时文件的策略，通过计划任务定时执行清理脚本。检查和优化产生大量临时文件的查询。可能需要重写查询或调整数据库索引来减少对临时文件的依赖。与应用开发团队合作，了解应用层面可能导致临时文件增多的操作，并探索优化可能性。确保有有效的监控系统跟踪磁盘使用情况，特别是临时文件的增长。使用工具如 Grafana、Prometheus 对磁盘使用进行可视化，及时发现异常变化。在磁盘使用达到预定阈值时设置自动警报，以便及时采取行动。
OCP添加OB主机，Pre check for create host环境校验步骤OCP主机与OB主机检验时钟差过大。[pool-manual-subtask-
executor14,125cd45d331d4273,456a532ab0ee] c.o.o.c.t.engine.runner.RunnerFactory :
Execute task failed, subtask=SubtaskInstanceOverview{id=121718, name=Pre check for create host, state=FAILED, operation=EXECUTE,
className=com.oceanbase.ocp.service.task.business.host.PreCreateHostCheckTask, seriesId=1,
startTime=2024-03-08T16:31:34.867+08:00, endTime=null}, failedMessage=The time difference between OCP and the host is relatively large.
The current time difference is -47,498 ms, and the maximum time difference allowed is 50 ms.
- 在三台OB主机执行clockdiff至OCP主机IP，得到评估值，看到delta值小于20ms，为正常范围内；
- 后在OCP主机使用clockdiff命令分别至三台OB主机，均提示目标主机主机is down；
- 在OCP主机分别ping三台OB主机，无法ping通；
- 联系客户得知三台OB主机被禁ping（ICMP协议），提流程开通；
- 开通后，再次从OCP测试clockdiff至OB主机后，均通过，再次执行OCP加入主机的任务，成功通过。
通过ping发现主机ICMP协议被禁止，搜索发现clockdiff也是使用的ICMP协议。在部署和配置新主机之前，与网络团队沟通，确认网络安全策略，特别是关于ICMP协议的使用情况。确保所有必要的网络协议都已开通，以便各种系统工具能够正常运行。开发或使用预先配置的脚本来自动检查网络配置和主机间通讯状态，包括ICMP、SSH等关键协议的连通性，避免手动检查可能遗漏的风险。确保所有相关操作文档反映此次经验，特别是对ICMP协议的依赖性和在环境校验前确认协议可用性的重要性。制定和实施标准操作流程(SOP)，在遇到类似网络通讯问题时，可以快速按照标准流程操作，减少故障处理时间。在系统中实施更强大的监控解决方案，监测主机间的网络状态和时间同步状态，及时发现并报告潜在问题。在监控系统中设置针对关键网络参数（如ICMP连通性和时间差异）的警报，当这些指标超出正常范围时能够及时通知技术团队。
数据库中执行insert into xxx select * from xxx时有时候插入正常，有时候报错transaction needs rollback，用oms迁移oracle数据到该ob库时基本上每次迁一会速度就会降到0kb/s，在ocp sql诊断查看oms的insert语句报的也是-6244 transaction needs rollback。ocp上观察到该集群主机频繁有网络收发包出错告警，业务网卡bond error计数一直在增加。主机侧排查网卡有翻滚，主机侧协助禁用故障网卡后恢复正常。工具如Nagios、Zabbix或新兴的云监控工具，可以实时检测并报告网络状态。周期性地运行网络诊断工具（如iperf或NetFlow）来测试网络性能和稳定性。这可以帮助预测网络故障并提前介入。为关键的数据库服务器配置冗余网络路径和多重物理连接，如网络接口卡（NIC）绑定，以提高容错能能力。检查并优化路由器、交换机等网络设备的配置，确保它们能够处理高峰时段的流量负载。确保能够迅速定位并隔离网络中的故障节点或设备，最小化对业务的影响。实施数据库级别或网络级别的自动故障转移机制，确保在检测到网络故障时能自动切换到备用网络或服务器。根据网络的实际表现调整数据库事务的超时时间，以防止由于短暂的网络抖动导致事务失败。8）使用事务日志和恢复策略：确保所有事务都有完整的日志记录，以便在事务失败后可以进行数据恢复。
alter table ras_hubei.zfzx_pay rename to ras_hubei.zfzx_pay_bak;
alter table ras_hubei.zfzx_new rename to ras_hubei.zfzx_pay;
rename前的表没有加到白名单里，一个已知的限制点，rename前的的表要在白名单里面。做这种动作需要把新表的名字加入到白名单里，不然数据不会同步。3x为了尽可能的少抽取日志，抽取日志逻辑是需要哪些表就仅抽取这些表的clog 因此不在表名单的表即使rename为了白名单中的表名，日志也是检索不到变更。在执行DDL操作如rename之前，确保动态更新白名单设置。可以考虑实现自动化脚本或工具，当捕捉到DDL操作前，自动将涉及的新表名加入白名单。对日志抽取逻辑进行优化，确保即使表不在当前白名单中，也能保留足够的日志信息，以便在需要时进行追溯和同步。确保所有重要的操作，包括白名单变更和表rename操作，都有详细的日志记录，便于问题追踪和后续分析。在生产环境部署之前，对所有数据同步策略进行严格的测试，特别是涉及DDL操作的同步策略。确保测试覆盖各种边界条件和异常情况。实施版本控制系统来管理白名单和同步策略的变更。在发现问题时，可以快速回滚到稳定版本。
OMS全量校验任务报错ORA-08181：specified number is not a valid system change number，点恢复可以跑一段时间（已完成校验行数还在变动）过段时间又报同样错误。核查因OMS根据操作系统的系统时间来生成Oracle源端校验查询的SCN号，但该环境由于存在机器间时间不同步，停了ADG实时应用后，该SCN号不匹配Oracle ADG自己生成的SCN号。通过调整ORACLE主库时间，使其与ADG库、OMS机器之间的时间同步后，再次全量校验，问题解决。确保所有数据库服务器（包括主库和ADG库）以及OMS系统都同步到同一个可靠的时间源。使用网络时间协议（NTP）可以帮助保持系统时间的一致性。定期检查时间同步状态，特别是在关键的数据库操作和备份过程中。使用工具如chrony或ntpq来监控时间同步质量和偏差。在OMS或数据库层面实现错误处理逻辑，当检测到由于SCN无效引起的错误时，自动进行重试或调整SCN值。定期审查系统配置和管理策略，确保所有相关系统和服务都遵循最佳实践，特别是在时间管理和数据同步方面。确保数据库和应用层的时间同步策略一致，以防止因时间偏差导致的数据一致性问题。
coordinator.allowRecordTypes = "DELETE,INSERT,UPDATE,DDL"
source.ignoreDdl = false
slik.isPreLoadAllTableSchema = false
确保配置文件或同步参数中允许同步所有类型的数据库操作，包括DELETE、INSERT、UPDATE以及DDL。这有助于保证数据和结构的完整性都得到同步。通过设置source.ignoreDdl = false确保源数据库的DDL操作（如表结构变更）也被同步到目标数据库。通过设置slik.isPreLoadAllTableSchema = false，调整表结构的预加载方式，确保只有在需要时才加载表结构，避免不必要的性能开销。增强同步过程的日志记录功能，记录所有关键步骤和任何异常情况，以便在出现问题时可以快速定位原因。通过定期运行一致性检查工具或脚本，验证源数据库和目标数据库之间的数据一致性，确保同步过程没有丢失任何关键数据。在同步程序中增加错误处理逻辑，能够识别常见的同步错误并自动采取恢复措施。在发生错误时，提供数据回滚选项，以恢复到错误发生前的状态，保证数据的准确性和完整性。
OMS回流导致OB节点CPU使用率超高或创建ob-oracle全量、增量迁移链路。slik.isPreLoadAllTableSchema = false
slik.isPreLoadAllTableSchema = false
减小每次同步的批处理大小，可以降低单次操作对CPU的压力，但可能会增加总体同步时间。需要根据具体情况调整以找到最佳平衡点。如果可能，考虑采用异步处理数据的方法，这样可以平滑CPU使用率，避免高峰时段CPU使用率过高。优化同步过程中使用的SQL查询，尽量减少复杂的联表查询和大量的数据处理操作。确保OB节点有足够的CPU资源来处理同步任务。如果需要，考虑增加CPU资源或优化现有资源分配。使用工具监控CPU使用情况，分析哪些具体过程或查询最消耗CPU资源，并针对这些过程进行优化。如果可能，将负载分散到多个节点，避免单一节点过载。在资源始终为瓶颈的情况下，考虑进行硬件升级，尤其是提升CPU性能。尽量避免在同步过程中进行全表扫描，这种操作通常会导致高CPU和I/O使用率。检查数据处理逻辑，避免不必要的数据转换和复杂计算。
OMS回流链路报错误：“ORA-00054：resource busy and acquire with NOWAIT specified or timeout expired errorDDL: drop index XXXX”--sink(无作用)
maxRetryTimes = 3000
retryIntervalTime = 1
retryErrorCode = ["00054"]
--coordinator
skipDdl = ["drop INDEX","drop index","Drop index","DROP INDEX"]
在应用层面实施同步控制，确保在执行DDL操作前数据库不处于高负载状态或减少并发操作。尽量在数据库负载较低的时段执行DDL操作。例如，可以安排在业务低峰时段自动执行这类操作。如果适用，使用数据库分区来减少需要操作的数据量，这样可以减少锁定的范围和时间。在数据库级别设置合理的锁定超时时间，使得长时间锁定的操作能够自动放弃，减少堵塞。实施针对DDL操作的监控系统，确保及时了解和响应可能的锁定和错误。定期进行数据库维护，如重建索引、清理历史数据等，以优化数据库性能和减少锁竞争。
resource_hard_limit = 110
当资源使用接近限制时自动通知管理员，以便及时采取行动。如基于需求动态调整资源分配，可以更有效地利用可用资源。resource_hard_limit 参数设置为110意味着允许超过配置的硬性资源限制，这虽然可以提供灵活性，但也可能导致资源争抢和性能下降。根据实际的运行情况调整这一参数，避免过度超卖。考虑同时设置软限制（resource_soft_limit），作为预警的阈值，而硬限制作为绝对不可超过的界限。定期进行容量规划和审核，基于历史数据和未来预测来决定资源需求，从而有效预防资源超卖。保持一定比例的资源作为缓冲区域，以应对突发事件和避免资源紧张。
ocp告警，获取集群信息失败，集群状态检测异常,observer有4012执行超时和4019空间溢出报错，备份延迟告警，连接集群后执行命令异常，只能查询processlist，其他操作无法执行。查看rs日志，发现 sys 租户存在队列积压：req_queue:total_size = 17409。确保有有效的监控系统来跟踪关键资源的使用情况，如CPU、内存、磁盘空间和网络。使用工具如Prometheus、Grafana等进行实时监控和可视化。实施自动化的资源管理和扩展策略。例如，当检测到资源使用达到阈值时，自动增加资源或启动更多实例来处理增加的负载。针对观察到的问题调整数据库配置，例如增加连接池大小、调整超时设置、优化查询性能等。定期进行数据库维护，如索引重建、数据清理和碎片整理，以保持数据库性能。设计系统和应用时，考虑到容错性和异常处理能力，确保在某个组件失败时，整个系统能够继续运行或快速恢复。实施限流和服务降级策略，当系统负载过高时，通过降低服务质量来保护系统不被过载。新炬运维避坑指南连载合集链接：
https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzUxNTYzMjA5Mg==&action=getalbum&album_id=2846038717288693763#wechat_redirect
