MySQLdump - Ver 10.13 Distrib 5.7.31 - possible bug ?

[Jesús Delgado Ramírez]

Hi everyone,

I'm experiencing an unexpected issue with mysqldump after granting SHOW VIEW privileges to our backup user. Hoping someone can help clarify if this is expected behavior or a potential bug.

Background

We have MySQL 5.7 with InnoDB Cluster configured. Our backup script has been running successfully for years using a dedicated backup user with SELECT, PROCESS, EVENT and LOCK TABLES privileges.

What happened :

Last Friday, we created a view and needed to grant SHOW VIEW privilege to our backup user for it to work. After adding this privilege, our backup started failing with:


mysqldump: Couldn't execute 'show fields from `async_cluster_members`':
SELECT command denied to user 'xxxxx'@'xxxxx' for table 'async_cluster_members' (1142)

Before granting SHOW VIEW, mysqldump was working fine and completely ignoring the mysql_innodb_cluster_metadata schema (which has existed since 2020). After adding SHOW VIEW, mysqldump suddenly started trying to access tables in this schema.


We're using: mysqldump flags : --all-databases --single-transaction --flush-privileges --hex-blob --triggers --routines --events --set-gtid-purged=AUTO


Evidence:
Previous backups contain NO CREATE DATABASE statement for mysql_innodb_cluster_metadata
Previous backups only show permission references to this schema in mysql.db table
After SHOW VIEW: mysqldump attempts to dump the actual cluster metadata tables


Is this expected behavior? The documentation for SHOW VIEW doesn't mention any impact on schema enumeration.
Does --all-databases combined with SHOW VIEW change how mysqldump discovers schemas?
Should SHOW VIEW affect which databases mysqldump attempts to process?


Thanks for any insights!

jdelgado