Bitrix i ažuriranje MariaDB na najnoviju stabilnu verziju

Pozdrav svima, dragi članovi Habr! Dopustite da se predstavim, Aleksandar. Sistem administrator jedne male, ali ponosne WEB radionice. Želimo da sve radi brzo, sigurno i sa najnovijim softverom. Zbog toga smo čak postavili vezu nagios+PhantomJS na internoj mašini i svake 30 minuta provjeravamo brzinu učitavanja stranica. Prema uslovima održavanja, također pratimo ažuriranja 1C-Bitrix i redovno ih instaliramo. I tako, jednog dana nakon još jednog ažuriranja, u admin panelu vidimo poruku da od ljeta 2019. 1C-Bitrix prestaje raditi s MySQL 5.5 i da je potrebno ažurirati. Dečki iz ISPSystem-a su odlični i redovno proširuju funkcionalnost panela, na čemu im posebno zahvaljujemo. No, ovaj put nije bilo moguće sve uraditi mišem. O tome šta se desilo i koliko sijedih dlačica sada imam u bradi možete saznati ispod koda.

Postojala je samo mogućnost postaviti "alternativni server DB" koji se instalira u Docker kontejner. Naravno, razumem da je Docker vrlo štedljiv s resursima, ali koliko god dobro radio, preopterećenje će ipak biti >0. A mi se ovdje borimo za desetine delova sekunde i sve sajtove optimizujemo pre nego što ih objavimo i potpišemo ugovor. Dakle, to nije moj izbor.
U redu, šta piše u dokumentaciji? Backup svega, dodati u yum.repos.d datoteku sa linkom na MariaDB repozitorij, zatim

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

Yum će kasnije prigovarati što je neko brisao ili instalirao pakete bez njegovog znanja. Prvo — neka prigovara, neće biti strašno. A drugo, ako se brisanje radi putem yum, on pokušava da izbriše sve što je povezano sa MariaDB, uključujući PHP, ISPManager i PHPmyadmin. Tako da ćemo se kasnije pozabaviti prigovorima.

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

Uglavnom, sve se instaliralo i pokrenulo. Drago mi je da su se baze primile i da ih nije bilo potrebno obnavljati iz dumpova. Proverio sam sajtove — rade i brzo. Ušao sam u nekoliko admin panel-a da se uverim da ništa nije ispalo i obavestio direktora da je sve u redu. Nije prošlo ni 30 minuta kad se ispostavilo da nije sve u redu...

Prilikom pokušaja da se uđe u admin panel i doda/izmeni bilo šta u sadržaju prikazivala se poruka

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

Budući da sadržaj na stranicu dodaju naše zaposlenice, klijenti još nisu ništa znali i još uvijek nas nisu počeli isključivati. No, to je bilo pitanje vremena jer je potrebno ažurirati informacije na stranicama, a mnogi klijenti to pažljivo prate sami.

Iz poruke o grešci može se zaključiti da Bitrix pokušava dodati novu evidenciju u bazu koristeći isti primarni ključ kao kod uređivanog članka. To znači da postoji razlog za sumnju da problem nastaje na strani Bitrixa. Idemo na njihovu stranicu i kontaktiramo podršku. Gotovo odmah dobivamo odgovor "složeni problem. Predali smo starijim inženjerima - čekajte…"

Čekalo se prilično dugo (cijeli dijalog odvijao se u razdoblju od 25.06.2019. do 9.07.2019.) i rezultat je bila poruka "ovaj problem nije povezan s radom CMS-a Bitrix, već s radom same baze podataka u mariadb 10.4.6 i nažalost sa strane stranice nije moguće riješiti ovaj problem, potrebno je preći na stariju verziju MariaDB."

Stigli smo… O downgradu sam razmišljao još na početku priče, ali ovdje je crno na bijelo napisano, da nikakvog downgrada ne može biti. Izlijte dumpove i ponovo postavite na svježe instaliran serveru. To jest, dobro je što nisam sve servere odjednom ažurirao. T.j. "samo" stotinu stranica (nervozan smijeh:-)). Također su u podršci rekli: "Za rješenje problema prilikom korištenja baze MariaDB 10.4.6 trebate se obratiti tehničkoj podršci MariaDB, jer se u transakciji ne može izvršiti brisanje zapisa iz BDP-a, ako se izvrši upit:

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

Nada je trajala nekoliko sati od početka komunikacije s podrškom MariaDB, ali onda je stiglo pismo u kojem su mi veoma korektno rekli da nisam komercijalni korisnik i zato se moja problematika neće namjenski rješavati, ali postoji forum na njihovoj stranici gdje mogu pokušati potražiti rješenja… Neću vas umarati detaljima. Nema tamo rješenja.
Oh! Pa imamo kupljenu licencu za ISP!
— Halo, podrška? Momci, pomozite!
— Žao nam je, ne podržavamo zaledile koje mijenjaju nativne verzije DBMS-a. Ako želite, postoji opcija s alternativnim serverom u Dockeru.
— Ali kako će korisnici i baze doći tamo? U Docker?
— Pa, vi ćete ih tamo ručno smjestiti...
— Da! I ne zaboravite da će port za MySQL promijeniti i trebate proći kroz sve konfiguracije i prepisati.
— U redu, hvala, razmišljat ću...
Razmislio sam i odlučio konačno ručno ukloniti 10.4 i instalirati 10.2 s kojim nije bilo problema na drugim serverima.

Proces se nije mnogo razlikovao od procesa nadogradnje. Samo trebate promijeniti 10.4 u linku na repozitorij, resetirati i ponovno stvoriti predmemoriju za yum. I još jedna 'sitnica': nakon uklanjanja 10.4, idemo u /var/lib/mysql i sve odatle brišemo. Bez ovog koraka nakon instalacije 10.2, servis će se stalno rušiti i vidjet ćete

Nije se uspjelo spojiti na bazu podataka '' Izgubljena veza s MySQL serverom prilikom 'čitanja inicijalnog komunikacijskog paketa', sistemska greška: 104 "Veza resetirana od strane peer-a"

Ili

Izgubljena veza s MySQL serverom prilikom 'rukovanja: čitanje inicijalnog komunikacijskog paketa', sistemska greška: 104

Prije nego što sam uvezao baze, prvo sam postavio onaj root lozinku za mysql koja je bila navedena u ISP konfiguracijama i uvezao sam dump baze mysql. Nakon toga, budući da korisnici i prava već postoje, jednostavno s root računom uvozimo sve baze korisnika uzastopno.

Tekst skripte za dump baza:

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

Prije uvoza baza trebate ih raspakirati. Stoga jednostavno izvršite naredbu

gunzip /BACK/*.gz

I na kraju: iz nekog razloga u nazivima baza (ako ih stvarate putem ISPmanager-a) dopuštene su crte. Međutim, prilikom stvaranja ili pokušaja učitavanja dumpa u bazu koja ima crtu u nazivu, dobivate poruku da je sintaksa zahtjeva pogrešna.

Onima koji su pročitali do kraja, sve najbolje. Ispričavam se zbog vjerojatno nepostavljenih zareza — s njima je problem. Ako imate prijedloge ili želje u vezi s navedenim — pišite u privatne poruke jer se bojim da ću nešto propustiti u komentarima. I ne ljutite se previše — ovo je moj prvi članak 🙂

UPD1:

Umalo sam zaboravio spomenuti: dok sam pokušavao pronaći rješenje problema bez downgrada MariaDB, trebalo je nekako ažurirati informacije. Ažurirali su se na sljedeći način: cijela baza se pretvara iz InnoDB u MyISAM, ažurira se informacija, a zatim se ponovno pretvara nazad u InnoDB.
UPD2:

Upravo je stiglo pismo od 1C-Bitrix sljedećeg sadržaja:

Zahtjev za doradom je realiziran
„Nakon nadogradnje mariadb na 10.4.6, došlo je do pogreške prilikom spremanja elementa infobloka“
Modul: iblock, verzija: nepoznata
Rješenje: odbijeno

Dakle, očito se ne može ažurirati do 10.4 🙁

Izvor: habr.com