🥇Bitrix et mise à jour de MariaDB vers la dernière version stable

Bonjour à tous les Hubbers ! Permettez-moi de me présenter, Alexandre. Administrateur système d'une petite mais fière agence WEB. Nous souhaitons vraiment que tout fonctionne rapidement, en toute sécurité et avec des logiciels à jour. Pour cela, nous avons même mis en place une combinaison nagios+PhantomJS sur un ordinateur de bureau et nous vérifions toutes les 30 minutes la vitesse de chargement des pages. Selon les conditions de service, nous surveillons également les mises à jour de 1C-Bitrix et les installons régulièrement. Un jour, après une autre mise à jour, nous avons reçu un message dans l'interface d'administration indiquant qu'à partir de l'été 2019, 1C-Bitrix ne supporterait plus MySQL 5.5 et qu'il fallait procéder à une mise à jour. Les gars d'ISPSystem sont géniaux et élargissent régulièrement les fonctionnalités du panneau, pour cela un grand merci à eux. Mais cette fois, je n'ai pas pu tout faire avec la souris. Et pour savoir ce qui s'est passé et combien de cheveux gris se retrouvent maintenant dans ma barbe, vous pouvez le découvrir ci-dessous.

Il n'y avait que l'option d'installer un "serveur de base de données alternatif" dans un conteneur Docker. Je comprends bien que Docker est très économe en ressources, mais peu importe à quel point il fonctionne bien, il y aura toujours un certain surcoût. Et ici, nous travaillons en fractions de secondes et nous optimisons tous les sites avant de les publier chez nous et de signer un contrat. Donc, ce n’est pas ma solution.
D'accord, que dit la documentation ? Sauvegarder tout, ajouter au fichier yum.repos.d un lien vers le dépôt de MariaDB, ensuite

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common

Yum se plaindra par la suite du fait que quelqu'un a supprimé ou installé des paquets sans son accord. Mais premièrement — qu'il se plaigne, ce n'est rien de grave. Et deuxièmement, si l'on fait la suppression via yum, il essaie de désinstaller avec MariaDB tout ce qui lui est lié par dépendances, y compris PHP et ISPManager et PHPMyAdmin. Donc, nous réglerons les plaintes plus tard.


yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-common

En gros, tout s'est installé et a fonctionné. Ce qui est agréable, c'est que les bases de données ont été reconnues et qu'il n'a pas été nécessaire de les restaurer à partir de sauvegardes. J'ai vérifié les sites — ils fonctionnent et rapidement. Je suis entré dans quelques interfaces d'administration pour m'assurer que rien ne s'est cassé et j'ai informé le directeur que tout va bien. Il ne s'est pas écoulé 30 minutes avant que je réalise que ce n'était pas du tout le cas…

Lors de la tentative d'accès à l'interface d'administration pour ajouter/modifier quoi que ce soit dans le contenu, un message s'affichait.

Erreur de requête MySQL : INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VALUE, VALUE_NUM) SELECT 10555, 2201, P.ID, '3607', 3607.0000 FROM b_iblock_property P WHERE ID = 184 [[1062] Entrée dupliquée '10555' pour la clé 'PRIMARY']

Puisque le contenu est ajouté sur le site par nos collègues, les clients ne savaient encore rien et n'ont pas encore commencé à nous tirer dessus. Mais c'était juste une question de temps car les informations sur les sites doivent être mises à jour, et c'est ce que de nombreux clients surveillent eux-mêmes de près.

Du texte de l'erreur, on peut conclure que Bitrix essaie d'ajouter un nouvel enregistrement dans la base de données tout en indiquant la même clé primaire que celle de l'article en cours de modification. Cela signifie qu'il y a des raisons de soupçonner que le problème se produit du côté de Bitrix. Nous allons sur leur site et contactons le support. Nous recevons presque immédiatement la réponse “problème complexe. Transmis aux ingénieurs seniors — attendez… ”

Nous avons dû attendre assez longtemps (toute la discussion s'est déroulée entre le 25.06.2019 et le 9.07.2019) et en fin de compte, nous avons reçu un message disant “ce problème n'est pas lié au fonctionnement du CMS Bitrix, mais à la base de données elle-même dans mariadb 10.4.6 et malheureusement, du côté du site, il n'est pas possible de résoudre ce problème ; il sera nécessaire de revenir à une ancienne version de MariaDB.”

Nous y sommes… J'avais pensé au downgrade dès le début de l'histoire, mais il est clairement indiqué ici, qu'il n'y aura pas de downgrade possible. Sauvegardez les dumps et réinstallez à partir d'une installation propre le serveur. C'est bien que je n'ai pas mis à jour tous les serveurs en même temps. Donc, “à peine” une centaine de sites (rire nerveux :-)). Le support a également déclaré : “Pour résoudre le problème lors de l'utilisation de la base MariaDB 10.4.6, vous devrez contacter le support technique de MariaDB, car dans la transaction, la suppression d'un enregistrement de la BDD ne s'exécutera pas si la requête est :

$DB->Query("DELETE FROM " . $strTable . " WHERE ID = " . $res["ID"]);
$results = $DB->Query("SELECT * FROM " . $strTable . " WHERE ID = " . $res["ID"]);”

L'espoir a duré quelques heures à partir du moment où j'ai commencé à discuter avec le support de MariaDB, mais ensuite j'ai reçu un e-mail me précisant de manière très polie que je n'étais pas un utilisateur commercial et que donc personne ne s'occuperait de résoudre mon problème spécifiquement, mais il y a un forum sur leur site où je peux essayer de chercher des options… Je ne vais pas vous ennuyer avec les détails. Il n'y a pas d'options là-bas.
Oh ! Nous avons une licence achetée pour ISP !
— Allô, assistance ? Les gars, aidez-moi !
— Désolé, nous ne soutenons pas les personnes qui modifient les versions natives du SGBD. Si vous le souhaitez, il y a une option avec un serveur alternatif dans Docker.
— Mais comment les utilisateurs et les bases vont-ils y accéder ? Dans Docker ?
— Eh bien, vous les y ferez entrer manuellement...
— Oui ! Et n'oubliez pas que le port pour MySQL va changer et qu'il faudra passer en revue tous les fichiers de configuration et les réécrire.
— Ok, merci, je vais réfléchir...
J'ai réfléchi et j'ai décidé finalement de désinstaller manuellement la version 10.4 et d'installer la 10.2 avec laquelle il n'y avait pas de problèmes sur d'autres serveurs.

Le processus n'était pas très différent de celui de la mise à jour. Il fallait juste changer 10.4 en 10.2 dans le lien vers le dépôt, réinitialiser et recréer le cache pour yum. Et une autre "petite chose" : après avoir supprimé 10.4, allez dans /var/lib/mysql et supprimez tout de là. Sans cette étape, après l'installation de 10.2, le service va planter en continu.

Impossible de se connecter à la base de données '' Perte de connexion au serveur MySQL lors de la lecture du paquet de communication initial, erreur système : 104 "Connexion réinitialisée par l'autre partie"

Perte de connexion au serveur MySQL lors de l'établissement de la connexion : lecture du paquet de communication initial, erreur système : 104

Avant d'importer les bases, j'ai d'abord défini le mot de passe root pour MySQL qui était indiqué dans les fichiers de configuration d'ISP et j'ai importé le dump de la base MySQL. Et ensuite, comme les utilisateurs et les droits existent déjà, j'importe simplement toutes les bases d'utilisateurs avec le compte root, l'une après l'autre.

Le texte du script pour le dump des bases :

#!/bin/bash
echo 'show databases' | mysql -u root --password="ПаРоЛь_РУТА" --skip-column-names | grep -v information_schema | xargs -I {} -t bash -c 'mysqldump -u root --password="ПаРоЛь_РУТА" {} | gzip > /BACK/back-$(hostname)-{}-$(date +%Y-%m-%d-%H.%M.%S).sql.gz'

Avant d'importer les bases, vous devez les décompresser. Donc, il suffit d'exécuter la commande

gunzip /BACK/*.gz

Et enfin : pour une raison quelconque, dans les noms des bases (si vous les créez via ISPmanager), les tirets sont autorisés. Mais lors de la création ou de la tentative d'importation d'un dump dans une base dont le nom contient un tiret, vous recevrez un message indiquant que la syntaxe de la requête est incorrecte.

À ceux qui ont tout lu jusqu'à la fin, tous mes vœux. Je m'excuse pour les virgules peut-être mal placées — c'est un problème. Si vous avez des souhaits ou des suggestions concernant ce qui a été décrit, écrivez-moi en privé car j'ai peur de manquer quelque chose dans les commentaires. Et ne soyez pas trop durs — c'est mon premier article :)

UPD1 :

J'ai failli oublier de mentionner : pendant que j'essayais de trouver une solution au problème sans rétrograder MariaDB, il fallait à un moment donné mettre à jour les informations. Cela se faisait ainsi : toute la base est convertie de InnoDB à MyISAM, les informations sont mises à jour puis elle est reconvertie en InnoDB.
UPD2 :

Je viens de recevoir un e-mail de 1C-Bitrix indiquant ce qui suit :

La demande de modification a été réalisée
« Après la mise à jour de MariaDB vers 10.4.6, une erreur est survenue lors de la sauvegarde d'un élément du bloc d'information »
Module : iblock, version : inconnue
Solution : rejetée

Donc, pour l'instant, il semble impossible de mettre à jour vers 10.4 🙁

Source : habr.com