. thread stacks, code cache, garbage collection space etc, it is a
capped fractionated component of the total process memory
|
在 2024-04-09 11:28:57,"Shawn Huang" 写道:
从报错信息看,是由于JM的堆内存不够,可以尝试把JM内存调大,一种可能的原因是mysql表全量阶段分片较多,导致SourceEnumerator状态较大。
Best,
Shawn Huang
wyk 于2024
,"Jiabao Sun" 写道:
>Hi,
>
>日志中有包含 GTID 的内容吗?
>用 SHOW VARIABLES LIKE 'gtid_mode’; 确认下是否开启了GTID呢?
>
>Best,
>Jiabao
>
>
>On 2024/01/19 09:36:38 wyk wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 抱歉,具
ng at "
+ mySqlOffsetContext.getSourceInfo()
+ ", but this is no longer "
+ "available on the server. Reconfigure the connector to
use a snapshot when needed.");
}
在 2024-01-19 17:33:03,"Jiabao Sun" 写道:
>Hi,
>
>你的图挂了,可以贴一下图床链接或者直接贴一下代码。
>
各位大佬好:
现在有一个binlog文件丢失问题,需要请教各位,具体问题描述如下:
问题描述:
场景: 公司mysql有两个备库: 备库1和备库2。
1. 现在备库1需要下线,需要将任务迁移至备库2
2.我正常将任务保存savepoint后,将链接信息修改为备库2从savepoint启动,这个时候提示报错binlog文件不存在问题,报错截图如附件内图一
3.我根据报错找到对应代码(如附件内图二)后,发现是一块校验binlog文件是否存在的逻辑,我理解的是我们从gtid启动不需要对binlog文件进行操作,就将这部分代码进行了注释,任务能够正常从savepoint启动,
各位大佬好:
现在有一个binlog文件丢失问题,需要请教各位,具体问题描述如下:
问题描述:
场景: 公司mysql有两个备库: 备库1和备库2。
1. 现在备库1需要下线,需要将任务迁移至备库2
2.我正常将任务保存savepoint后,将链接信息修改为备库2从savepoint启动,这个时候提示报错binlog文件不存在问题,报错截图如下图一
3.我根据报错找到对应代码(如下图二)后,发现是一块校验binlog文件是否存在的逻辑,我理解的是我们从gtid启动不需要对binlog文件进行操作,就将这部分代码进行了注释,任务能够正常从savepoint启动,并且数据