O zi bună, dragi Khabroviți! Permite-mi să mă prezint, Alexander. Administrator de sistem al unui studio WEB mic, dar mândru. Ne dorim cu adevărat ca totul să funcționeze rapid, în siguranță și cu software proaspăt. Pentru a face acest lucru, am ridicat chiar și pachetul nagios + PhantomJS pe computerul din interiorul biroului și la fiecare 30 de minute verificăm viteza de încărcare a paginii. Conform termenilor și condițiilor, monitorizăm și actualizările 1C-Bitrix și le instalăm în mod regulat. Și apoi într-o zi, după următoarea actualizare, vedem un mesaj în panoul de administrare care spune că din vara lui 2019, 1C-Bitrix nu mai funcționează cu MySQL 5.5 și trebuie actualizat. Băieții de la ISPSystem sunt frumoși și extind în mod regulat funcționalitatea panoului, pentru care le mulțumesc în mod special. Dar de data aceasta nu a fost posibil să faceți clic pe totul cu mouse-ul. Dar ce s-a întâmplat și câte fire de păr gri sunt acum în barba mea se găsesc sub tăietură.
A existat doar o opțiune de a instala un „server DBMS alternativ” care este instalat în containerul Docker. Desigur, înțeleg că Docker este foarte cumpătat cu resursele, dar oricât de grozav funcționează, suprasarcina va fi totuși > 0. Și iată-ne, parcă, ne luptăm în zecimi de secunde și optimizăm toate site-urile de la intrare înainte de a publica și a semna un acord. Deci nu alegerea mea.
Ok, ce este în documentație? Faceți backup pentru tot, adăugați un fișier cu un link către depozitul MariaDB la yum.repos.d, apoi
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonUlterior, Yum va înjură faptul că cineva a scos pachetele fără știrea lui. Dar în primul rând - lasă-l să jure, e în regulă. Și în al doilea rând, dacă faci ștergerea prin yum, atunci încearcă să demoleze, împreună cu MariaDB, tot ceea ce este legat de el prin dependențe, iar acesta este PHP și ISPManager și PHPmyadmin. Deci ne vom ocupa de bug-uri mai târziu.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonÎn general, totul a fost pus la punct și a început. Lucrul frumos este că bazele au fost ridicate și nu a fost necesară refacerea lor din gropi. Am verificat site-urile - funcționează și rapid. M-am dus la câteva panouri de administrare pentru a mă asigura că nimic nu a căzut și m-am dezabonat directorului că totul este OK. În mai puțin de 30 de minute, s-a dovedit că nici măcar nu era deloc OK...
Când am încercat să merg la panoul de administrare și să adaug ceva editat în conținut, a căzut un mesaj
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']Întrucât conținutul de pe site este adăugat de angajații noștri, clienții încă nu știau nimic și nu începuseră încă să ne despartă. Dar era o chestiune de timp, pentru că informațiile de pe site-uri trebuie actualizate, iar mulți clienți urmăresc acest lucru foarte îndeaproape.
Din textul erorii, putem concluziona că Bitrix încearcă să adauge o nouă înregistrare în baza de date, specificând în același timp aceeași cheie primară pe care o avea articolul în curs de editare. Deci, există motive să bănuim că problema apare de partea lui Bitrix. Accesați site-ul lor și contactați asistența. Aproape imediat primim răspunsul „problema dificilă. Dat inginerilor seniori - așteptați ... "
A trebuit să aștept destul de mult (întregul dialog a avut loc în perioada 25.06.2019 până în 9.07.2019) și a rezultat mesajul „această problemă nu are legătură cu funcționarea CMS-ului Bitrix, ci are legătură la funcționarea bazei de date în sine în mariadb 10.4.6 și, din păcate, cu o parte a site-ului această problemă de a rezolva posibilitatea lipsește, va fi necesară migrarea la versiunea veche a MariaDB.”
Navigat... M-am gândit la downgrade la începutul poveștii, dar că nu poate exista downgrade. Îmbinați depozitele și redistribuiți pe un server proaspăt instalat. Acestea. e bine ca nu am actualizat toate serverele odata. Acestea. „doar” o sută de site-uri (chicot nervos :-)). Ei au mai spus în sprijin: „Pentru a rezolva problema atunci când utilizați baza de date MariaDB 10.4.6, va trebui să contactați asistența tehnică MariaDB pentru ca tranzacția nu va șterge o înregistrare din baza de date dacă se face o solicitare:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Speranța a strălucit câteva ore din momentul în care am început să comunicăm cu suportul MariaDB, dar apoi am primit o scrisoare în care am fost extrem de corect informat că nu sunt un utilizator comercial și, prin urmare, nimeni nu mi-ar rezolva intenționat problema, dar există un forum pe site-ul lor și poți încerca să cauți opțiuni acolo... nu te voi plictisi cu detalii. Nu există opțiuni acolo.
DESPRE! Am achiziționat o licență pentru ISP!
Bună, sprijin? Băieți, ajutor!
- Ne pare rău, nu acceptăm bătăușii care schimbă versiunile native ale DBMS. Dacă doriți, există o opțiune cu un server alternativ în docker.
- Dar cum vor ajunge acolo utilizatorii și bazele de date? Pentru a docker?
- Ei bine, le tragi acolo cu mâinile...
- Da! Și nu uitați că portul pentru mysql se va schimba și va trebui să parcurgeți și să rescrieți toate configurațiile.
Ok, multumesc, ma voi gandi...
M-am gândit și am decis să demolez 10.4 cu mânere și să instalez 10.2 cu care nu au fost probleme pe alte servere.
Procesul nu a fost foarte diferit de procesul de actualizare. Doar că a fost necesar să schimbați 10.4 în 10.2 în linkul către depozit, să resetați și să recreați memoria cache pentru yum. Ei bine, încă un „fleac”: după eliminarea 10.4, mergem la /var/lib/mysql și ștergem totul de acolo. Fără acest pas, după instalarea 10.2, serviciul se va bloca constant și vei vedea
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"sau
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Înainte de a importa bazele de date, am setat mai întâi parola rădăcină mysql care a fost specificată în configurațiile ISP și am importat dump-ul bazei de date mysql. Ei bine, atunci, deoarece există deja utilizatori și drepturi, pur și simplu importăm toate bazele de date de utilizatori la rând cu contul root.
Textul scriptului pentru descărcarea bazei de date:
#!/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 de date, trebuie să le dezarhivați. Deci, rulați comanda
gunzip /BACK/*.gzȘi ultimul lucru: din anumite motive, cratimele sunt permise în numele bazelor de date (dacă le creați folosind ISPmanager). Dar când creați sau încercați să încărcați un dump într-o bază de date care are o cratimă în nume, primiți un mesaj că sintaxa interogării este incorectă.
Citiți până la sfârșitul tuturor binecuvântărilor. Îmi cer scuze pentru virgulele, cel mai probabil, care nu sunt spațiate - au probleme. Dacă există dorințe pentru o propunere descrisă în mod esențial - scrieți într-un personal pentru că în comentarii mi-e teamă să ratez ceva. Și nu înjură prea mult - acesta este primul meu articol 🙂
UPD1:
Aproape că am uitat să menționez: în timp ce încercam să găsesc o soluție la problemă fără să declasez MariaDB, a trebuit să actualizez cumva informațiile. A fost actualizat astfel: întreaga bază de date este convertită din InnoDB în MyISAM, infa este actualizată și apoi convertită înapoi în InooDB.
UPD2:
Tocmai am primit o scrisoare de la 1C-Bitrix cu următorul conținut:
Solicitarea de revizuire a fost finalizată
„După actualizarea mariadb la 10.4.6, a apărut o eroare la salvarea elementului infoblock”
Modul: iblock, versiune: necunoscut
Soluție: respins
Deci, deocamdată, se pare că este imposibil să actualizați la 10.4 🙁
Sursa: www.habr.com