Skip to content

MySQL DBM: recommend REFERENCES instead of SELECT for schema collection - #38606

Closed
azhou-datadog wants to merge 4 commits into
masterfrom
allen.zhou/mysql-schema-collection-privs-update
Closed

MySQL DBM: recommend REFERENCES instead of SELECT for schema collection#38606
azhou-datadog wants to merge 4 commits into
masterfrom
allen.zhou/mysql-schema-collection-privs-update

Conversation

@azhou-datadog

@azhou-datadog azhou-datadog commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Changes the "Collecting schemas" section of the MySQL Database Monitoring setup pages to recommend GRANT REFERENCES instead of GRANT 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-examples shortcode.

Motivation

MySQL exposes a table in INFORMATION_SCHEMA only to users that hold a privilege on that table. That is why this page currently asks customers to grant the Agent SELECT on 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 REFERENCES privilege 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 under REFERENCES, while SELECT on a user table returns ERROR 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

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>
@github-actions

Copy link
Copy Markdown
Contributor

Preview links (active after the build_preview check completes)

Modified Files

@azhou-datadog
azhou-datadog marked this pull request as ready for review July 30, 2026 17:26
@azhou-datadog
azhou-datadog requested review from a team as code owners July 30, 2026 17:26

@datadog-datadog-prod-us1-2 datadog-datadog-prod-us1-2 Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Datadog Autotest: PASS

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.

Was this helpful? React 👍 or 👎

📊 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>
@OliviaShoup OliviaShoup self-assigned this Jul 30, 2026
azhou-datadog and others added 2 commits July 30, 2026 15:30
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>
@jhgilbert

Copy link
Copy Markdown
Contributor

[Automated message] This PR has merge conflicts caused by the recent docs repo reorg (files moved from the repo root into hugo/). A new PR with your commits translated to the correct paths has been opened: #38894

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).

@jhgilbert jhgilbert closed this Aug 6, 2026
@jhgilbert jhgilbert added astro-reorg-autofixed Needs manual conflict resolution after replatforming reorg astro-reorg-processed Needs manual conflict resolution after replatforming reorg labels Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Architecture Everything related to the Doc backend astro-reorg-autofixed Needs manual conflict resolution after replatforming reorg astro-reorg-processed Needs manual conflict resolution after replatforming reorg

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants