🥇Bitrix ja MariaDB viimase stabiilse versiooni värskendamine

Tere, austatud Hubberid! Lubage mul end tutvustada, mina olen Aleksandr. Süsteemihaldur ühes väikeses, kuid uhkes veebistuudios. Me tõeliselt soovime, et kõik töötaks kiiresti, ohutult ja värske tarkvaraga. Selleks tõstsime isegi kontoris tööjaamas üles nagios+PhantomJS ja kontrollime iga 30 minuti tagant lehtede laadimise kiirus. Teeninduse tingimustes jälgime ka 1C-Bitrixi uuendusi ja paigaldame neid regulaarselt. Ja ühel korral pärast järjekordset uuendust näeme administraatori paneelis teadet, et suvel 2019 lõpetab 1C-Bitrix koostöö MySQL 5.5-ga ja tuleb uuendada. ISPSystemi mehed on suurepärased ning laiendavad regulaarselt paneeli funktsioone, mis on nende jaoks eraldi tänu. Kuid seekord ei õnnestunud kõiki hiireklõpse teha. Kuidas see kõik lõppes ja kui palju halli karva now minu habemes on, saate lugeda edasi.

Ainus variant oli paigaldada 'alternatiivne andmebaasirver', mis paigaldatakse Docker-konteinerisse. Ma mõistan, et Docker on ressursikasutuses üsna säästlik, kuid olenemata sellest, kui hästi see töötab, ületab ülejäänud siiski 0. Ja me püüame siin kümnendikke sekundeid ja optimeerime kõik saidid enne nende avaldamist ja lepingu allkirjastamist. Seega ei ole see minu variant.
Olgu, mida dokumentatsioonis öeldakse? Varundage kõik, lisage yum.repos.d faili link MariaDB hoidla jaoks, seejärel

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

Yum hakkab hiljem kaebama, et keegi on pakette eemaldanud ilma tema teadmiseta. Kuid esiteks — las ta kaebab, pole hullu. Teiseks, kui teha eemaldamine läbi yum, siis püüab ta koos MariaDB-ga eemaldada ka kõik, mis on temaga seotud sõltuvustega, sealhulgas PHP, ISPManager ja PHPmyAdmin. Seega saame hiljem kaebustega tegeleda.


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

Kokkuvõttes kõik paigaldati ja tööle hakkas. Tore on see, et andmebaasid said ise üles ja ei olnud vaja neid dumpidest taastada. Kontrollisin saite — need töötavad ja kiiresti. Käisin paaris admin paneelis, et veenduda, et midagi pole katki ja kirjutasin direktoris, et kõik on OK. Ei läinud 30 minutitki, kui selgus, et asjad ei ole sugugi OK…

Katsel admin paneeli siseneda ja sisu lisada/redigeerida visati välja teadet

MySQL päringuviga: 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] Korduv sisend '10555' võtme 'PRIMARY' jaoks]

Kuna sisu koguvad saidile meie töötajad, ei teadnud kliendid veel midagi ja ei olnud veel alustanud meid ribadeks rebimist. Kuid see oli aja küsimus, kuna teavet veebilehtedel tuleb uuendada ja paljud kliendid jälgivad seda ise ja hoolikalt.

Vea tekstist võib järeldada, et Bitrix üritab andmebaasi lisada uut kirjet, samal ajal kui sama esmavõti, mis oli redigeeritaval artiklil. Seega on põhjust kahtlustada, et probleem tekib Bitrixi küljel. Käime nende veebilehel ja pöördume tugiteenuse poole. Peaaegu kohe saame vastuse: "keeruline probleem. Oleme edastanud kõrgematele inseneridele - palun oodake…"

Ootamine pidi olema üsna pikk (kogu dialoog toimus ajavahemikus 25.06.2019 kuni 9.07.2019) ja tulemuseks oli teade, et "see probleem ei ole seotud CMS Bitrixi tööga, vaid seotud MariaDB 10.4.6 andmebaasi tööga ja kahjuks ei ole sellel saidil seda probleemi võimalik lahendada, tuleb minna tagasi vanemale MariaDB versioonile."

Saime kätte… Downgrade'i mõtlesin juba loo alguses, kuid siin on must ja valge öeldud, et mingit downgradet ei saa olla. Tehke dump'id ja seadke kõik nullist üles. serveris. St see on hea, et ma ei uuendanud kõiki servereid kohe. St "ainult" sada veebisaiti (närviline naer:-)). Veel ütles tugiteenus: "Probleemi lahendamiseks MariaDB 10.4.6 andmebaasi kasutamisel peate pöörduma MariaDB tehnilise toetuse poole, kuna tehingu käigus ei eemaldataks kirjeid andmebaasist, kui tehakse päring:

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

Lootus püsis paar tundi alates tuvastamisest MariaDB tugiteenusega, kuid seejärel tuli kiri, milles öeldi, et ma ei ole kommertskasutaja ja seetõttu ei lahendata minu probleemi sihipäraselt, kuid nende veebilehel on foorum, kus võib proovida variante otsida… Ei hakka tüütama detailidega. Seal ei ole mingeid variante.
Oi! Meil on ju ostetud litsents ISP jaoks!
— Tere, tugiteenus? Poisid, palun aidake!
— Vabandust, me ei toeta neid, kes muudavad andmebaasi haldurite natiivversioone. Soovite — on alternatiivne server Dockeris.
— Kuidas aga kasutajad ja andmebaasid sinna pääsevad? Dockerisse?
— No te lihtsalt viite nad sinna käsitsi...
— Jah! Ja ärge unustage, et MySQLi port muutub ning peate kõikides konfiguratsioonides läbi käima ja ümber kirjutama.
— Okei, aitäh, mõtlen sellega...
Mõtlesin ja otsustasin siiski käsitsi eemaldada 10.4 ja paigaldada 10.2, millega teistel serveritel probleeme ei olnud.

Protsess ei erinenud eriti uuendamisprotsessist. Ainult et repository lingis tuli muuta 10.4 10.2 vastu, tühjendada ja luua yum'i vahemälu uuesti. Ning veel üks "pisiasi": pärast 10.4 eemaldamist minge /var/lib/mysql ja kustutage kõik sealt välja. Ilma selle sammuta, pärast 10.2 paigaldamist, teenus pidevalt kukub ja näete

Andmebaasi juurde ei saanud ühendust '' Kadunud ühendus MySQL serveriga 'algse kommunikatsioonipaketi lugemisel', süsteemi viga: 104 "Ühendus taastatud pooli poolt"

Või

Kadunud ühendus MySQL serveriga 'käepigistus: algse kommunikatsioonipaketi lugemisel', süsteemi viga: 104

Enne kui ma andmebaase impordima hakkasin, installisin kõigepealt mysql'i root parooli, mis oli ISP konfiguratsioonides määratud, ja importisin mysql'i andmebaasi dump'i. Ja kuna kasutajad ja õigused on juba olemas, impordin lihtsalt root-konto abil kõiki kasutajate andmebaase järjest.

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

Enne andmebaaside importimist tuleb need dekomprimeerida. Seega lihtsalt käivitage käsk

gunzip /BACK/*.gz

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

Neile, kes on lõpuni lugenud, head soovid. Vabandan tõenäoliselt vale tähtsustamise pärast — nendega on probleeme. Kui on ettepanekuid või soove selle kohta, mis on välja toodud — kirjutage isiklikult, sest kardan, et kommentaaridesse midagi jätta. Ja ärge pange liiga palju pahaks — see on minu esimene artikkel 🙂

UPD1:

Peaaegu unustasin mainida: seni, kuni püüdsin leida lahendust probleemile ilma MariaDB allapoole viimiseta, pidi kuidagi infot värskendama. Infot värskendati nii: kogu andmebaas konverteeritakse InnoDB-st MyISAM-iks, infomaterjal värskendatakse ja siis konverteeritakse tagasi InnoDB-ks.
UPD2:

Just nüüd tuli kiri 1C-Bitrixilt järgmise sisuga:

Taotlus muudatuste tegemiseks on ellu viidud
«Pärast MariaDB 10.4.6 värskendamist ilmnes viga infobloki elemendi salvestamisel»
Moodul: iblock, versioon: tundmatu
Lahendus: tagasi lükatud

Nii et näib, et 10.4-le ei saa hetkel uuendada 🙁

Allikas: habr.com

Bitrix ja MariaDB uuendamine viimasele stabiilsele versioonile