🥇Bitrix en de update van MariaDB naar de laatste stabiele versie

Goedemiddag, gewaardeerde Habr-leden! Laat me me voorstellen, Alexander. Systeembeheerder van een kleine maar trotse webstudio. We willen heel graag dat alles snel, veilig en met actuele software functioneert. Daarom hebben we zelfs een combinatie van nagios+PhantomJS op een interne computer opgezet en controleren we elke 30 minuten de laadsnelheid van de pagina's. Volgens de onderhoudsvoorwaarden houden we ook de updates van 1C-Bitrix in de gaten en installeren we deze regelmatig. En op een dag, na weer een update, zagen we een bericht in de admin-pagina dat 1C-Bitrix vanaf de zomer van 2019 niet meer werkt met MySQL 5.5 en dat we moesten upgraden. De jongens van ISPSystem zijn geweldig en breiden de functionaliteit van de panelen regelmatig uit, waarvoor mijn dank. Maar dit keer lukte het niet om alles met de muis te klikken. Wat er is gebeurd en hoeveel grijze haren ik nu in mijn baard heb, kun je onder de kat lezen.

Er was alleen de optie om een 'alternatieve DB-server' te installeren die in een Docker-container draait. Ik begrijp dat Docker zuinig omgaat met middelen, maar hoe goed het ook werkt, er zal altijd overhead zijn >0. En wij zijn hier bezig om de laadtijden in tienden van seconden te optimaliseren voordat we de sites publiceren en een contract ondertekenen. Dus dat is niet mijn optie.
Oké, wat staat er in de documentatie? Backup alles, voeg een link naar het MariaDB-repository toe in het yum.repos.d-bestand, vervolgens

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

Yum zal later klagen dat iemand pakketten heeft verwijderd/geplaatst zonder zijn medeweten. Maar ten eerste - laat hem maar klagen, niets ernstigs. En ten tweede, als je het verwijderen via yum doet, dan probeert het samen met MariaDB alles te verwijderen wat daarmee afhankelijk is, inclusief PHP en ISPManager en PhpMyAdmin. Dus dat lossen we later wel op.


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

In het algemeen is alles geïnstalleerd en geconfigureerd. Het is prettig dat de databases zijn herkend en dat we ze niet vanuit back-ups hoefden te herstellen. Ik heb de sites gecontroleerd - ze werken en snel. Ik ging naar een paar admin-pagina's om te bevestigen dat er niets was uitgevallen en heb de directeur laten weten dat alles in orde was. Niet eens 30 minuten later bleek dat helemaal niet het geval te zijn...

Bij het proberen om in de admin-pagina te komen en iets toe te voegen of te bewerken in de content verscheen er een foutmelding.

MySQL-queryfout: 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] Dubbele invoer '10555' voor sleutel 'PRIMARY']

Aangezien de content op de website door onze eigen medewerkers wordt toegevoegd, wisten de klanten nog niets en begonnen ze ons nog niet in stukken te scheuren. Maar het was slechts een kwestie van tijd, want de informatie op de websites moet worden bijgewerkt, en hierop letten veel klanten nauwlettend zelf.

Uit de foutmelding kan worden geconcludeerd dat Bitrix probeert een nieuwe record aan de database toe te voegen met dezelfde primaire sleutel als die van het bewerkte artikel. Dit betekent dat er redenen zijn om te vermoeden dat het probleem aan de zijde van Bitrix ligt. We gaan naar hun website en nemen contact op met de ondersteuning. Bijna onmiddellijk krijgen we het antwoord: “complex probleem. We hebben het aan de senior engineers doorgegeven — wacht alstublieft…”

Het wachten duurde behoorlijk lang (de hele dialoog vond plaats tussen 25.06.2019 en 09.07.2019) en het resultaat was de boodschap “dit probleem is niet gerelateerd aan het functioneren van de CMS Bitrix, maar is gerelateerd aan de werking van de database zelf in mariadb 10.4.6 en helaas kan dit probleem vanaf de website niet worden opgelost; het is noodzakelijk om terug te gaan naar een oudere versie van MariaDB.”

We zijn er... Ik dacht aan downgrade nog aan het begin van dit verhaal, maar hier staat zwart op wit, dat er geen downgrade kan plaatsvinden. Maak backups en zet alles opnieuw op een schoon geïnstalleerde de server. Dus het is goed dat ik niet alle servers tegelijk heb bijgewerkt. Dus “slechts” een paar honderd websites (nerveuze lach:-)). Ook hebben ze in de ondersteuning gezegd: “Om het probleem op te lossen bij gebruik van database MariaDB 10.4.6, zult u contact moeten opnemen met de technische ondersteuning van MariaDB, omdat in de transactie het verwijderen van een record uit de database niet zal plaatsvinden, als de aanvraag wordt gedaan:

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

Hoopje brandde een paar uur na het begin van het gesprek met de ondersteuning van MariaDB, maar toen kwam er een bericht waarin me uiterst correct werd meegedeeld dat ik geen commerciële gebruiker ben en dus niemand mijn probleem gericht zal oplossen, maar er is een forum op hun website waar je misschien opties kunt proberen te zoeken… Ik zal u niet vermoeien met details. Er zijn daar geen opties.
Oh! We hebben toch een gekochte licentie voor ISP!
— Hallo, ondersteuning? Jongens, help ons alstublieft!
— Sorry, we do not support the freezing of native DBMS versions. If you wish, there's an option with an alternative server in Docker.
— But how will users and databases access it? In Docker?
— Well, you'll have to manually move them there…
— Yes! And don't forget that the port for MySQL will change, so you'll need to go through all the configs and rewrite them.
— Okay, thanks, I’ll think about it…
I thought it over and decided to manually uninstall 10.4 and install 10.2, which had no issues on other servers.

The process was not much different from the update process. You just needed to change 10.4 to 10.2 in the repository link, reset, and recreate the cache for yum. Oh, and one more "small thing": after removing 10.4, go to /var/lib/mysql and delete everything from there. Without this step, after installing 10.2, the service will keep crashing, and you will see

Failed to connect to the database '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

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

Before importing databases, I first set the root password for MySQL that was specified in the ISP configs and imported the MySQL database dump. Since the users and permissions already exist, we simply use the root account to import all user databases sequentially.

The script text for dumping databases:

#!/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'

Before importing databases, they need to be unzipped. So just run the command

gunzip /BACK/*.gz

And lastly: for some reason, dashes are allowed in the names of databases (if created through ISPmanager). However, when creating or attempting to upload a dump to a database with a dash in its name, you receive a message that the query syntax is incorrect.

To those who read to the end, best wishes. I apologize for probably misplaced commas — I have issues with them. If you have suggestions or feedback about the content described, please send me a private message because I'm afraid I might miss something in the comments. And don’t be too harsh — this is my first article 🙂

UPD1:

I almost forgot to mention: while I was trying to find a solution to the problem without downgrading MariaDB, I had to update the information somehow. It was updated as follows: the entire database is converted from InnoDB to MyISAM, the information is updated, and then converted back to InnoDB.
UPD2:

I just received a letter from 1C-Bitrix with the following content:

The request for improvement has been implemented
“After upgrading mariadb to 10.4.6 there’s an error when saving the information block element”
Module: iblock, versie: onbekend
Oplossing: afgewezen

Dus voorlopig kan ik blijkbaar niet naar 10.4 updaten 🙁

Bron: habr.com