Before you begin monitoring your MySQL with NRDOT, ensure your environment meets these requirements.
Prerequisites
Before you begin, ensure you have the following:
- A 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
Supported MySQL versions
The receiver detects the database product and version on first connection and adjusts its behavior accordingly. Unsupported or older versions still work, but with reduced functionality:
Versions | Query plans on | Traceparent propagation |
| Replica status syntax |
|---|---|---|---|---|
| No | Yes | 0 |
|
| No | Yes | 0 |
|
| Yes | Yes | 0 |
|
| Yes | Yes | Populated |
|
| Yes | Yes | Populated |
|
| Yes | Yes | Populated |
|
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 |
Amazon RDS / Aurora for MySQL | VPC security group: add an inbound rule on the RDS instance's port (default |
Any remote/cross-host deployment | MySQL treats |
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 |
|---|---|---|
| Enabled | Query samples, top queries, and blocking detection all depend on it |
|
| Longer digest text before MySQL truncates it |
|
| Same, at the Performance Schema layer |
|
| If a captured statement is truncated, the receiver skips |
Next steps
Once you've verified your environment meets these prerequisites:
- Choose your installation method:
- Review the available metrics that will be collected
- See Enable detailed insights for optional features like write-statement query plans and lock-wait duration tracking
- Check our troubleshooting guide for common issues