Description des bugs causés par le pilote MySQL-JDBC

Contexte du problème

La société est engagée dans un système de commerce électronique et l'ensemble du système est construit sur Huawei Cloud. Lors de la conception du système, étant donné que le nombre d'utilisateurs et de commandes ultérieurs est relativement important, certains composants de base de données volumineux doivent être utilisés. Pour la base de données relationnelle, compte tenu de la croissance rapide du volume de données ultérieur, au lieu d'écrire directement sur MySQL, le middleware de base de données distribué de Huawei Cloud, DDM a été utilisé. Après avoir utilisé DDM, vous pouvez directement augmenter le nombre d'instances de lecture MySQL sans que l'entreprise s'en rende compte, améliorant ainsi linéairement les performances de lecture. Il prend également en charge les sous-bases de données et les tables au niveau middleware, fournissant ainsi des opérations pour des bases de données relationnelles massives. Il est simplement personnalisé pour les systèmes de commerce électronique.

DDM fournit lui-même des services sous forme de cluster, et plusieurs adresses IP de connexion sont ouvertes à l'entreprise. Une couche d’équilibrage de charge est requise. Si vous utilisez la méthode traditionnelle d'ajout de LB pour l'équilibrage de charge, il y aura une couche de transit supplémentaire, ce qui entraînera des pertes de performances. Par conséquent, la capacité d'équilibrage de charge client fournie par MySQL-JDBC est directement utilisée.

La structure logique est présentée dans la figure ci-dessous :

▲L'entreprise peut fournir un accès à plusieurs nœuds DDM via l'équilibre de charge de MySQL-JDBC. MySQL-JDBC fournit des capacités d'équilibrage de charge.

Description du problème

La capacité d'équilibrage de charge client du pilote MySQL JDBC fonctionne bien et les performances sont incroyables. Mais il y a quelque temps, la demande commerciale a échoué sans raison. Je suis en charge du module de commande e-commerce, qui implique de l'argent réel. Ce problème m'a donné des sueurs froides...

J'ai donc rapidement vérifié le journal en arrière-plan et j'ai constaté qu'il y avait une exception lors de l'accès. DDM Sans rien dire, j'ai directement soumis un bon de travail au service Huawei Cloud DDM.

Je dois dire que le service Huawei Cloud est toujours très bon. En moins d'une demi-heure, un membre du personnel dévoué m'a contacté et a travaillé avec moi pour résoudre le problème.

J'ai pris les journaux de notre entreprise et les ai analysés avec le personnel d'assistance de DDM. Nous avons constaté que l'erreur a été signalée comme suit : La cause première s'est avérée être un bug dans le pilote MySQL, qui <.> a provoqué le débordement de pile local de StackOverflow ...Il s'est avéré qu'il s'agissait d'un meurtre causé par un bug. J'ai mal compris le service DDM. Je suis vraiment désolé

On peut le voir depuis la pile, une exception a déclenché un bug dans MySQL-JDBC, provoquant des appels en boucle jusqu'à ce que la pile déborde. À la suggestion du personnel d'assistance de Huawei DDM, le code du pilote a été décompilé. À partir de la décompilation, nous pouvons voir qu'il existe effectivement une possibilité d'imbrication de boucles.

Connexion d'interrogation Loadbalance -> Synchroniser l'état des nouvelles et anciennes connexions -> Envoyer SQL au serveur ->

Le code pertinent est le suivant :

Un bug si évident , pas trop évident, je pense que MySQL ne le trouvera pas. Nous utilisons actuellement la version 5.1.44 du pilote. Après avoir vérifié le dernier code 5.1.66, nous avons constaté que ce problème a effectivement été résolu :

. En filtrant les instructions SET et SHOW, l'imbrication des boucles est évitée.

Mais la version 5.1.66 a introduit un nouveau bug. Étant donné que tous les endroits où postProcess est appelé ne disposent pas de SQL, le code ici lèvera une exception de pointeur nul. Les développeurs de MySQL JDBC ne font-ils pas de tests...

Pas question, j'ai analysé le code de 5.1.44 et j'ai découvert qu'en ajustant de manière appropriée la valeur du paramètre loadBalanceAutoCommitStatementThreshold, l'imbrication de boucles peut également être évitée. . Notre environnement a été changé en 5. Après la modification, il a fonctionné sans problème pendant une semaine sans aucun problème.

Plan de modification

loadBalanceAutoCommitStatementThreshold est modifié à 5, mais le problème introduit est que si l'entreprise contient du SQL chronophage, cela peut entraîner une charge de DDM être déséquilibré. Cependant, à en juger par la situation actuelle, les performances de DDM sont encore relativement bonnes ~

Articles connexes :

BUG et stratégies pour les problèmes d'entiers MongoDB du pilote PHP

Configuration du pilote JDBC pour la base de données MySql sous WebLogic

Vidéos associées :

Tutoriel vidéo d'introduction à l'éducation booléenne Yan Shiba mysql

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!