ERROR 8121 (HY000): privilege check fail

[Hacker_oJu7jGxh]

【概述】 场景 + 问题概述
创建用户：
mysql> grant select on test1.* to ‘user1’@’%’ identified by ‘123456’;
ERROR 8121 (HY000): privilege check fail

操作用户相关权限：
mysql> show grants;
±--------------------------------------------------------------------+
| Grants for User |
±--------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON . TO ‘root’@‘127.0.0.1’ WITH GRANT OPTION |
±--------------------------------------------------------------------+
1 row in set (0.00 sec)

【TiDB 版本】
mysql> select version();
±-------------------+
| version() |
±-------------------+
| 5.7.25-TiDB-v4.0.0 |
±-------------------+
1 row in set (0.00 sec)

[leeray (Lileiaab)]

先检查一下当前用户有没有grant权限

select Grant_priv from mysql.user where user = ‘当前用户名’;

[Meditator (Wendywong020)]

确实太多的这样问题

[Hacker_oJu7jGxh]

我上面贴出来的那个 WITH GRANT OPTION 是假的吗？

从user表查的话确实没有grant_priv。
±----------±-----±-----------+
| host | user | Grant_priv |
±----------±-----±-----------+
| % | user1 | N |
±----------±-----±-----------+

[spc_monkey (carry@pingcap.com)]

你的登录用户是谁，上面没有提供

[Hacker_oJu7jGxh]

show grants 看到的就是 登录用户。

[spc_monkey (carry@pingcap.com)]

tidb 中好像不能直接 grant 创建用户（需要分两步：创建用户，再授权）

[Billmay表妹 (表妹)]

请问你的问题解决了吗？

[sylzd]

v6.1.0 遇到类似问题：

                                "id": 1,
                                "name": "source db dump privilege checker",
                                "desc": "check dump privileges of source DB",
                                "state": "fail",
                                "errors": [
                                        {
                                                "severity": "fail",
                                                "short_error": "lack of Select privilege: {`INFORMATION_SCHEMA`}; "
                                        }
                                ],

task只同步一个业务数据库，配置跳过该检查项后解决

# 任务名，多个同时运行的任务不能重名。
name: "dm-XXX"
# 全量+增量 (all) 迁移模式。
task-mode: "all"

shard-mode: "pessimistic"       # 任务协调模式，可选的模式有 ""、"pessimistic、"optimistic"。默认值为 "" 即无需协调。如果是分库分表合并任务，请设置为悲观协调模式 "pessimistic"。
                                # 在 v2.0.6 版本后乐观模式逐渐成熟，深入了解乐观协调模式的原理和使用限制后，也可以设置为乐观协调模式 "optimistic"
meta-schema: "dm_meta"          # 下游储存 `meta` 信息的数据库
case-sensitive: false           # schema/table 是否大小写敏感
# 若存在多源合表情况，不能打开online-ddl
online-ddl: false                # 支持上游 "gh-ost" 、"pt" 的自动处理
#online-ddl-scheme: "pt"     # `online-ddl-scheme` 在未来将会被弃用，建议使用 `online-ddl` 代替 `online-ddl-scheme`
clean-dump-file: true           # 是否清理 dump 阶段产生的文件，包括 metadata 文件、建库建表 SQL 文件以及数据导入 SQL 文件
ignore-checking-items: [ "dump_privilege" ]


# 下游 TiDB 配置信息。
target-database:
  host: "XXX"
  port: 3306
  user: "dm_target"
  password: "XXX"

# 当前数据迁移任务需要的全部上游 MySQL 实例配置。
mysql-instances:
-
  # 上游实例或者复制组 ID，参考 `inventory.ini` 的 `source_id` 或者 `dm-master.toml` 的 `source-id 配置`。
  source-id: "mysql-XXX"
  # 需要迁移的库名或表名的黑白名单的配置项名称，用于引用全局的黑白名单配置，全局配置见下面的 `block-allow-list` 的配置。
  block-allow-list: "global"          # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
  # dump 处理单元的配置项名称，用于引用全局的 dump 处理单元配置。
  mydumper-config-name: "global"

block-allow-list:                     # 如果 DM 版本 <= v2.0.0-beta.2 则使用 black-white-list。
  global:
    do-dbs: ["XXX"]

mydumpers:
  global:
    extra-args: "-B XXX"

[wuxiangdong]

貌似不支持这种写法，
先创建用户，
再加权限。