Bitrix et MariaDB mettent à jour vers la dernière version stable

Bonjour, chers habitants de Khabrovsk ! Laissez-moi me présenter, Alexandre. Administrateur système d'un petit mais fier studio WEB. Nous voulons vraiment que tout fonctionne rapidement, en toute sécurité et avec les logiciels les plus récents. Pour ce faire, nous avons même monté le bundle nagios + PhantomJS sur l'ordinateur intra-bureau et toutes les 30 minutes nous vérifions la vitesse de chargement des pages. Selon les conditions de service, nous surveillons également les mises à jour 1C-Bitrix et les installons régulièrement. Et puis un jour, après la prochaine mise à jour, nous voyons un message dans le panneau d'administration indiquant que depuis l'été 2019, 1C-Bitrix cesse de fonctionner avec MySQL 5.5 et que nous devons mettre à jour. Les gars d'ISPSystem sont beaux et élargissent régulièrement les fonctionnalités du panneau, pour lesquels nous les remercions tout particulièrement. Mais cette fois-ci, il n’était pas possible de tout cliquer avec la souris. Mais vous pouvez découvrir ce qui s'est passé et combien de cheveux gris se trouvent maintenant dans ma barbe sous la coupe.

Il n'y avait qu'une option pour installer un « serveur SGBD alternatif » installé dans le conteneur Docker. Bien sûr, je comprends que Docker est très économe en ressources, mais peu importe son fonctionnement, la surcharge sera toujours > 0. Et nous voilà en quelque sorte en train de nous battre en dixièmes de secondes et d'optimiser tous les sites à l'entrée avant de publier et de signer un accord. Ce n'est donc pas mon choix.
Ok, qu'y a-t-il dans la documentation ? Sauvegardez tout, ajoutez un fichier avec un lien vers le référentiel MariaDB vers yum.repos.d, puis

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

Yum jurera par la suite que quelqu'un a supprimé les paquets à son insu. Mais avant tout, laissez-le jurer, ça va. Et deuxièmement, si vous effectuez la suppression via yum, alors il essaie de supprimer, avec MariaDB, tout ce qui lui est connecté par dépendance, et cela inclut PHP, ISPManager et PHPmyadmin. Par conséquent, nous traiterons des jurons plus tard.

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

En général, tout a été installé et démarré. Ce qui est bien, c'est que les bases de données ont été récupérées et qu'il n'a pas été nécessaire de les restaurer à partir des sauvegardes. J'ai vérifié les sites – ils fonctionnent et sont rapides. Je suis allé dans quelques zones administratives pour m'assurer que rien n'était tombé et j'ai répondu au directeur que tout allait bien. Moins de 30 minutes plus tard, il s’est avéré que tout n’allait pas du tout…

Lorsque j'ai essayé d'accéder au panneau d'administration et d'ajouter des modifications au contenu, un message est tombé

MySQL Query Error: INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) SELECT 10555 ,2201 ,P.ID ,'3607' ,3607.0000 FR OM b_iblock_property P WHERE ID = 184 [[1062] Duplicate entry '10555' for key 'PRIMARY']

Le contenu du site étant ajouté par nos propres collaborateurs, les clients ne savaient encore rien et n'ont pas encore commencé à nous déchirer. Mais ce n’était qu’une question de temps car les informations sur les sites doivent être mises à jour et de nombreux clients suivent eux-mêmes cette évolution de près.

D'après le texte de l'erreur, nous pouvons conclure que Bitrix essaie d'ajouter un nouvel enregistrement à la base de données, tout en spécifiant la même clé primaire que celle de l'article en cours d'édition. Il y a donc des raisons de soupçonner que le problème se produit du côté de Bitrix. Accédez à leur site Web et contactez le support. Presque immédiatement, nous obtenons la réponse « problème difficile ». Je l'ai donné aux ingénieurs supérieurs - attendez..."

Nous avons dû attendre assez longtemps (l'intégralité du dialogue s'est déroulée du 25.06.2019 juin 9.07.2019 au 10.4.6 juillet XNUMX) et le résultat a été le message « ce problème n'est pas lié au fonctionnement du CMS Bitrix, mais est lié au fonctionnement de la base de données elle-même dans mariadb XNUMX et, malheureusement, avec Côté site, il n'y a aucun moyen de résoudre ce problème ; vous devrez passer à l'ancienne version de MariaDB.

Ils sont arrivés... J'ai pensé au déclassement au début de l'histoire, mais ici en noir et blancqu'il ne peut y avoir de déclassement. Videz les sauvegardes et redéployez sur un serveur complètement installé. Ceux. C'est bien que je n'ai pas mis à jour tous les serveurs en même temps. Ceux. "seulement" une centaine de sites (rires nerveux :-)). Ils ont également déclaré à l'appui : « Pour résoudre le problème lors de l'utilisation de la base de données MariaDB 10.4.6, vous devrez contacter le support technique de MariaDB pour que la transaction ne supprime pas l'enregistrement de la base de données si une demande est faite :

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

L'espoir a brillé pendant quelques heures à partir du moment où j'ai commencé à communiquer avec le support MariaDB, mais j'ai ensuite reçu une lettre dans laquelle ils m'ont dit très correctement que je ne suis pas un utilisateur commercial et que donc personne ne résoudra spécifiquement mon problème, mais il y a un forum sur leur site Web et là vous pouvez essayer de chercher des options... Je ne vous ennuierai pas avec des détails. Il n’y a aucune option là-bas.
À PROPOS DE! Nous avons acheté une licence FAI !
- Bonjour, soutien ? Les gars, au secours !
— Désolé, nous ne prenons pas en charge les salauds qui modifient les versions natives du SGBD. Si vous le souhaitez, il existe une option avec un serveur alternatif dans Docker.
- Mais comment les utilisateurs et les bases de données y parviendront-ils ? Vers Docker ?
- Eh bien, tu les traînes là avec tes mains...
- Oui! Et n'oubliez pas que le port de MySQL va changer et que vous devrez parcourir toutes les configurations et les réécrire.
ok merci, je vais y réfléchir...
J'ai réfléchi et décidé de démolir 10.4 avec des poignées et d'installer 10.2 avec lequel il n'y avait aucun problème sur d'autres serveurs.

Le processus n'était pas très différent du processus de mise à jour. J'ai juste dû changer 10.4 en 10.2 dans le lien vers le référentiel, réinitialiser et recréer le cache pour miam. Eh bien, encore une « petite chose » : après avoir supprimé 10.4, allez dans /var/lib/mysql et supprimez tout à partir de là. Sans cette étape, après l'installation de la version 10.2, le service plantera constamment et vous verrez

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Ou

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

Avant d'importer les bases de données, j'ai d'abord défini le mot de passe root mysql spécifié dans les configurations du FAI et importé le dump de la base de données mysql. Eh bien, puisqu'il y a déjà des utilisateurs et des droits, nous importons simplement toutes les bases de données utilisateur d'affilée avec le compte root.

Texte du script pour le dump de la base de données :

#!/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 des bases de données, vous devez les décompresser. Nous exécutons donc simplement la commande

gunzip /BACK/*.gz

Et la dernière chose : pour une raison quelconque, les tirets sont autorisés dans les noms de bases de données (si vous les créez à l'aide d'ISPmanager). Mais lorsque vous créez ou essayez de télécharger un dump vers une base de données dont le nom comporte un trait d'union, vous recevez un message indiquant que la syntaxe de la requête est incorrecte.

Bon courage à ceux qui liront jusqu'au bout. Je m'excuse pour les virgules les plus probablement mal placées - elles posent problème. Si vous avez des suggestions concernant l'essence de ce qui est décrit, écrivez un message personnel car j'ai peur de manquer quelque chose dans les commentaires. Et ne jure pas trop, c'est mon premier article :)

UPD1 :

J'ai presque oublié de mentionner : pendant que j'essayais de trouver une solution au problème sans rétrograder MariaDB, j'ai dû d'une manière ou d'une autre mettre à jour les informations. Il a été mis à jour comme ceci : la base de données entière est convertie d'InnoDB en MyISAM, infa est mis à jour puis reconverti en InooDB.
UPD2 :

Je viens de recevoir une lettre de 1C-Bitrix avec le contenu suivant :

Demande de révision complétée
"Après la mise à niveau de mariadb vers 10.4.6, une erreur s'est produite lors de l'enregistrement d'un élément infoblock"
Module : iblock, version : inconnue
Solution : rejetée

Donc pour l'instant, apparemment il est impossible de mettre à jour vers la 10.4 🙁

Source: habr.com