Bitrix en MariaDB bijwerken naar de nieuwste stabiele versie

Goede dag, beste Khabrovieten! Sta mij toe mezelf voor te stellen, Alexander. Systeembeheerder van één kleine maar trotse WEB-studio. Wij willen heel graag dat alles snel, veilig en met nieuwe software werkt. Om dit te doen, hebben we zelfs de nagios + PhantomJS-bundel op de intra-office computer gezet en de laadsnelheid van de pagina elke 30 minuten gecontroleerd. Volgens de servicevoorwaarden monitoren we ook 1C-Bitrix-updates en installeren we deze regelmatig. En dan op een dag, na de volgende update, zien we een bericht in het beheerderspaneel waarin staat dat 2019C-Bitrix sinds de zomer van 1 niet meer werkt met MySQL 5.5 en moet worden bijgewerkt. De jongens van ISPSystem zijn knap en breiden regelmatig de functionaliteit van het paneel uit, waarvoor speciale dank aan hen. Maar deze keer was het niet mogelijk om alles met de muis aan te klikken. Maar wat er gebeurde en hoeveel grijze haren er nu in mijn baard zitten, vind je onder de snit.

Er was alleen een optie om een ​​“alternatieve DBMS-server” te installeren die in de Docker-container is geïnstalleerd. Natuurlijk begrijp ik dat Docker erg zuinig is met middelen, maar hoe goed het ook werkt, de overhead zal nog steeds> 0 zijn. En hier zijn we als het ware aan het vechten in tienden van seconden en het optimaliseren van alle sites bij de ingang voordat we een overeenkomst publiceren en ondertekenen. Dus niet mijn keuze.
Oké, wat staat er in de documentatie? Maak een back-up van alles, voeg vervolgens een bestand toe met een link naar de MariaDB-repository naar yum.repos.d

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

Yum zal vervolgens zweren dat iemand de pakketten zonder zijn medeweten heeft verwijderd. Maar eerst: laat hem zweren dat het goed is. En ten tweede, als je de verwijdering via yum doet, probeert het, samen met MariaDB, alles te slopen dat ermee verbonden is door afhankelijkheden, en dit zijn PHP en ISPManager en PHPmyadmin. Dus we zullen de bugs later behandelen.

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

Over het algemeen is alles opgezet en gestart. Het leuke is dat de bases zijn opgehaald en dat het niet nodig was om ze uit stortplaatsen te herstellen. Ik heb de sites gecontroleerd - ze werken en snel. Ik ging naar een paar beheerderspanelen om er zeker van te zijn dat er niets afviel en meldde me af bij de directeur dat alles in orde was. Binnen een half uur bleek dat het helemaal niet in orde was...

Toen ik probeerde naar het beheerdersdashboard te gaan en iets aan de inhoud te bewerken, viel er een bericht uit

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']

Omdat de inhoud op de site door onze medewerkers wordt toegevoegd, wisten de klanten nog steeds van niets en waren ze nog niet begonnen ons uit elkaar te drijven. Maar het was een kwestie van tijd, want de informatie op de sites moet geactualiseerd worden en veel klanten volgen dit op de voet.

Uit de tekst van de fout kunnen we concluderen dat Bitrix probeert een nieuw record aan de database toe te voegen, terwijl hij dezelfde primaire sleutel specificeert als het artikel dat wordt bewerkt. Er is dus reden om te vermoeden dat het probleem zich aan de kant van Bitrix voordoet. Ga naar hun website en neem contact op met de ondersteuning. Vrijwel onmiddellijk krijgen we het antwoord “moeilijk probleem. Gegeven aan senior ingenieurs - wacht ... "

Ik moest behoorlijk lang wachten (de hele dialoog vond plaats van 25.06.2019-9.07.2019-10.4.6 tot XNUMX-XNUMX-XNUMX) en het resultaat was de boodschap “dit probleem heeft geen betrekking op de werking van het Bitrix CMS, maar is gerelateerd aan de werking van de database zelf in mariadb XNUMX en, helaas, omdat een kant van de site om dit probleem op te lossen ontbreekt, zal het nodig zijn om naar een oudere versie van MariaDB te migreren.”

Zeilde ... Ik dacht aan het begin van het verhaal aan downgraden, maar hier in zwart-witdat er geen downgrade mogelijk is. Voeg dumps samen en implementeer opnieuw op een nieuw geïnstalleerde server. Die. het is goed dat ik niet alle servers in één keer heb bijgewerkt. Die. “slechts” honderd sites (nerveus grinniken :-)). Ze zeiden ook ter ondersteuning: “Om het probleem bij het gebruik van de MariaDB 10.4.6-database op te lossen, moet u contact opnemen met de technische ondersteuning van MariaDB dat de transactie geen record uit de database zal verwijderen als er een verzoek wordt gedaan:

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

Een paar uur lang gloorde er hoop vanaf het moment dat we begonnen te communiceren met MariaDB-ondersteuning, maar toen ontving ik een brief waarin ik uiterst correct werd geïnformeerd dat ik geen commerciële gebruiker was en dat daarom niemand mijn probleem doelbewust zou oplossen, maar er is een forum op hun website en je kunt daar naar opties zoeken … Ik zal je niet vervelen met details. Er zijn daar geen opties.
OVER! We hebben een licentie voor ISP aangeschaft!
Hallo, ondersteuning? Jongens, help!
- Sorry, we ondersteunen geen misdadigers die de oorspronkelijke versies van het DBMS wijzigen. Als je wilt, is er een optie met een alternatieve server in docker.
- Maar hoe komen gebruikers en databases daar? Aan dokken?
- Nou, je sleept ze daarheen met je handen ...
- Ja! En vergeet niet dat de poort voor mysql zal veranderen en dat u alle configuraties moet doorlopen en herschrijven.
Oké bedankt, ik zal erover nadenken...
Ik dacht en besloot 10.4 met handvatten te slopen en 10.2 te installeren waarmee op andere servers geen problemen waren.

Het proces verschilde niet veel van het upgradeproces. Alleen was het nodig om 10.4 naar 10.2 te veranderen in de link naar de repository, de cache voor yum opnieuw in te stellen en opnieuw te maken. Nog een “kleinigheidje”: na het verwijderen van 10.4 gaan we naar /var/lib/mysql en verwijderen daar alles. Zonder deze stap zal de service na installatie van 10.2 voortdurend crashen en dat zult u zien

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

Of

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

Voordat ik de databases importeerde, stelde ik eerst het mysql-rootwachtwoord in dat was opgegeven in de ISP-configuraties en importeerde ik de mysql-databasedump. Omdat er al gebruikers en rechten zijn, importeren we eenvoudigweg alle gebruikersdatabases op rij met het root-account.

Scripttekst voor databasedump:

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

Voordat u databases importeert, moet u ze uitpakken. Voer dus gewoon de opdracht uit

gunzip /BACK/*.gz

En als laatste: om de een of andere reden zijn koppeltekens toegestaan ​​in databasenamen (als u deze aanmaakt met ISPmanager). Maar wanneer u een dump maakt of probeert te uploaden naar een database met een koppelteken in de naam, krijgt u een bericht dat de syntaxis van de query onjuist is.

Lees tot het einde van alle zegeningen. Mijn excuses voor de hoogstwaarschijnlijk niet-gespatieerde komma's: ze zitten in de problemen. Als er wensen zijn voor een voorstel dat in essentie wordt beschreven, schrijf dan in een persoonlijk bericht, want in de reacties ben ik bang iets te missen. En vloek niet te veel - dit is mijn eerste artikel 🙂

UPD1:

Ik vergat bijna te vermelden: terwijl ik probeerde een oplossing voor het probleem te vinden zonder MariaDB te downgraden, moest ik op de een of andere manier de informatie bijwerken. Het werd als volgt bijgewerkt: de hele database wordt geconverteerd van InnoDB naar MyISAM, infa wordt bijgewerkt en vervolgens weer geconverteerd naar InooDB.
UPD2:

Zojuist een brief ontvangen van 1C-Bitrix met de volgende inhoud:

Revisieverzoek voltooid
"Na het updaten van mariadb naar 10.4.6 is er een fout opgetreden bij het opslaan van het infoblock-element"
Module: iblock, versie: onbekend
Oplossing: afgewezen

Dus voorlopig is het blijkbaar onmogelijk om te updaten naar 10.4 🙁

Bron: www.habr.com