[reorg fix] MySQL DBM: recommend REFERENCES instead of SELECT for schema collection - #38894
Open
jhgilbert wants to merge 4 commits into
Open
[reorg fix] MySQL DBM: recommend REFERENCES instead of SELECT for schema collection#38894jhgilbert wants to merge 4 commits into
jhgilbert 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>
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>
Contributor
|
Contributor
There was a problem hiding this comment.
More details
The shared MySQL schema-collection guidance consistently replaces table-level SELECT grants with REFERENCES, preserves database and table scopes, and adds the explain-plan procedure caveat. Source-level validation found no diff-only behavioral hazard; full Hugo rendering could not run because its external Go module download was unavailable.
📊 Validated against 5 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit 9cde562 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 Auto-generated fix for #38606.
@azhou-datadog — the docs repo reorg created merge conflicts in your PR #38606. This is an auto-generated replacement with the file paths fixed; please use it instead of the original.
This PR replays the commits from #38606 with file paths translated to the post-reorg
hugo/layout. The original commits are preserved — same messages and authorship.The original PR (#38606) will be closed in favor of this one.
Next steps:
WORK IN PROGRESSlabel from this PR.Original PR description:
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