Bună ziua, dragi utilizatori de pe Habr! Permiteți-mi să mă prezint, Alexandru. Administrator de sistem la o mică, dar mândră agenție WEB. Vrem ca totul să funcționeze rapid, sigur și cu software de ultimă oră. De aceea, am setat un sistem nagios+PhantomJS pe un calculator din birou și verificăm viteza de încărcare a paginilor la fiecare 30 de minute. Conform condițiilor de întreținere, urmărim de asemenea actualizările 1C-Bitrix și le instalăm regulat. Și așa, într-o zi, după o nouă actualizare, am văzut un mesaj în panoul de administrare că din vara lui 2019 1C-Bitrix nu va mai funcționa cu MySQL 5.5 și trebuie să ne actualizăm. Băieții de la ISPSystem sunt grozavi și extind continuu funcționalitatea panoului, pentru care le mulțumim. Dar de data aceasta nu am reușit să fac totul cu mouse-ul. Despre ce am reușit și câte fire de păr alb sunt acum în barba mea, puteți afla mai jos.
A existat doar opțiunea de a instala un „server SGBD alternativ” care se instalează în container Docker. Înțeleg, bineînțeles, că Docker este destul de eficient în utilizarea resurselor, dar oricât de bine ar funcționa, tot vor exista overhead-uri >0. Și noi ne străduim să optimizăm toate site-urile înainte de a le publica și a semna contractul. Așadar, nu este varianta mea.
Bine, ce scrie în documentație? Backup complet, adăugați în fișierul yum.repos.d un link către repository-ul MariaDB, apoi
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum va face apoi comentarii că cineva a șters/instalat pachete fără știrea lui. Dar, în primul rând - lasă-l să se plângă, nu e o problemă. În al doilea rând, dacă facem ștergerea prin yum, acesta încearcă să dezinstaleze împreună cu MariaDB tot ce este legat prin dependențe, adică și PHP, și ISPManager, și PHPmyadmin. Așa că ne vom ocupa de plângerile ulterioare.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonÎn general, totul s-a instalat și a început să funcționeze. Este plăcut că bazele de date au fost preluate și nu a fost nevoie să le restaurăm din dump-uri. Am verificat site-urile - funcționează și sunt rapide. Am intrat în câteva panouri de administrare pentru a mă asigura că nimic nu s-a stricat și am raportat directorului că totul este OK. Nu a trecut nici 30 de minute când s-a dovedit că nici pe departe nu era OK...
Când am încercat să intru în panoul de administrare și să adaug/corectez orice în conținut, mi-a apărut un mesaj de eroare
Eroare în interogarea MySQL: 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] Intrare duplicată '10555' pentru cheia 'PRIMARY']Deoarece conținutul pe site este adăugat de angajatele noastre, clienții nu știau nimic până acum și nu au început să ne „atingă”. Dar era o chestiune de timp, deoarece informațiile de pe site-uri trebuie actualizate, iar acest lucru este urmărit îndeaproape de mulți clienți.
Din textul erorii se poate deduce că Bitrix încearcă să adauge o nouă înregistrare în baza de date, specificând aceeași cheie principală ca și cea a articolului editat. Asta înseamnă că există motive să suspectăm că problema apare pe partea Bitrix. Mergem pe site-ul lor și contactăm suportul. Aproape imediat primim răspunsul 'problemă complexă. Am transmis senior inginerilor - așteptați…'
A fost nevoie să așteptăm destul de mult (întreg dialogul a avut loc în perioada 25.06.2019 - 9.07.2019) și rezultatul a fost un mesaj 'această problemă nu este legată de funcționarea CMS-ului Bitrix, ci de funcționarea bazei de date MariaDB 10.4.6, iar, din păcate, din partea site-ului nu există posibilitatea de a rezolva această problemă, va trebui să reveniți la o versiune mai veche a MariaDB.'
Am ajuns în acest punct… M-am gândit la downgrade încă de la început, dar , că nu se poate face downgrade. Faceți backup-uri și restaurați de la zero pe o instalare proaspătă. server. Așadar, este bine că nu am actualizat toate serverele deodată. Așadar, „numai” o sută de site-uri (râs nervos :-)). De asemenea, în suport mi s-a spus: „Pentru a rezolva problema utilizând baza MariaDB 10.4.6, va trebui să contactați suportul tehnic MariaDB, deoarece în tranzacții nu se va putea efectua ștergerea înregistrării din Baza de Date, dacă se face cererea:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);” Speranța a durat câteva ore de la începutul discuției cu suportul MariaDB, dar apoi a venit un email în care mi s-a comunicat cu maximă corectitudine că eu nu sunt un utilizator comercial și, prin urmare, problema mea nu va fi rezolvată intenționat de nimeni, dar există un forum pe site-ul lor și acolo pot căuta opțiuni ... Nu voi obosi cu detalii. Nu există opțiuni acolo.
O! Avem o licență cumpărată pentru ISP!
— Alo, suport? Băieți, ajutați-mă!
— Ne pare rău, nu acceptăm intervenții care modifică versiunile nativ ale SGBD-ului. Dacă doriți, există o opțiune cu un server alternativ în Docker.
— Dar cum vor ajunge utilizatorii și bazele de date acolo? În Docker?
— Păi trebuie să le aduceți manual...
— Da! Și nu uitați că portul pentru MySQL se va schimba și va trebui să verificați toate fișierele de configurare și să scrieți din nou.
— Ok, mulțumesc, mă voi gândi...
M-am gândit și am decis să dezinstalez manual 10.4 și să instalez 10.2 cu care nu am avut probleme pe celelalte servere.
Procesul nu a fost foarte diferit de actualizare. Tot ce trebuia să fac era să modific 10.4 în 10.2 în linkul către repository, să resetez și să creez din nou cache-ul pentru YUM. Și un alt detaliu: după ce am șters 10.4, mă duc în /var/lib/mysql și șterg totul de acolo. Fără acest pas, după instalarea 10.2, serviciul va cădea constant și veți vedea
Nu s-a putut conecta la baza de date '' Conexiune pierdută la serverul MySQL la 'citirea pachetului de comunicare inițial', eroare de sistem: 104 "Conexiune resetată de peer"Sau
Conexiune pierdută la serverul MySQL la 'handshake: citirea pachetului de comunicare inițial', eroare de sistem: 104Î înainte de a importa bazele, am instalat întâi parola root pentru MySQL care era specificată în fișierele de configurare ISP și am importat dump-ul bazei MySQL. Apoi, deoarece utilizatorii și permisiile erau deja configurate, am importat secvențial toate bazele de utilizatori cu contul root.
Textul scriptului pentru dump-ul bazelor:
#!/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'Înainte de a importa bazele, trebuie să le dezarhivați. Așadar, executați pur și simplu comanda
gunzip /BACK/*.gzȘi în final: dintr-un motiv oarecare, în numele bazelor (dacă le creați prin ISPmanager) sunt acceptate cratimele. Însă atunci când creați sau încercați să încărcați un dump într-o bază cu un nume care conține o cratimă, veți primi un mesaj că sintaxa interogării este greșită.
Celor care au citit până la sfârșit, toate cele bune. Îmi cer scuze pentru că, probabil, nu am pus punctele și virgulele la locul lor — este o problemă cu ele. Dacă aveți sugestii sau propuneri legate de cele descrise — scrieți-mi în privat, deoarece în comentarii îmi este teamă că voi pierde ceva. Și nu vă supărați prea tare — aceasta este prima mea articole 🙂
UPD1:
Puțin am uitat să menționez: în timp ce încercam să găsesc o soluție la problemă fără a downgrade-a MariaDB, trebuia să actualizez informațiile. S-a actualizat astfel: întreaga bază a fost convertită din InnoDB în MyISAM, informațiile au fost actualizate și apoi convertite înapoi în InnoDB.
UPD2:
Tocmai am primit un email de la 1C-Bitrix cu următorul conținut:
Cererea pentru modificare a fost implementată
„După actualizarea MariaDB la 10.4.6, a apărut o eroare la salvarea elementului din infobază“
Modul: iblock, versiune: necunoscută
Soluție: respinsă
Deci, se pare că nu putem actualiza până la 10.4 🙁
Sursa: habr.com
