OMS增量迁移速度变慢如何排查

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OCEANBASE、OMS
【 使用版本 】OB4.3.4.1、OMS4.2.9
【问题描述】
如图，12点之前迁移速率约为125000KB/s。 在之后突然暴跌到40000KB/s

image
image1657×831 72.1 KB

如何排查问题
@论坛小助手

2 个赞
#3

根据您提供的信息，OMS 增量迁移速度在 12 点前后发生了显著变化。以下是一些可能的排查步骤和建议，基于 OMS 社区版的功能和使用限制：

1. 检查 OMS 和 OceanBase 的日志

  • OMS 日志：OMS 社区版的日志文件中可能会记录迁移过程中遇到的问题或性能瓶颈。请检查 OMS 的日志文件，特别是从 12 点开始的时间段，查看是否有任何错误或警告信息。
  • OceanBase 日志：同时，也需要检查 OceanBase 数据库的日志文件，确保数据库本身没有出现性能问题或异常。

2. 监控资源使用情况

  • CPU、内存、磁盘 I/O：检查 OMS 和 OceanBase 所在服务器的 CPU、内存和磁盘 I/O 使用情况。如果这些资源在 12 点之后被其他进程占用较多，可能会导致迁移速度下降。
  • 网络带宽：如果数据迁移是通过网络进行的，请检查网络带宽是否在 12 点之后有所变化，例如是否有其他高带宽任务抢占了网络资源。

3. 检查 OceanBase 参数配置

  • 根据文档片段 5，如果目标端表存在 LOB 字段，需要关闭 enable_rebalance 参数以避免性能问题。可以通过以下命令检查并修改该参数：
    SHOW PARAMETERS LIKE 'enable_rebalance';
ALTER SYSTEM SET enable_rebalance = false;
  • 检查其他可能影响性能的参数，如 memory_limit 和 cpu_count，确保它们的配置适合当前的工作负载。

4. 分析 MySQL Binlog 配置（如果适用）

  • 如果增量迁移的数据源是 MySQL 数据库，请确保 MySQL 的 Binlog 配置正确，并且没有因为日志轮转或其他原因导致延迟。根据文档片段 6，可以参考相关操作确保 Binlog 已正确开启。

5. 检查 OMS 的高可用（HA）配置

  • 根据文档片段 7，OMS 社区版默认关闭高可用（HA）功能。如果启用了 HA，请检查 HA 配置是否正确，以及是否有任何 HA 相关的故障导致性能下降。

6. 检查迁移任务的预检查结果

  • 在创建迁移任务时，OMS 会进行预检查。请回顾预检查的结果，确认是否有任何潜在的问题或警告信息未被解决。

7. 分析迁移任务的配置

  • 检查迁移任务的具体配置，确保没有设置不合理的参数。例如，根据文档片段 5，旁路导入方式不支持断点续传，如果任务中断后重新启动，可能会导致性能下降。

8. 联系技术支持

  • 如果以上步骤无法解决问题，建议联系 OceanBase 的技术支持团队，提供详细的日志和配置信息，以便进一步分析。

总结

根据文档库中的信息，您可以按照上述步骤逐步排查 OMS 增量迁移速度变慢的原因。重点在于检查日志、监控资源使用情况、调整 OceanBase 参数配置以及确保迁移任务的正确配置。如果问题仍然存在，建议联系 OceanBase 的技术支持团队获取进一步帮助。

详情请参考:

  1. 产品动态
  2. 缓存系统视图
  3. 概述
  4. 通过 OMS 进行数据迁移和同步
  5. 旁路导入介绍
  6. 为 MySQL 数据库开启 Binlog
  7. OceanBase 生态工具介绍
  8. 迁移同步相关生态组件介绍
  9. 数据同步概述
1 个赞
#4

@论坛小助手 目的端，没有开启日志归档，会影响增量同步速率吗

2 个赞
#5

根据文档库中的信息，可以明确回答：目的端未开启日志归档不会直接影响增量同步速率，但可能间接影响整体迁移任务的稳定性与数据一致性。

以下是详细分析和依据：

1. 日志归档的作用

根据文档片段 5 的描述：

  • 日志归档是将数据库产生的重做日志存储到其他介质（如 NFS、OSS 等），用于长时间保存数据库的所有重做历史操作记录。
  • OceanBase 数据库支持租户级别的日志归档功能，每个租户可以独立决定是否开启。

因此，日志归档的主要目的是为了长期保存日志以供恢复或审计使用，而不是直接服务于增量同步任务。

2. 增量同步的工作机制

增量同步依赖于主库（源端）的日志流，通过解析这些日志来捕获数据变化并将其应用到目标端。具体来说：

  • 源端需要开启日志归档功能，确保增量日志能够被正确记录并传递给 OMS 或目标端。
  • 目标端（目的端）并不直接依赖日志归档功能，而是通过接收来自源端的增量日志进行应用。

因此，目的端未开启日志归档不会直接影响增量同步速率。

3. 可能的间接影响

尽管目的端未开启日志归档不会直接影响增量同步速率，但可能存在以下间接影响：

  • 数据恢复能力受限：如果目的端未开启日志归档，在发生故障时可能无法通过归档日志进行数据恢复，从而影响整体迁移任务的可靠性。
  • 网络带宽占用：如果目的端未开启日志归档，可能会导致某些日志重复传输或缓存不足，从而间接增加网络带宽压力。
  • 任务中断风险：在某些场景下，如果目的端未开启日志归档，可能导致任务中断后无法快速恢复，从而影响整体迁移效率。

4. 建议

为了确保增量同步任务的稳定性和数据一致性，建议如下：

  1. 检查源端日志归档配置：确保源端已正确开启日志归档功能，并设置合理的 archive_lag_target 参数（如文档片段 3 所述），以减少日志延迟。
  2. 评估目的端需求：如果目的端对数据恢复或审计有需求，建议开启日志归档功能。
  3. 监控日志同步状态：通过查询 GV$OB_LOG_ARCHIVE_STATUS 等视图，监控日志归档和同步的状态，及时发现潜在问题。

结论

根据文档库中的信息，目的端未开启日志归档不会直接影响增量同步速率，但可能间接影响任务的稳定性和数据一致性。如果您的场景对数据恢复或审计有需求，建议开启目的端的日志归档功能。

详情请参考:

  1. 备份架构
  2. OceanBase 数据库性能的影响因素
  3. 日志归档前准备
  4. 日志稳定性
  5. 日志归档概述
  6. OceanBase 集群运维管理之用户实操
  7. 统计信息概述
  8. 物理备库同步过程中卡住
  9. 设置日志同步限速
1 个赞
#6

可以把metrics.log日志发一下 按照官网的可以分析一下 看看性能在哪里 是源端还是目标端
https://www.oceanbase.com/docs/community-oms-cn-1000000002947453

1 个赞
#7

被国外通过ntp攻击网络。源端外网出流量400Mb。 OMS入网流量几十Mb。
store组件拉取的位点还在昨晚9点···
特么的，无聊的人真多···

image
image1114×331 26.6 KB

2 个赞
#8

根据您提供的信息，目前遇到的问题是由于 NTP 攻击导致网络流量异常，并且 OMS 的 Store 组件拉取位点停滞在昨晚 9 点。以下是针对该问题的排查和解决建议：

1. 确认 NTP 攻击的影响

  • NTP 攻击简介：NTP 攻击通常通过伪造源 IP 地址发送大量 NTP 请求，导致目标服务器的带宽被耗尽或 CPU 负载过高。
  • 影响分析：
    • 源端外网出流量达到 400Mb，表明网络带宽可能已被攻击流量占用。
    • OMS 入网流量仅为几十 Mb，说明正常业务流量受到严重影响。
    • Store 组件拉取位点停滞可能是由于网络延迟或中断导致增量日志无法正常传输。

2. 排查网络问题

  • 检查网络带宽使用情况：
    • 使用 iftop 或 nload 工具监控网络流量，确认是否有异常流量占用带宽。
    • 如果发现大量来自特定 IP 地址的流量，可以尝试屏蔽这些 IP 地址。
  • 检查防火墙规则：
    • 确保防火墙规则中已限制不必要的入站和出站流量。
    • 可以临时关闭 NTP 服务（如果非必要），避免成为攻击目标。
  • 联系 ISP：
    • 如果攻击流量过大，建议联系您的互联网服务提供商（ISP）请求帮助进行流量清洗。

3. 检查 Store 组件状态

根据文档片段 6 和 8 的描述，Store 组件负责增量数据的拉取和解析。如果拉取位点停滞，可能是以下原因导致：

  • 网络延迟或中断：由于 NTP 攻击导致网络不稳定，增量日志无法及时传输到 OMS。
  • 源端日志生成延迟：源端可能因高负载或其他原因未能及时生成增量日志。
  • Store 组件故障：Store 组件本身可能存在异常，导致无法正常拉取数据。

排查步骤：

  1. 登录 OMS 社区版控制台，进入 数据迁移 页面，单击目标任务名称，查看 组件监控。
  2. 检查 Store 组件的日志文件（如 libobcdc.log 或 connector/connector.log），确认是否有错误信息。
  3. 如果发现 Store 组件异常，可以尝试重启组件或重新启动任务。

4. 优化增量同步性能

根据文档片段 10 的描述，可以通过以下 SQL 查询各 OBServer 节点的 SQL 流量分布情况，定位潜在的性能瓶颈：

SELECT/*+ PARALLEL(15)*/t2.zone, t1.svr_ip, COUNT(*) AS RPC_COUNT,
AVG(t1.elapsed_time), AVG(t1.queue_time)
FROM oceanbase.GV$OB_SQL_AUDIT t1, __all_server t2
WHERE t1.svr_ip = t2.svr_ip
AND tenant_id = 1001
AND SQL_ID = 'BF7AA13A28DF50BA5C33FF19F1DBD8A9'
AND IS_EXECUTOR_RPC = 0
AND request_time > (time_to_usec(now()) - 1000000)
AND request_time < time_to_usec(now())
GROUP BY t1.svr_ip;
  • 分析结果：
    • 如果某个节点的 RPC_COUNT 或 elapsed_time 明显高于其他节点，可能是该节点存在性能瓶颈。
    • 针对性能瓶颈节点，可以考虑调整资源分配或优化查询语句。

5. 恢复增量同步

如果 Store 组件拉取位点停滞时间较长，可以尝试以下方法恢复增量同步：

  • 手动调整位点：
    • 在 OMS 控制台中，找到对应的任务，手动调整增量同步的起始位点。
  • 重新启动任务：
    • 如果手动调整位点不可行，可以暂停并重新启动任务。
  • 检查源端日志归档：
    • 确保源端已开启日志归档功能，并设置合理的 archive_lag_target 参数，避免日志丢失。

6. 预防措施

  • 限制 NTP 服务访问：
    • 仅允许可信 IP 地址访问 NTP 服务，避免成为攻击目标。
  • 启用流量清洗服务：
    • 如果频繁遭受 DDoS 或 NTP 攻击，建议启用专业的流量清洗服务。
  • 定期监控网络流量：
    • 使用监控工具定期检查网络流量，及时发现异常行为。

总结

根据文档库中的信息，当前问题的主要原因是 NTP 攻击导致网络流量异常，进而影响了 Store 组件的增量同步性能。建议按照上述步骤逐步排查并解决问题，同时采取预防措施避免类似问题再次发生。如果问题仍未解决，建议联系 OceanBase 技术支持团队获取进一步帮助。

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

  1. OMS 社区版错误码
  2. OceanBase Store RPC 访问 OceanBase 集群失败
  3. 如何处理 Failed to fetch 报错
  4. OMS 社区版问题排查手册
  5. 负载均衡
  6. 查询 SQL 流量分布情况及 QPS

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

1 个赞
#9

ntp服务配置加上以下内容，仅允许内网ip访问，忽略其他ip访问。同时nomodify(禁止修改) notrap(禁止放大)：
restrict default ignore
restrict 172.168.0.0 mask 255.255.0.0 nomodify notrap
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap
restrict 127.0.0.1
restrict ::1

1 个赞
#10

目前流程正常么？是否解决了

#11

您是怎么发现是攻击的。分享下！ 非常感谢！

#12

之前部署集群，创建ntp服务的时候。把原始自带的配置清空了。
没了以下配置项
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
导致源端proxy开放外网的时候。有很多陌生ip来试探。

昨天排查的时候，发现源端和目的端的出网流量和入网流量差异太大，应该是有问题的
就去分析源端入网ip和出网ip。发现存在国外的陌生ip出网流量特别高。
就意识到是被攻击了。
当时还很慌，怕数据流失。赶紧关了外网。
最后排查端口，这个陌生ip使用的ntp服务的端口入网。

目前临时把VPN流量升上去了，使用了VPN网络进行的连接。没有继续使用外网。
之前是因为阿里云VPN流量最高200Mb。想升上去还需要人工申请，觉得麻烦就搞了个外网。还特意仅对指定ip开放入网白名单，以为这样就安全了。

建议在部署教程里，加上ntp服务配置安全性强调。

2 个赞
#13

好示例，学习了！！充实了数据安全的考虑面

#14

你说的是oms部署的时候么？

#15

在oceanbase部署时。 前置准备的ntp部署文档中

#16

部署ntp时。

配置直接这样改：
#禁止所有ntp访问
restrict default ignore
#只允许自己配置的上级ntp服务访问
restrict xxx.xxx.xxx.xxx nomodify notrap nopeer noquery
#配置自己的上级ntp服务
server xxx.xxx.xxx.xxx iburst