Bitrix ja MariaDB värskendamine viimasesse stabiilsesse versiooni

Tere päevast, austatud Habrovichid! Lubage mul tutvustada, mina olen Aleksander. Süsteemiadministraator ühes väikeses, kuid uhkes veebistuudios. Me tahame, et kõik töötaks kiiresti, turvaliselt ja värske tarkvaraga. Selleks oleme isegi seadnud üles kontori arvutisse kombinatsiooni nagios+PhantomJS ning iga 30 minuti järel kontrollime lehtede laadimiskiirust. Teenusetingimuste kohaselt jälgime ka 1C-Bitrixi uuendusi ning installime neid regulaarselt. Ja ühel päeval, pärast uut värskendust, näeme administraatori paneelis teadet, et suvest 2019 ei toeta 1C-Bitrix enam MySQL 5.5 ja tuleb uuendada. ISPSystemi mehed on suurepärased, nad laiendavad pidevalt paneeli funktsioone, millega neile eraldi tänud. Kuid seekord ei saanud kõike hiirega klikkida. Aga seda, mis õnnestus ja kui palju on nüüd valgeid karvu mu habemes, saab lugeda allolevast lingist.

Ainult variant oli "alternatiivse andmebaasi serveri" seadistamine, mis paigaldatakse Docker-konteinerisse. Ma mõistan, et Docker on ressursitõhus, kuid olenemata sellest, kui hästi see töötab, on overhead igal juhul suurem kui 0. Meil on siinkohal tähtis, et kõik saidid oleksid optimeeritud enne avaldamist ja lepingu allkirjastamist. Seega ei sobi see variant.
Ok, mis seal dokumendis kirjas on? Varukoopia kõigest, lisage yum.repos.d faili link MariaDB hoidlatele, seejärel

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

Yum hakkab hiljem pahandama, et keegi on pakette eemaldanud või paigaldanud ilma tema teadmata. Kuid esiteks — las ta pahandab, pole hullu. Ja teiseks, kui eemaldada yum'i kaudu, siis ta püüab koos MariaDB-ga eemaldada kõik, mis on sellega seotud, sealhulgas PHP, ISPManager ja PHPmyadmin. Nii et tegeleme pahandustega hiljem.

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

Kokkuvõttes paigaldus ja tööle hakkas kõik kenasti. Hea on see, et andmebaasid kätkesid end ja neid ei pidanud taastama varukoopiatest. Kontrollisin veebisaite — kõik töötab kiirelt. Käisin paaris adminnibaasis, et veenduda, et midagi pole katki ning kirjutasin direktorile, et kõik on korras. Pole möödas isegi 30 minutit, kui selgus, et see ei ole kaugeltki korras...

Katses siseneda adminnibaasi ja lisada või redigeerida sisu kuvatakse teade

MySQL päringu viga: 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] Duplikatiivne sisestus '10555' võtme 'PRIMARY' jaoks]

Kuna sisu veebilehele lisavad meie enda töötajad, ei teadnud kliendid veel midagi ja pole veel hakanud meid ribadeks kiskuma. Kuid see oli vaid aja küsimus, kuna teavet veebilehtedel tuleb ajakohastada ja sellega jälgivad paljud kliendid ise ja tähelepanelikult.

Veateatest järeldub, et Bitrix üritab andmebaasi lisada uut kirjet, määrates samas sama primaarvõtme, mis oli muudetaval artiklil. Seega on põhjust kahtlustada, et probleem võib olla Bitrixi poolel. Lähme nende veebisaidile ja võtame ühendust toega. Peaaegu kohe saame vastuse "keeruline probleem. Edastasime vanematele inseneridele — palun oodake..."

Ootamine venis päris pikaks (kogu dialoog toimus ajavahemikus 25.06.2019 kuni 9.07.2019) ning lõpuks tuli sõnum: "see probleem ei ole seotud Bitrixi CMS-i toimimisega, vaid on seotud andmebaasi enda, mariadb 10.4.6, tõrgetega ning kahjuks ei ole probleemile veebilehe poolelt lahendust, tuleks minna tagasi vanemale MariaDB versioonile."

Oleme ummikus... Downgrade'ist mõtlesin juba loo alguses, aga siin on mustvalgel kirjutatud, et mingit downgrade'i ei saa teha. Exportige dump’id ja installige kõik uuesti puhtale süsteemile. serveril. See, it's a good thing I didn't update all the servers at once. Just a “mere” hundred websites (nervous chuckle:-)). Support also mentioned: “To resolve the issue while using MariaDB version 10.4.6, you will need to contact MariaDB technical support, as deletion of records from the database will not execute in transactions if the query is:

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

Hope lingered for a couple of hours from the moment I started communicating with MariaDB support, but then I received a letter stating, very politely, that I am not a commercial user, so my problem won't be deliberately addressed by anyone. However, there is a forum on their website where I can try to search for options… I won’t bore you with the details. There are no options there.
Oh! We have a purchased license for ISP!
— Hello, support? Guys, help!
— Sorry, we don't support individuals who change native versions of the DBMS. If you want, there's an option with an alternative server in Docker.
— But how will users and databases get there? Into Docker?
— Well, you will have to move them there manually…
— Jah! Ja ära unusta, et mysql port muutub ja tuleb kõikides konfiguratsioonides ringi käia ja need ümber kirjutada.
— Okei, aitäh, mõtlen sellele...
Mõtlesin ja otsustasin ikkagi käsitsi eemaldada 10.4 ja installida 10.2, millega teistel serveritel probleeme ei olnud.

Protsess ei erinenud oluliselt uuendamise protsessist. Ainult, et tuleb reposti lingis muuta 10.4 10.2-ks, tühjendada ja uuesti luua yum jaoks vahemälu. Ja veel üks 'pisiasi': pärast 10.4 eemaldamist mine /var/lib/mysql ja kustuta kõik sealt. Ilma selle sammuta, pärast 10.2 installimist, teenus pidevalt kukub ja sa näed.

Ei saanud andmebaasiga ühendust '' Kaotatud ühendus MySQL serveriga 'esialgse kommunikatsioonipaketi lugemisel', süsteemi viga: 104 "Ühendus lähtestati partneri poolt"

Või

Kaotatud ühendus MySQL serveriga 'kätel: sissejuhatava kommunikatsioonipaketi lugemisel', süsteemi viga: 104

Enne andmebaaside importimist seadistasin kõigepealt mysql root parooli, mis oli ISP konfiguratsioonides kirjas, ja importisin mysql andmebaasi dumpi. Ja edasi, kuna kasutajad ja õigused on juba olemas, impordime lihtsalt root konto alusel järjest kõik kasutajate andmebaasid.

Andmebaaside dumpimise skripti tekst:

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

Andmebaaside importimise eel tuleb need dekompressida. Seega täidame lihtsalt käsu

gunzip /BACK/*.gz

Ja viimane: mingil põhjusel on andmebaaside nimedes (kui loote läbi ISPmanager'i) lubatud sidekriipsud. Kuid kui proovite luua või laadida dump'i andmebaasi, mille nimes on sidekriips, saate teate, et päringu süntaks on vale.

Kellel on kannatlikkust lõpuni lugeda, kõike head. Palun vabandust ilmselt valesti paigutatud koma pärast — nende osas on probleeme. Kui on soovitusi või ettepanekuid käsitletud teema osas — kirjutage isiklikult, sest kommentaarides kardan midagi maha magada. Ja ärge palun väga pahandage — see on minu esimene artikkel 🙂

UPD1:

Peaaegu unustasin mainida: seni, kuni ma üritasin probleemi lahendust leida ilma MariaDB versiooni alandamiseta, pidin kuidagi infot uuendama. Uuendamine toimus nii: kogu andmebaas konverteeritakse InnoDB-st MyISAM-iks, info uuendatakse ja siis konverteeritakse tagasi InnoDB-sse.
UPD2:

Just sain kirja 1C-Bitrix-ilt järgmise sisuga:

Taotlus täiustamiseks on ellu viidud
„Pärast mariadb uuendamist versioonile 10.4.6 ilmus viga infoblooki elementi salvestades“
Moodul: iblock, versioon: teadmata
Lahendus: tagasi lükatud

Nii et tundub, et seni ei saa versioonile 10.4 uuendada 🙁

Allikas: habr.com