Questions about unsupported table : EVENTS in ShardingSphere-Proxy when using SQLyog

[linghengqian]

Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

• Searched open and closed GitHub issues.
• Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.
If no response anymore and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

5.0.0-RC1(From https://dist.apache.org/repos/dist/dev/shardingsphere/5.0.0-RC1/ , not master branch)

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-Proxy

Expected behavior

When I click on the library table in the SQLyog GUI to operate normally, the Proxy terminal should not have an error level log.
The following is my operation log in SQLyog.

/*[22-Oct 13:20:02][17 ms]*/ SHOW VARIABLES LIKE 'AUTOCOMMIT'; 
/*[22-Oct 13:20:02][2 ms]*/ SHOW DATABASES; 
/*[22-Oct 13:20:04][1 ms]*/ USE `sharding_db`; 
/*[22-Oct 13:20:05][2 ms]*/ SHOW FULL TABLES FROM `sharding_db` WHERE table_type = 'BASE TABLE'; 
/*[22-Oct 13:20:06][30 ms]*/ DESCRIBE `sharding_db`.`tb_result3_sharding_sphere`; 
/*[22-Oct 13:20:06][19 ms]*/ SHOW INDEX FROM `sharding_db`.`tb_result3_sharding_sphere`; 
/*[22-Oct 13:21:21][39789 ms]*/ SELECT * FROM `sharding_db`.`tb_result3_sharding_sphere` LIMIT 0, 1000; 
/*[22-Oct 13:21:21][12 ms]*/ SHOW CREATE TABLE `sharding_db`.`tb_result3_sharding_sphere`; 
/*[22-Oct 13:21:21][27 ms]*/ SHOW FULL FIELDS FROM `sharding_db`.`tb_result3_sharding_sphere`; 
/*[22-Oct 13:21:21][11 ms]*/ SHOW KEYS FROM `sharding_db`.`tb_result3_sharding_sphere`; 

Actual behavior

Of course, everything is normal in SQLyog, and the select statement is executed normally. I have not seen any abnormalities in SQLyog, but I found error level logs on the terminal of ShardingSphere-Proxy, which puzzled me.

[INFO ] 2021-10-22 13:18:32.839 [main] o.a.s.p.frontend.ShardingSphereProxy - ShardingSphere-Proxy start success
[ERROR] 2021-10-22 13:19:47.669 [Connection-5-ThreadExecutor] o.a.s.p.f.c.CommandExecutorTask - Exception occur:
java.lang.UnsupportedOperationException: unsupported table : `EVENTS`
        at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLInformationSchemaExecutorFactory.newInstance(MySQLInformationSchemaExecutorFactory.java:52)
        at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLAdminExecutorFactory.newInstance(MySQLAdminExecutorFactory.java:95)
        at org.apache.shardingsphere.proxy.backend.text.admin.DatabaseAdminBackendHandlerFactory.newInstance(DatabaseAdminBackendHandlerFactory.java:78)
        at org.apache.shardingsphere.proxy.backend.text.TextProtocolBackendHandlerFactory.newInstance(TextProtocolBackendHandlerFactory.java:86)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.<init>(MySQLComQueryPacketExecutor.java:52)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecutorFactory.newInstance(MySQLCommandExecutorFactory.java:73)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecuteEngine.getCommandExecutor(MySQLCommandExecuteEngine.java:60)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:97)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:72)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
[ERROR] 2021-10-22 13:20:03.759 [Connection-10-ThreadExecutor] o.a.s.p.f.c.CommandExecutorTask - Exception occur:
java.lang.UnsupportedOperationException: unsupported table : `EVENTS`
        at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLInformationSchemaExecutorFactory.newInstance(MySQLInformationSchemaExecutorFactory.java:52)
        at org.apache.shardingsphere.proxy.backend.text.admin.mysql.MySQLAdminExecutorFactory.newInstance(MySQLAdminExecutorFactory.java:95)
        at org.apache.shardingsphere.proxy.backend.text.admin.DatabaseAdminBackendHandlerFactory.newInstance(DatabaseAdminBackendHandlerFactory.java:78)
        at org.apache.shardingsphere.proxy.backend.text.TextProtocolBackendHandlerFactory.newInstance(TextProtocolBackendHandlerFactory.java:86)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.<init>(MySQLComQueryPacketExecutor.java:52)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecutorFactory.newInstance(MySQLCommandExecutorFactory.java:73)
        at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecuteEngine.getCommandExecutor(MySQLCommandExecuteEngine.java:60)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:97)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:72)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
[INFO ] 2021-10-22 13:20:38.681 [Connection-8-ThreadExecutor] o.a.s.p.b.t.a.m.e.i.AbstractSelectInformationExecutor$DefaultSelectInformationExecutor - Actual SQL: ds_0 ::: select `ENGINE`, `SUPPORT` from information_schema.Engines

Reason analyze (If you can)

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

Example codes for reproduce this issue (such as a github link).

The following is my configuration in Proxy.
server.yaml

mode:
  type: Cluster
  repository:
    type: ZooKeeper
    props:
      namespace: governance_ds
      server-lists: localhost:2181
      retryIntervalMilliseconds: 500
      timeToLiveSeconds: 60
      maxRetries: 3
      operationTimeoutMilliseconds: 500
  overwrite: true
rules:
  - !AUTHORITY
    users:
      - root@%:root
      - sharding233@:sharding233
    provider:
      type: ALL_PRIVILEGES_PERMITTED
  - !TRANSACTION
    defaultType: XA
    providerType: Atomikos
props:
  max-connections-size-per-query: 1
  kernel-executor-size: 16
  proxy-frontend-flush-threshold: 128
  proxy-opentracing-enabled: false
  proxy-hint-enabled: false
  sql-show: false
  check-table-metadata-enabled: false
  lock-wait-timeout-milliseconds: 50000
  show-process-list-enabled: false
  proxy-backend-query-fetch-size: -1
  check-duplicate-table-enabled: false
  sql-comment-parse-enabled: false
  proxy-frontend-executor-size: 0
  proxy-backend-executor-suitable: OLAP

config-sharding.yaml

schemaName: sharding_db
dataSources:
  ds_0:
    url: jdbc:mysql://localhost:3306/test?serverTimezone=GMT%2b8&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1
rules:
- !SHARDING
  tables:
    tb_result3_sharding_sphere:
      actualDataNodes: ds_0.tb_result3_sharding_sphere_$->{1..366}
      tableStrategy:
        standard:
          shardingColumn: datadate
          shardingAlgorithmName: tb-result3-class-based
      keyGenerateStrategy:
        column: tb_result3_id
        keyGeneratorName: snowflake
  bindingTables:
    - tb_result3_sharding_sphere
  defaultDatabaseStrategy:
    none:
  defaultTableStrategy:
    none:
  shardingAlgorithms:
    tb-result3-class-based:
      type: CLASS_BASED
      props:
        strategy: STANDARD
        algorithmClassName: com.sg8000.spi.TbResult3ShardingAlgorithm
  keyGenerators:
    snowflake:
      type: SNOWFLAKE
      props:
        worker-id: 1

[RaigorJiang]

Hi @linghengqian
Thank you for your feedback.
These abnormal logs appear because SQLyog queries information_schema.events in the background, which generally does not affect the user SQL, but only affects the metadata display of the third-party client.

[RaigorJiang]

You can refer to another issue: #11994

[RaigorJiang]

I think the question has been answered clearly, and I just close this issue now.