Compatibilité et prérequis

Avant de commencer à monitorer votre MySQL avec NRDOT, assurez-vous que votre environnement répond à ces exigences.

Prérequis

Avant de commencer, assurez-vous d’avoir les éléments suivants :

Une clé de licenceNew Relic valide
Connectivité réseau entre l'hôte où vous installez le Collector NRDOT et votre base de données MySQL. Si vous prévoyez d'installer le Collector NRDOT sur un hôte différent de votre base de données MySQL, consultez les exigences d'accès réseau.
Connectivité réseau vers la documentation sur les points de terminaison OTLP de New Relic

Versions MySQL prises en charge

Le Récepteur détecte le produit, et la version de la base de données lors de la première connexion, et ajuste son comportement en conséquence. Les versions non prises en charge, ou plus anciennes fonctionnent toujours, mais avec une fonctionnalité réduite :

Versions	Plans de requête activés `db.server.top_query`	Propagation de traceparent	`client.port` / `network.peer.port`	Syntaxe de l'état du réplica
`8.0.3` – `8.0.21`	Oui	Oui	0	`SHOW SLAVE STATUS`
`8.0.22+`	Oui	Oui	Renseigné	`SHOW REPLICA STATUS`
`8.4.x`	Oui	Oui	Renseigné	`SHOW REPLICA STATUS`
`9.x`	Oui	Oui	Renseigné	`SHOW REPLICA STATUS`

Exigences d'accès réseau

Par défaut, NRDOT se connecte via TCP (transport: tcp dans la configuration du Récepteur, la valeur par défaut). Si le collecteur s’exécute sur le même hôte que la base de données, vous pouvez plutôt définir transport: unix et pointer endpoint vers le socket de domaine Unix de la base de données (par exemple, /var/run/mysqld/mysqld.sock), ce qui contourne entièrement les vérifications réseau ci-dessous. Pour tout autre déploiement (collecteur et base de données sur des hôtes, conteneurs ou VPC différents), TCP est requis.

déploierons	Ce qu'il faut vérifier
MySQL autogéré sur EC2	Groupe de sécurité : ajoutez une règle entrante sur le port de la base de données (par défaut `3306` ) depuis la source du collecteur : l’ID de son propre groupe de sécurité (même VPC, préféré à une IP brute) si le collecteur s’exécute sur une instance EC2 différente, ou aucune règle n’est nécessaire s’il s’exécute en tant que sidecar sur la même instance. Vérifiez également `bind-address` dans `my.cnf` : de nombreuses distributions fournissent par défaut `bind-address = 127.0.0.1` , qui refuse toute connexion TCP non locale. Définissez-le sur l’adresse IP privée de l’instance ou sur `0.0.0.0` avant qu’un collecteur distant ne puisse l’atteindre.
Amazon RDS/Aurora pour MySQL	Groupe de sécurité VPC : ajoutez une règle entrante sur le port de l’instance RDS (par défaut `3306` ) à partir du groupe de sécurité ou de l’adresse IP privée du collecteur ; RDS n’a pas de `my.cnf` au niveau du système d’exploitation à modifier, il s’agit donc de la seule passerelle réseau. Les droits doivent provenir de l’utilisateur maître RDS. RDS n’a pas de compte `root` . Privilèges restreints : `SUPER` et `FILE` sont restreints ou indisponibles selon la version du moteur RDS et le groupe de paramètres. TLS : les instances RDS avec l’obligation « Require SSL/TLS » nécessitent que le collecteur fasse confiance à l’autorité de certification RDS d’Amazon. Définissez `tls.ca_file` (ou `tls.ca_pem` ) sur le lot de certificats Amazon RDS et laissez `tls.insecure` / `tls.insecure_skip_verify` sur `false` .
Tout déploiement distant/inter-hôte	MySQL traite `'<user>'@'localhost'` et `'<user>'@'%'` (ou un hôte/CIDR spécifique) comme des comptes différents , même avec un nom d’utilisateur identique. La création de l’utilisateur de monitoring en tant que `'<user>'@'localhost'` échoue silencieusement lors de l’authentification depuis un collecteur s’exécutant n’importe où ailleurs, avec une erreur d’accès refusé impossible à distinguer d’un mot de passe incorrect. Utilisez `'<user>'@'%'` ou limitez-le à l’IP/CIDR privée spécifique du collecteur.

déploierons

Ce qu'il faut vérifier

MySQL autogéré sur EC2

Groupe de sécurité

: ajoutez une règle entrante sur le port de la base de données (par défaut

3306

) depuis la source du collecteur : l’ID de son propre groupe de sécurité (même VPC, préféré à une IP brute) si le collecteur s’exécute sur une instance EC2 différente, ou aucune règle n’est nécessaire s’il s’exécute en tant que sidecar sur la même instance. Vérifiez également

bind-address

dans

my.cnf

: de nombreuses distributions fournissent par défaut

bind-address = 127.0.0.1

, qui refuse toute connexion TCP non locale. Définissez-le sur l’adresse IP privée de l’instance ou sur

0.0.0.0

avant qu’un collecteur distant ne puisse l’atteindre.

Amazon RDS/Aurora pour MySQL

Groupe de sécurité VPC

: ajoutez une règle entrante sur le port de l’instance RDS (par défaut

3306

) à partir du groupe de sécurité ou de l’adresse IP privée du collecteur ; RDS n’a pas de

my.cnf

au niveau du système d’exploitation à modifier, il s’agit donc de la seule passerelle réseau.

Les droits

doivent provenir de l’utilisateur maître RDS. RDS n’a pas de compte

root

Privilèges restreints

SUPER

FILE

sont restreints ou indisponibles selon la version du moteur RDS et le groupe de paramètres.

TLS

: les instances RDS avec l’obligation « Require SSL/TLS » nécessitent que le collecteur fasse confiance à l’autorité de certification RDS d’Amazon. Définissez

tls.ca_file

(ou

tls.ca_pem

) sur le

lot de certificats Amazon RDS

et laissez

tls.insecure

tls.insecure_skip_verify

sur

false

Tout déploiement distant/inter-hôte

MySQL traite

'<user>'@'localhost'

'<user>'@'%'

(ou un hôte/CIDR spécifique) comme des

comptes différents

, même avec un nom d’utilisateur identique. La création de l’utilisateur de monitoring en tant que

'<user>'@'localhost'

échoue silencieusement lors de l’authentification depuis un collecteur s’exécutant n’importe où ailleurs, avec une erreur d’accès refusé impossible à distinguer d’un mot de passe incorrect. Utilisez

'<user>'@'%'

ou limitez-le à l’IP/CIDR privée spécifique du collecteur.

Important

Vérifié sur une instance Amazon RDS pour MySQL active : la famille de groupes de paramètres mysql8.0 de RDS n’expose aucun paramètre performance_schema_consumer_* du tout ; seuls les paramètres de dimensionnement/tampon, plus performance_schema, slow_query_log, et long_query_time y sont configurables. Cela signifie que events_waits_current (nécessaire pour mysql.events_waits_current.timer_wait, et les dashboards basés sur l’attente en général) ne peut être activé qu’à l’exécution sur RDS, et qu’il ne survit pas à un redémarrage, ou à un basculement.

Configuration côté serveur recommandée

Configurez ces paramètres de serveur MySQL pour vous assurer que le Récepteur peut collecter toutes les métriques et plans de requête disponibles. Le tableau suivant répertorie les paramètres et leurs valeurs recommandées :

paramètres	Valeur recommandée	Pourquoi
`performance_schema`	Activé	Les échantillons de requêtes, les requêtes principales et la détection des blocages en dépendent tous.
`max_digest_length`	`4096`	Texte de résumé plus long avant que MySQL ne le tronque
`performance_schema_max_digest_length`	`4096`	Identique, au niveau de la couche Performance Schema
`performance_schema_max_sql_text_length`	`4096`	Si une instruction capturée est tronquée, le Récepteur ignore complètement `EXPLAIN` pour celle-ci. Les plans de requête disparaissent silencieusement pour les instructions longues à la valeur par défaut de `1024` octets

Prochaines étapes

Une fois que vous avez vérifié que votre environnement respecte ces prérequis :

Choisissez votre méthode d'installation :

Consultez les métriques disponibles qui seront collectées
Consultez Activer les informations détaillées pour les fonctionnalités facultatives telles que les plans de requête d’instruction d’écriture, et le suivi de la durée d’attente de verrouillage
Consultez notre guide de dépannage pour les problèmes courants