Régler la valeur correcte de max_allowed_packet. |
Dans les configurations de réplication où les transactions importantes ou les binlogs dépassent la limite, le dépassement de la taille de max_allowed_packet peut entraîner l'entrée du réplica dans un état de copie défaillante
et le risque de bloquer le primaire. L'utilisation de colonnes BLOB ou VARTEXT pour stocker le contenu des fichiers dans les colonnes MySQL peut entraîner des problèmes de réplication et de restauration des sauvegardes. Il est recommandé
de configurer le paramètre max_allowed_packet à la valeur maximale si vous chargez des données de longueurs variables dans une colonne. En outre, n'utilisez pas plusieurs colonnes LONGBLOB larges dans une table spécifique, car cela peut
conduire à des situations où la taille des lignes dépasse le maximum autorisé et où les restaurations utilisant le point-in-time risquent de ne pas fonctionner. |
| Mettre en place des clés primaires dans les tables ayant un grand nombre de lignes. |
L'ajout d'une clé primaire à toute table > 5K lignes optimisera grandement la réplication et évitera les décalages excessifs. Il est recommandé de définir une clé primaire pour toute table pour laquelle des opérations DELETE ou UPDATE
de plus de 5K lignes sont effectuées dans des instructions uniques. Si vous ne pouvez pas ajouter de clé primaire, EFFACEZ par lots de < 5K lignes, avec des validations par lot. |
| Privilégier DROP TABLE et TRUNCATE TABLE plutôt que DELETE table entière lorsque c'est possible. |
La réplication enregistre chaque suppression de ligne, ce qui peut ralentir considérablement le processus. Il est recommandé de regrouper les suppressions et les mises à jour. Sachez que DROP, CREATE et TRUNCATE sont des instructions DDL
et qu'elles ne s'exécutent pas pendant une sauvegarde, mais attendent que l'opération de sauvegarde soit terminée. Les entrées du journal affichent des messages d'avertissement pour le moment de la sauvegarde où ces instructions se bloqueront.
Vous pouvez estimer la durée de vos sauvegardes en consultant le panneau "Disque utilisé" du tableau de bord de surveillance. En règle générale, la sauvegarde de 500 Go de données prend environ 90 minutes. |
| Réduire au minimum les opérations à plusieurs lignes dans une seule déclaration, telles que UPDATE JOIN ou DELETE, en utilisant des clauses d'intervalle WHERE pour minimiser le nombre de lignes touchées. |
Cette pratique permet d'améliorer les performances des requêtes et de réduire les blocages. |
| Utiliser la mise en commun des connexions au niveau de l'application. |
La mise en commun permet de réutiliser les connexions, ce qui évite de les saturer. Veillez à ce que la taille de votre pool soit bien inférieure à celle de la base de données max_connections. Mettre en œuvre une logique de
réessai et attraper les exceptions pour gérer l'épuisement du pool ou les échecs de connexion. |
| Réduire le rayon d'action en utilisant une instance ICD-MySQL dédiée par application de production. |
La séparation des applications réduit le volume par instance de service, minimisant ainsi les problèmes causés par l'agrégation de la demande de plusieurs applications. |
| Déployer une réplique de lecture MySQL par instance MySQL. |
Les répliques de lecture permettent de prendre en charge le trafic de lecture à partir de l'instance principale, ce qui réduit la charge de travail globale et améliore la fiabilité. |
| Hébergement d' MySQL s sur une instance dédiée |
Pour les environnements de production, en particulier ceux qui anticipent une croissance, une augmentation du trafic ou qui exigent une fiabilité et des performances élevées, nous recommandons vivement d'héberger MySQL sur une instance dédiée.
Cela garantit une meilleure isolation des ressources, une meilleure évolutivité et une meilleure stabilité globale du système. |