MySQL DBM: recommend REFERENCES instead of SELECT for schema collection - #38606
MySQL DBM: recommend REFERENCES instead of SELECT for schema collection#38606azhou-datadog wants to merge 4 commits into
Conversation
MySQL exposes a table in INFORMATION_SCHEMA only to users holding a privilege on it, which is why we currently ask customers to grant the Agent SELECT on their tables. The REFERENCES privilege satisfies the same visibility check without granting any ability to read table data, so the Agent gets identical schema metadata with no read access to customer data. Also drop the per-column scoping option, which produces incomplete schemas (a column-level grant exposes only the granted columns), and add a troubleshooting entry for the "no tables were found" warning. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Preview links (active after the
|
There was a problem hiding this comment.
More details
The shared MySQL schema section consistently renders the REFERENCES-based grants across all five English setup pages, and the new troubleshooting link targets the shortcode's collecting-schemas anchor. Adversarial checks found no diff-only behavioral hazard; a full Hugo render was unavailable because Corepack could not download Yarn in the sandbox.
📊 Validated against 7 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit 829f4df · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
Verified in a sandbox: with REFERENCES in place of SELECT, explain plans still work through the explain_statement definer procedure, but the Agent's last-resort STATEMENT strategy (a direct EXPLAIN as the datadog user) fails with ERROR 1142. Customers who never created the per-schema procedure would silently lose explain plans, so call it out. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The remainder of the warning changes between Agent versions (it now names REFERENCES rather than SELECT), and older Agents will be in the field for a while, so matching on the full string would not hold. The first sentence is stable across versions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
[Automated message] This PR has merge conflicts caused by the recent docs repo reorg (files moved from the repo root into Please follow the instructions in the PR description. This is an automated comment, but if you have a question, you can mention me in this PR (external contributors) or reach out in #docs-repo-reorg-support on Slack (internal contributors). |
What does this PR do?
Changes the "Collecting schemas" section of the MySQL Database Monitoring setup pages to recommend
GRANT REFERENCESinstead ofGRANT SELECT, drops the per-column scoping option, and adds a troubleshooting entry for the "no tables were found" warning.Affects all five MySQL setup pages (self-hosted, RDS, Aurora, Azure, Cloud SQL), since they share the
dbm-mysql-agent-config-examplesshortcode.Motivation
MySQL exposes a table in
INFORMATION_SCHEMAonly to users that hold a privilege on that table. That is why this page currently asks customers to grant the AgentSELECTon their tables, and why it has to reassure them in prose that "the Agent does not use SELECT to access or read your table data."The
REFERENCESprivilege satisfies the same visibility requirement and grants no ability to read data at all, so we can stop asking for read access on customer data and the reassurance becomes a property of the grant rather than a promise. Testing across MySQL 5.7 / 8.0 / 8.4 / 9.x and MariaDB 10.11 / 11.4 confirmed the Agent collects a byte-identical schema payload underREFERENCES, whileSELECTon a user table returnsERROR 1142. The privilege is grantable on RDS/Aurora, Cloud SQL, and Azure Database for MySQL.The per-column option is removed because a column-level grant exposes only the granted columns, so it yields an incomplete schema.
Preview links