Bonjour, chers Khabrovchians! Permettez-moi de me présenter, Alexander. Administrateur système d'un petit mais fier WEB-studio. Nous voulons vraiment que tout fonctionne rapidement, en toute sécurité et avec de nouveaux logiciels. Pour ce faire, ils ont même levé un tas de nagios + PhantomJS sur l'ordinateur de bureau et vérifié la vitesse de chargement des pages toutes les 30 minutes. Selon les conditions de service, nous suivons également les mises à jour de 1C-Bitrix et les installons régulièrement. Et une fois, après la prochaine mise à jour, nous voyons un message dans le panneau d'administration indiquant qu'à l'été 2019, 1C-Bitrix cesse de fonctionner avec MySQL 5.5 et doit être mis à jour. Les gars de ISPSystem sont beaux et étendent régulièrement les fonctionnalités du panneau, pour lesquelles un merci spécial à eux. Mais cette fois, il n'a pas été possible de cliquer sur toute la souris. Mais ce qui s'est passé et la quantité de cheveux gris dans ma barbe se trouvent sous la coupe.
Il n'y avait qu'une option pour mettre un «serveur SGBD alternatif» qui est placé dans le conteneur Docker. Bien sûr, je comprends que Docker est très économe en ressources, mais peu importe à quel point il fonctionne, les frais généraux seront toujours> 0. Et là, on se bat, pour ainsi dire, en dixièmes de seconde, et à l'entrée on optimise tous les sites avant de publier et signer un contrat. Ce n'est donc pas mon option.
Ok, qu'est-ce qui est écrit dans la documentation? Total de la sauvegarde, ajoutez un fichier avec un lien vers le référentiel MariaDB dans yum.repos.d, puis
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common
Yum maudira plus tard que quelqu'un ait supprimé / installé des packages à son insu. Mais d'abord - laissez-le jurer, ça va. Et deuxièmement, si vous effectuez la suppression via yum, alors il essaie de démolir avec MariaDB tout ce qui lui est lié, et c'est PHP et ISPManager et PHPmyadmin. Par conséquent, nous traiterons des gribouillis.
yum clean all yum update yum install MariaDB-server MariaDB-client MariaDB-common
En général, tout a été installé et terminé. Ce qui est bien, c'est que les bases ont été récupérées et qu'il n'a pas été nécessaire de les restaurer à partir des décharges. J'ai vérifié les sites - ils fonctionnent et rapidement. Je suis allé dans quelques pages d'administration pour m'assurer que rien ne tombait et j'ai écrit au directeur que tout allait bien. En moins de 30 minutes, il s'est avéré que ce n'était pas du tout OK ...
Lorsque vous essayez d'accéder au panneau d'administration et d'ajouter / modifier quoi que ce soit, un message est tombé dans le contenu
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']
Depuis que nos employés ajoutent du contenu au site, les clients ne savaient toujours rien et n'avaient pas encore commencé à nous séparer. Mais c'était une question de temps car les informations sur les sites doivent être mises à jour et c'est ce que de nombreux clients se suivent et suivent de près.
À partir du texte d'erreur, nous pouvons conclure que Bitrix essaie d'ajouter un nouvel enregistrement à la base de données tout en indiquant la même clé primaire que l'article édité. Il y a donc lieu de soupçonner que le problème se pose du côté de Bitrix. Nous allons sur leur site Web et nous tournons vers le support. Presque immédiatement, nous obtenons la réponse «un problème difficile. Je l'ai donné aux ingénieurs seniors - attendez ... "
J'ai dû attendre longtemps (tout le dialogue a eu lieu du 25/06/2019 au 07/09/2019) et le résultat a été le message «ce problème n'est pas lié au travail de Bitrix CMS, mais à la base de données elle-même dans mariadb 10.4.6 et malheureusement avec du côté du site ce problème pour résoudre la possibilité est manquant il faudra passer à l'ancienne version de MariaDB.
Ils sont arrivés ... J'ai pensé au déclassement au début de l'histoire, mais
ici on dit en noir et blanc qu'il ne peut y avoir de déclassement. Fusionnez les vidages et déployez à nouveau sur un serveur correctement installé. C'est-à-dire c'est bien que je n'ai pas mis à jour tous les serveurs à la fois. C'est-à-dire «Juste» une centaine de sites (un rire 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 que la transaction ne supprimera pas l'enregistrement de la base de données si la demande est faite:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]); $results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
L'espoir se réchauffe depuis quelques heures depuis le début de la communication avec le support de MariaDB, mais une lettre est arrivée dans laquelle ils m'ont correctement dit que je n'étais pas un utilisateur commercial et donc personne ne résoudrait délibérément mon problème, mais il y avait un forum sur leur site Web et vous pouviez essayer de chercher des options là-bas ... Je ne porterai pas les détails. Il n'y a pas d'options là-bas.
Oh! Nous avons une licence achetée pour ISP!
- Bonjour, support? Les gars, aidez-moi!
- Désolé, nous ne prenons pas en charge les scumbags qui modifient la version native du SGBD. Voulez-vous - il existe une option avec un autre serveur dans le docker.
- Mais comment les utilisateurs et les bases de données y arrivent-ils? Au docker?
- Eh bien, vous les faites glisser avec vos mains ...
- Oui! Et n'oubliez pas que le port de mysql va changer et que vous devrez parcourir toutes les configurations et le réécrire.
- D'accord, merci, je vais penser ...
J'ai pensé et décidé de démolir 10.4 avec des stylos et de mettre 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. Seulement, il était nécessaire dans le lien vers le référentiel de changer 10.4 en 10.2, de réinitialiser et de recréer le cache pour yum. Eh bien, une autre "bagatelle": 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 tombera 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 pour mysql qui a été enregistré dans les configurations ISP et j'ai importé le vidage de la base de données mysql. Eh bien, comme il y a déjà des utilisateurs et des droits, nous importons simplement toutes les bases d'utilisateurs d'affilée avec le compte root.
Texte du script pour le vidage de la base de données:
Avant d'importer des bases de données, vous devez les décompresser. Il suffit donc d'exécuter la commande
gunzip /BACK/*.gz
Et le dernier: pour une raison quelconque, les tirets sont autorisés dans le nom des bases de données (si vous créez via ISPmanager). Mais lorsque vous créez ou essayez de remplir le vidage dans la base de données avec un trait d'union dans le nom, vous obtenez un message indiquant que la syntaxe de la requête est incorrecte.
Lisez jusqu'à la fin de toutes les bénédictions. Je m'excuse pour les virgules les plus probablement non placées - des problèmes avec eux. S'il y a des souhaits / suggestions sur l'essence de ce qui est décrit - écrivez dans un message personnel parce que j'ai peur de manquer quelque chose dans les commentaires. Et ne jure pas beaucoup - c'est mon premier article :-)
UPD1:
J'ai presque oublié de mentionner: alors que j'essayais de trouver une solution au problème sans rétrograder MariaDB, j'ai dû mettre à jour les informations en quelque sorte. Il a été mis à jour comme suit: toute la base de données est convertie d'InnoDB en MyISAM, les informations sont mises à jour, puis elles sont reconverties en InooDB.
UPD2:
Une lettre vient d'arriver de 1C-Bitrix avec le contenu suivant:
Demande de révision mise en œuvre
"Après la mise à jour de mariadb vers 10.4.6, une erreur s'est produite lors de l'enregistrement de l'élément de bloc d'informations"
Module: iblock, version: inconnue
Solution: rejetée
Donc, même s'il est apparemment impossible de mettre à jour vers 10.4 :-(