Compatibility and prerequisites

Preview

We're still working on this feature, but we'd love for you to try it out!

This feature is currently provided as part of a preview pursuant to our pre-release policies.

Before you begin monitoring your MySQL with NRDOT, ensure your environment meets these requirements.

Prerequisites

Before you begin, ensure you have the following:

Valid New Relic license key
Network connectivity between the host where you install the NRDOT Collector and your MySQL database. If you're planning to install the NRDOT Collector on a different host than your MySQL database, refer to Network access requirements.
Network connectivity to New Relic OTLP endpoints documentation
This integration is available as a part of New Relic public preview program. Check with your Organization Manager to opt in from the Previews & Trials page.

Supported MySQL versions

The receiver detects the database product and version on first connection and adjusts its behavior accordingly — unsupported/older versions still work, but with reduced functionality:

Versions	Query plans on `db.server.top_query`	Traceparent propagation	`client.port` / `network.peer.port`	Replica status syntax
`5.7.x`	No	Yes	0	`SHOW SLAVE STATUS`
`8.0.0`–`8.0.2`	No	Yes	0	`SHOW SLAVE STATUS`
`8.0.3`–`8.0.21`	Yes	Yes	0	`SHOW SLAVE STATUS`
`8.0.22+`	Yes	Yes	Populated	`SHOW REPLICA STATUS`
`8.4.x`	Yes	Yes	Populated	`SHOW REPLICA STATUS`
`9.x`	Yes	Yes	Populated	`SHOW REPLICA STATUS`

Important

Version detection is non-fatal: if it fails, the receiver falls back to MySQL < 8 behavior rather than erroring.

Network access requirements

By default, NRDOT connects over TCP (transport: tcp in the receiver config, the default). If the collector runs on the same host as the database, you can instead set transport: unix and point endpoint at the database's Unix domain socket (for example, /var/run/mysqld/mysqld.sock), which sidesteps the network checks below entirely. For any other deployment — collector and database on different hosts, containers, or VPCs — TCP is required.

Deployment	What to check
Self-managed MySQL on EC2	Security group: add an inbound rule on the DB port (default `3306`) from the collector's source — its own security group ID (same-VPC, preferred over a raw IP) if the collector runs on a different EC2 instance, or no rule needed if it runs as a sidecar on the same instance. Also check `bind-address` in `my.cnf`: many distro defaults ship `bind-address = 127.0.0.1`, which refuses any non-local TCP connection — set it to the instance's private IP or `0.0.0.0` before a remote collector can reach it.
Amazon RDS / Aurora for MySQL	VPC security group: add an inbound rule on the RDS instance's port (default `3306`) from the collector's security group or private IP; RDS has no OS-level `my.cnf` to edit, so this is the only network gate. Grants must come from the RDS master user — RDS has no `root` account. Restricted privileges: `SUPER` and `FILE` are restricted or unavailable depending on RDS engine version and parameter group. TLS: RDS instances with "Require SSL/TLS" enforcement need the collector to trust Amazon's RDS CA — set `tls.ca_file` (or `tls.ca_pem`) to the Amazon RDS certificate bundle and leave `tls.insecure`/`tls.insecure_skip_verify` at `false`.
Any remote/cross-host deployment	MySQL treats `'<user>'@'localhost'` and `'<user>'@'%'` (or a specific host/CIDR) as different accounts, even with an identical username — creating the monitoring user as `'<user>'@'localhost'` silently fails to authenticate from a collector running anywhere else, with an access-denied error indistinguishable from a wrong password. Use `'<user>'@'%'` or scope it to the collector's specific private IP/CIDR.

Important

Verified against a live Amazon RDS for MySQL instance: RDS's mysql8.0 parameter-group family exposes no performance_schema_consumer_* parameters at all — only sizing/buffer parameters plus performance_schema, slow_query_log, and long_query_time are settable there. This means events_waits_current (needed for mysql.events_waits_current.timer_wait, and wait-based dashboards generally) can only be turned on at runtime on RDS, and it doesn't survive a restart or failover.

Recommended server-side configuration

Configure these MySQL server parameters to ensure the receiver can collect all available metrics and query plans. The following table lists the parameters and their recommended values:

Parameter	Recommended value	Why
`performance_schema`	Enabled	Query samples, top queries, and blocking detection all depend on it
`max_digest_length`	`4096`	Longer digest text before MySQL truncates it
`performance_schema_max_digest_length`	`4096`	Same, at the Performance Schema layer
`performance_schema_max_sql_text_length`	`4096`	If a captured statement is truncated, the receiver skips `EXPLAIN` for it entirely. Query plans silently disappear for long statements at the `1024`-byte default

Next steps

Once you've verified your environment meets these prerequisites:

Choose your installation method:

Review the available metrics that will be collected
See advanced configuration for optional features like write-statement query plans and lock-wait duration tracking
Check our troubleshooting guide for common issues

Preview

Prerequisites .css-21sua1{background:none;border:none;width:0;padding:0;}

Supported MySQL versions

Important

Network access requirements

Important

Recommended server-side configuration

Next steps

Prerequisites