DM 没有LOCK 权限能不能备份全量？

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

DM 8.1 版本
源库是分库分表 MySQL ,但是申请不了 LOCK 权限，能不能全量备份？

2

https://docs.pingcap.com/zh/tidb/stable/dm-worker-intro#上游数据库用户权限

没有提到需要lock权限，报错内容发出来看看？

3 
  {
            "result": true,
            "msg": "",
            "sourceStatus": {
                "source": "xxxx_db",
                "worker": "dmxxxx",
                "result": null,
                "relayStatus": null
            },
            "subTaskStatus": [
                {
                    "name": "wallet",
                    "stage": "Paused",
                    "unit": "Dump",
                    "result": {
                        "isCanceled": false,
                        "errors": [
                            {
                                "ErrCode": 32001,
                                "ErrClass": "dump-unit",
                                "ErrScope": "internal",
                                "ErrLevel": "high",
                                "Message": "mydumper/dumpling runs with error, with output (may empty): ",
"RawCause": "sql: LOCK TABLES `xxxx_db`.`xxx_xxx` READ,......: Error 1044 (42000): Access denied for user 'xxx'@'1.1.1.1' to database 'xxxx_db'"
4

你的任务配置文件中会有这么一块配置。
https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full

mydumpers: # dump 处理单元的运行配置参数
global: # 配置名称
threads: 4 # dump 处理单元从上游数据库实例导出数据和 check-task 访问上游的线程数量，默认值为 4
chunk-filesize: 64 # dump 处理单元生成的数据文件大小，默认值为 64，单位为 MB
extra-args: “–consistency none” # dump 处理单元的其他参数，不需要在 extra-args 中配置 table-list，DM 会自动生成

注意这个

extra-args: “–consistency none”

https://docs.pingcap.com/zh/tidb/stable/dumpling-overview#调整-dumpling-的数据一致性选项

这个参数的解释，在dumpling文档里面。

  • LOCK TABLES：使用 consistency lock 时需要，需要导出的库表都有该权限。

当这个参数被设置为lock的时候是需要这个权限的。
你检查一下任务的配置文件是否有这方面的配置。

1 个赞
5

除非设置为none，否则都得加锁吧。mysql也不支持–snapshot。
没有–single-transaction 这种方式吗？

6

对MySQL来说，要有所保证的话，其实就是lock或者flush。

一个是需要 FLUSH TABLES WITH READ LOCK，一个需要lock。

7

还是就是开增量校验，事后纠正一下。别的确实没什么好的办法了。

8

顺便再问一句，dm没法用binlog+offset方式同步吧，只能gtid是吧？我库里有别的同步工具搞的全量，也有binlog位点，但是是offset的方式。dm没法直接用吧。

9

dm可以不设置gtid。不设置的情况下好像就是binlog+offset这种方式的。

不过假如别的同步工具搞全量，记录的binlog点位要对每个库的表要一样，感觉也是要锁来保证的。
如果不锁，那每个表的binglog点位可能就不一样，你要每个表都要单独设置一个增量任务的话，表一多是有点麻烦的。

10

别的工具搞的全量的位点是对的，全库一个binlog+offset的位点。dm不设置gtid的话，位点怎么配置？我看源的配置里面就这两项,没有offset

source-id: "mysql-replica-01"

# 是否开启 GTID
enable-gtid: false

# 是否开启 relay log
enable-relay: false       # 该配置项从 DM v2.0.2 版本起弃用，使用 `start-relay` 命令开启 relay log
relay-binlog-name: ""     # 拉取上游 binlog 的起始文件名
relay-binlog-gtid: ""     # 拉取上游 binlog 的起始 GTID
# relay-dir: "relay-dir"  # 存储 relay log 的目录，默认值为 "relay-dir"。从 v6.1 版本起该配置标记为弃用，被 worker 配置中的同名参数取代

https://docs.pingcap.com/zh/tidb/stable/dm-source-configuration-file

另外别的工具是这样搞的全量备份：
记下来当前的binlog位置。然后对源库执行select，对目标库插入，期间随意修改。

然后回放binlog，改成replace into 这种方式写入。这样最终binlog追齐，源库和目标库就一致了。这种方式不需要锁表。dm支持么？

1 个赞
11

在task的配置文件中配置。
https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full

mysql-instances:

source-id: "mysql-replica-01"           # 对应 source.toml 中的 `source-id`
meta:                                   # `task-mode` 为 `incremental` 且下游数据库的 `checkpoint` 不存在时 binlog 迁移开始的位置; 如果 checkpoint 存在，则以 `checkpoint` 为准。如果 `meta` 项和下游数据库的 `checkpoint` 都不存在，则从上游当前最新的 binlog 位置开始迁移
  binlog-name: binlog.000001
  binlog-pos: 4
  binlog-gtid: "03fc0263-28c7-11e7-a653-6c0b84d59f30:1-7041423,05474d3c-28c7-11e7-8352-203db246dd3d:1-170"  # 对于 source 中指定了 `enable-gtid: true` 的增量任务，需要指定该值
1 个赞
12

感谢感谢！我对dm不熟悉，学习了不少！

13

问题是没锁的话，记录binlog的时间，和select的时间之间，可能有改动。比如插入。
那么回放binlog的时候，这期间插入的一条数据就可能插2次。要么改写insert到replace（dm的安全模式）。要么就直接报错了（dm非安全模式下就直接报错，卡住）。

感觉没有锁，很难保证记录binglog的时间和select的时间之间没改动。

14

就是用的replace，这样就可以了。看来dm有个安全模式可以这样搞。下午我再查查，看看能不能安全模式搞个备份。

1 个赞
15

应该不是权限的问题，看看是否有报错日志。

16

破案了，没有锁也能做到最终一致，就是先开个事务，然后记录binlog，然后dump数据。

image
image1465×261 29.2 KB

1 个赞
17

dm可以不设置gtid。不设置的情况下好像就是binlog+offset这种方式的。

不过假如别的同步工具搞全量，记录的binlog点位要对每个库的表要一样，感觉也是要锁来保证的。
如果不锁，那每个表的binglog点位可能就不一样，你要每个表都要单独设置一个增量任务的话，表一多是有点麻烦的。