MySQL 5.7.40 至 TiDB 6.1 的 DM 迁移任务,报错 Error 3167: The 'INFORMATION_SCHEMA.GLOBAL_STATUS' feature is disabled

【 使用环境】测试环境
【 环境介绍】

  1. 软件版本

  2. 上游数据源及迁移任务配置

  • 上游数据源
[tidb@localhost ~]$ tiup dmctl --master-addr 192.168.3.228:8261 operate-source show

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "mysql_3_228",
            "worker": "dm-192.168.3.228-8263"
        }
    ]
}
  • 迁移任务配置
[tidb@localhost ~]$ more dm_test228.yaml 
# 1. 全局配置 
name: dm_test228                                    # 指定迁移任务名称 
task-mode: all                                      # 指定迁移模式。all 表示"全量迁移 + 增量同步" 
meta-schema: "dm_meta"                              # 指定下游储存 meta 信息的数据库,默认 dm_meta
case-sensitive: false                               # 对象名称大小写不敏感 

# 2. 定义上游 MySQL 数据源及应用的过滤规则 
mysql-instances:
  - source-id: "mysql_3_228"                            # 指定上游 MySQL 数据源的 source-id 
    block-allow-list: "ba-block-228"                    # 指定绑定的数据库对象 block-allow-list 规则 
    filter-rules: ["filter-rule-ignore"]                # 指定绑定的 binlog event filter 规则 
    route-rules: ["route-rule-228"]                     # 指定绑定的 route 路由规则   


# 3. 下游 TiDB 数据库配置 
target-database:
    host: "192.168.3.220"                           # 指定下游 TiDB 的 IP      
    port: 13390                                     # 指定下游 TiDB 数据库端口  
    user: "dm_tidb"                                 # 指定下游 TiDB 数据库用户  
    password: "1x7n9z9VKEFIj360AhYMOEBE5bjtMnQS"    # 指定 dmctl --encrypt 加密过的下游 TiDB 数据库密码  
    session:                                        # 指定连接 TiDB 时的 Session 变量 
      tidb_skip_utf8_check: 1

# 4. 定义上游 MySQL 数据库 block-allow-list、filters、routes 规则的具体内容 
# 4.1 定义 block-allow-list 规则的具体内容  
block-allow-list:                               
  ba-allow-228:                              # 数据库对象过滤规则名称        
    do-dbs: ["tpcc"]                         # 迁移哪些库,多个库名用逗号分隔    
    ignore-dbs: ["mysql", "account"]         # 忽略哪些库,多个库名用逗号分隔  

  ba-block-228:                              # 数据库对象过滤规则名称        
    ignore-tables:                           # 忽略哪些表                   
    - db-name: "tpcc"
      tbl-name: "history"                    # 忽略同步上游 tpcc.history 表 

# 4.2 定义 binlog event filter 规则的具体内容 
filters:                                            
  filter-rule-ignore:                               # binlog event 过滤规则名称 
    schema-pattern: "tpcc"                          # 库名匹配规则,支持通配符 "*" 和 "?" 
    table-pattern:  "orders"                        # 表名匹配规则,支持通配符 "*" 和 "?" 
    events: ["truncate table", "drop table"]        # 匹配哪些 event 类型 
    action: Ignore                                  # 忽略同步 events 中指定的操作事件 

# 4.3 定义 routes 规则的具体内容,即上游哪个库表同步到下游哪个库表。常用于合库、合表同步 
routes:      
  route-rule-228:                             # route 路由规则名称 
    schema-pattern: "tpcc"                    # 将上游 tpcc 数据库同步至下游 apcc 数据库            
    target-schema: "apcc"

【 故障现象】

  1. 报错内容
"errors": [
    {
      "ErrCode": 32001,
      "ErrClass": "dump-unit",
      "ErrScope": "internal",
      "ErrLevel": "high",
      "Message": "mydumper/dumpling runs with error, with output (may empty): ",
      "RawCause": "sql: SELECT `VARIABLE_NAME`,`VARIABLE_VALUE` FROM `information_schema`.`GLOBAL_STATUS` LIMIT 1, args: []: Error 3167: The 'INFORMATION_SCHEMA.GLOBAL_STATUS' feature is disabled; see the documentation for 'show_compatibility_56'",
      "Workaround": ""
    }
   ...
  ]
  1. 上游 MySQL 数据库已开启 show_compatibility_56
mysql> show global variables like 'show_com%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| show_compatibility_56 | ON    |
+-----------------------+-------+
1 row in set (0.00 sec)
  1. 通过 dm_mysql 用户执行 dumpling 对上游 MySQL 进行逻辑备份,状态正常。

修改了这个参数show_compatibility_56还不行吗?

上游已经修改过这个参数,并且重启生效了。

想问下 dm 版本也是 v6.1.0 吗?

对的,DM 与 TiDB 版本一致。

[tidb@localhost ~]$ tiup dm list
tiup is checking updates for component dm ...
Starting component `dm`: /home/tidb/.tiup/components/dm/v1.11.0/tiup-dm /home/tidb/.tiup/components/dm/v1.11.0/tiup-dm list
Name     User  Version  Path                                          PrivateKey
----     ----  -------  ----                                          ----------
dm-krui  tidb  v6.1.0   /home/tidb/.tiup/storage/dm/clusters/dm-krui  /home/tidb/.tiup/storage/dm/clusters/dm-krui/ssh/id_rsa
  1. 不懂 MySQL ,但看 DM 执行了 SELECT VARIABLE_NAME,VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS LIMIT 1 这个 SQL。可以手动执行下,结果是什么。如果是 0 或 off,应该就是问题所在。可以测下手动强改 MySQL 变量,应该能绕过这问题,但就不知道是否安全~
  2. 没在 DM 找到具体哪个 函数 发出的这个动作:thinking:,可能还是要找个懂 DM 的人来看看,我提了个 issue → https://github.com/pingcap/tiflow/issues/7559
  3. 看 mysql 8.0 已经把这东西移除了,–> https://github.com/pingcap/tidb/issues/9154 ,但你的是 MySQL 5.7.40 感觉也不会有这个问题。
1 个赞

貌似5.7.16之后这个表GLOBAL_STATUS迁移到performance_schema去了,这个查询应该才是报错的关键吧。感觉dumpling全量再增量好点

https://github.com/pingcap/tidb/issues/39027 产品问题,已经记录在这个 issue,请关注这个 issue 的进展。