--- title: Compatibility and prerequisites source: https://docs.newrelic.com/docs/opentelemetry/database/mysql/compatibility --- > #### 💡 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](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy/). Before you begin monitoring your MySQL with NRDOT, ensure your environment meets these requirements. ## Prerequisites [#prereq] Before you begin, ensure you have the following: - Valid New Relic [license key](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/#ingest-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). - Network connectivity to [New Relic OTLP endpoints documentation](https://docs.newrelic.com/docs/opentelemetry/best-practices/opentelemetry-otlp/) - 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](https://one.newrelic.com/admin-portal/promotion-management/home) page. ## Supported MySQL versions [#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 [#network] 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](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) and leave `tls.insecure`/`tls.insecure_skip_verify` at `false`. | | Any remote/cross-host deployment | MySQL treats `''@'localhost'` and `''@'%'` (or a specific host/CIDR) as **different accounts**, even with an identical username — creating the monitoring user as `''@'localhost'` silently fails to authenticate from a collector running anywhere else, with an access-denied error indistinguishable from a wrong password. Use `''@'%'` 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 [#server] 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 [#next] Once you've verified your environment meets these prerequisites: 1. Choose your installation method: - [Self-hosted setup](https://docs.newrelic.com/docs/opentelemetry/database/mysql/hosted) - [AWS RDS setup](https://docs.newrelic.com/docs/opentelemetry/database/mysql/rds) 2. Review the [available metrics](https://docs.newrelic.com/docs/opentelemetry/database/mysql/metrics-reference) that will be collected 3. See [advanced configuration](https://docs.newrelic.com/docs/opentelemetry/database/mysql/advanced-config) for optional features like write-statement query plans and lock-wait duration tracking 4. Check our [troubleshooting guide](https://docs.newrelic.com/docs/opentelemetry/database/mysql/troubleshooting) for common issues