升级版本后通过mydumper备份报错

🪐 TiDB 技术问题 备份&数据迁移
,
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：4.0.8
  • 【问题描述】：
    通过如下命令做的tidb备份
    mydumper -h ${host_ip} -P ${port_num} -u ${db_user} -p ${db_pass} -L ${BASE_DIR}/${out_file} -t ${thead_num} -F ${chunk_size} -v 3 -e -o ${dump_dir}
    之前运行在2.1.14版本没有问题，最近升级到了4.0.8版本之后，每次备份一开始都会有如下的报错，但不影响mydumper的备份。
    只是最后通过$?进行判断的时候，会把备份判断为失败。请问这个报错有什么办法解决么

2020-12-14 02:05:01 [INFO] - Connected to a MySQL server
2020-12-14 02:05:01 [ERROR] - Couldn’t acquire global lock, snapshots will not be consistent: FLUSH TABLES WITH READ LOCK is not supported. Please use @@tidb_snapshot
2020-12-14 02:05:01 [INFO] - Started dump at: 2020-12-14 02:05:01
……
……
2020-12-14 11:18:21 [INFO] - Thread 1 shutting down
2020-12-14 11:18:22 [INFO] - Thread 4 shutting down
2020-12-14 11:55:22 [INFO] - Thread 2 shutting down
2020-12-14 23:10:50 [INFO] - Thread 3 shutting down
2020-12-14 23:10:50 [INFO] - Finished dump at: 2020-12-14 23:10:50

2

mydumper的参数
-k, --no-locks Do not execute the temporary shared read lock. WARNING: This will cause inconsistent backups
可以解决，不过这样就不是一致性备份。
我看报错，Please use @@tidb_snapshot，不知道tidb是不是有什么参数可以解决

3

使用 dumpling 代替 mydumper 吧，

当前这个问题可以使用 --no-lock 解决，@@tidb_snapshot 的添加也是可以的，这个参数的含义就是在 gc lift time 时间范围内，将这个 snapshot 的时间点的数据导出来。

4

好的，感谢。
我暂时先用–no-locks解决下，后面研究下dumpling

5

OK～