DM 8.1 版本
源库是分库分表 MySQL ,但是申请不了 LOCK 权限，能不能全量备份？
{
"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'"
你的任务配置文件中会有这么一块配置。
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 个赞
除非设置为none，否则都得加锁吧。mysql也不支持–snapshot。
没有–single-transaction 这种方式吗？
对MySQL来说，要有所保证的话，其实就是lock或者flush。
一个是需要 FLUSH TABLES WITH READ LOCK，一个需要lock。
还是就是开增量校验，事后纠正一下。别的确实没什么好的办法了。
顺便再问一句，dm没法用binlog+offset方式同步吧，只能gtid是吧？我库里有别的同步工具搞的全量，也有binlog位点，但是是offset的方式。dm没法直接用吧。
dm可以不设置gtid。不设置的情况下好像就是binlog+offset这种方式的。
不过假如别的同步工具搞全量，记录的binlog点位要对每个库的表要一样，感觉也是要锁来保证的。
如果不锁，那每个表的binglog点位可能就不一样，你要每个表都要单独设置一个增量任务的话，表一多是有点麻烦的。
别的工具搞的全量的位点是对的，全库一个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 个赞
在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 个赞
感谢感谢！我对dm不熟悉，学习了不少！
问题是没锁的话，记录binlog的时间，和select的时间之间，可能有改动。比如插入。
那么回放binlog的时候，这期间插入的一条数据就可能插2次。要么改写insert到replace（dm的安全模式）。要么就直接报错了（dm非安全模式下就直接报错，卡住）。
感觉没有锁，很难保证记录binglog的时间和select的时间之间没改动。
就是用的replace，这样就可以了。看来dm有个安全模式可以这样搞。下午我再查查，看看能不能安全模式搞个备份。
1 个赞
应该不是权限的问题，看看是否有报错日志。
dm可以不设置gtid。不设置的情况下好像就是binlog+offset这种方式的。
不过假如别的同步工具搞全量，记录的binlog点位要对每个库的表要一样，感觉也是要锁来保证的。
如果不锁，那每个表的binglog点位可能就不一样，你要每个表都要单独设置一个增量任务的话，表一多是有点麻烦的。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。