Bitrix i ažuriranje MariaDB-a na najnoviju stabilnu verziju

Dobar dan, dragi Khabrovci! Dopustite mi da se predstavim, Alexander. Sistem administrator jednog malog ali ponosnog WEB-studija. Zaista želimo da sve radi brzo, sigurno i sa svježim softverom. Da bismo to učinili, čak smo podigli paket nagios + PhantomJS na računalu unutar ureda i svakih 30 minuta provjeravamo brzinu učitavanja stranice. Prema uvjetima usluge, također pratimo ažuriranja 1C-Bitrixa i redovito ih instaliramo. A onda jednog dana, nakon sljedećeg ažuriranja, vidimo poruku na administrativnoj ploči u kojoj stoji da od ljeta 2019. 1C-Bitrix prestaje raditi s MySQL 5.5 i treba ga ažurirati. Dečki iz ISPSystema su zgodni i redovito proširuju funkcionalnost panela, za što im svaka čast. Ali ovoga puta nije bilo moguće sve kliknuti mišem. Ali što se dogodilo i koliko je sada sijedih vlasi u mojoj bradi, vidi se ispod reza.

Postojala je samo opcija za instaliranje "alternativnog DBMS poslužitelja" koji je instaliran u Docker spremniku. Naravno, razumijem da je Docker vrlo štedljiv s resursima, ali koliko god dobro funkcionirao, režijski troškovi će i dalje biti > 0. I tu se, kao, borimo u desetinkama sekunde i optimiziramo sve stranice na ulazu prije objave i potpisivanja ugovora. Dakle, nije moj izbor.
Ok, što je u dokumentaciji? Napravite sigurnosnu kopiju svega, dodajte datoteku s vezom na repozitorij MariaDB u yum.repos.d, zatim

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

Yum će naknadno psovati na činjenicu da je netko uklonio pakete bez njegovog znanja. Ali prvo - neka opsuje, u redu je. I drugo, ako radiš brisanje preko yum-a, onda pokušava srušiti, uz MariaDB, sve što je ovisnostima vezano za njega, a to su PHP i ISPManager i PHPmyadmin. Pa ćemo se s greškama pozabaviti kasnije.


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

Općenito, sve je postavljeno i počelo. Lijepa stvar je što su baze pokupljene i nije ih bilo potrebno obnavljati s deponija. Provjerio sam stranice - rade i brzo. Otisao sam na par admin panela da se uvjerim da nije sta otpalo i odjavio direktoru da je sve OK. U manje od 30 minuta pokazalo se da uopće nije u redu...

Kad sam pokušao otići na admin ploču i dodati edit bilo što u sadržaju, ispala je 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ši zaposlenici, klijenti još ništa nisu znali i još nas nisu počeli razdvojiti. Ali bilo je pitanje vremena, jer informacije na stranicama treba ažurirati, a mnogi klijenti to vrlo pažljivo prate.

Iz teksta pogreške možemo zaključiti da Bitrix pokušava dodati novi zapis u bazu podataka, pritom navodeći isti primarni ključ koji je imao članak koji se uređuje. Dakle, postoji razlog za sumnju da se problem javlja na strani Bitrixa. Idite na njihovu web stranicu i kontaktirajte podršku. Gotovo odmah dobivamo odgovor „težak problem. Dao sam ga višim inženjerima - čekaj ... "

Morao sam čekati prilično dugo (cijeli dijalog se odvijao od 25.06.2019. do 9.07.2019.) i rezultat je bila poruka „ovaj problem nije povezan s radom Bitrix CMS-a, ali je povezan na rad same baze podataka u mariadb 10.4.6 i, nažalost, na strani stranice nedostaje mogućnost rješavanja ovog problema, bit će potrebno migrirati na staru verziju MariaDB.”

Sailed ... Mislio sam na downgrade na početku priče, ali ovdje crno-bijeloda ne može biti niže razine. Spojite ispise i ponovno postavite na svježe instalirani poslužitelj. Oni. dobro je da nisam ažurirao sve servere odjednom. Oni. “samo” stotinjak stranica (nervozni smijeh :-)). Također su rekli u podršci: “Da biste riješili problem pri korištenju baze podataka MariaDB 10.4.6, morat ćete kontaktirati tehničku podršku MariaDB da transakcija neće izbrisati zapis iz baze podataka ako se podnese zahtjev:

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

Nada je tinjala par sati od trenutka kada smo počeli komunicirati s MariaDB podrškom, ali onda sam dobio pismo u kojem sam krajnje korektno obaviješten da nisam komercijalni korisnik i stoga nitko neće ciljano rješavati moj problem, ali postoji forum na njihovoj web stranici i tamo možete pokušati potražiti opcije … neću vas zamarati detaljima. Tu nema opcija.
OKO! Kupili smo licencu za ISP-a!
Halo, podrška? Ljudi, pomozite!
- Nažalost, ne podržavamo nasilnike koji mijenjaju izvorne verzije DBMS-a. Ako želite, postoji opcija s alternativnim poslužiteljem u dockeru.
- Ali kako će korisnici i baze podataka doći tamo? Na pristanište?
- Pa, rukama ih dovučeš tamo...
- Da! I ne zaboravite da će se port za mysql promijeniti i da ćete morati proći i ponovno napisati sve konfiguracije.
Ok hvala, razmislit ću o tome...
Razmišljao sam i odlučio srušiti 10.4 s ručkama i instalirati 10.2 s kojim nije bilo problema na drugim serverima.

Proces se nije mnogo razlikovao od procesa nadogradnje. Samo je bilo potrebno promijeniti 10.4 u 10.2 u poveznici na repozitorij, resetirati i ponovno stvoriti predmemoriju za yum. Pa, još jedna "sitnica": nakon uklanjanja 10.4, idemo u /var/lib/mysql i brišemo sve od tamo. Bez ovog koraka, nakon instalacije 10.2, usluga će se stalno rušiti i vidjet ćete

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

ili

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

Prije uvoza baza podataka, prvo sam postavio mysql root lozinku koja je navedena u konfiguracijama ISP-a i uvezao dump mysql baze podataka. Pa, pošto već postoje korisnici i prava, jednostavno uvozimo sve korisničke baze podataka redom s root računom.

Tekst skripte za dump baze podataka:

#!/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 podataka, morate ih raspakirati. Dakle, samo pokrenite naredbu

gunzip /BACK/*.gz

I zadnja stvar: iz nekog razloga, crtice su dopuštene u nazivima baza podataka (ako ih kreirate pomoću ISPmanagera). Ali kada stvarate ili pokušavate učitati ispis u bazu podataka koja ima crticu u nazivu, dobivate poruku da je sintaksa upita netočna.

Pročitajte do kraja sve blagoslove. Ispričavam se zbog najvjerojatnije nerazmaknutih zareza - u problemu su. Ako ima želja za bitno opisanim prijedlogom - pišite u osobnu jer se bojim da nešto propustim u komentarima. I ne psujte previše - ovo je moj prvi članak 🙂

UPD1:

Skoro sam zaboravio napomenuti: dok sam pokušavao pronaći rješenje problema bez degradacije MariaDB-a, morao sam nekako ažurirati informacije. Ažurirano je ovako: cijela baza podataka je pretvorena iz InnoDB u MyISAM, infa je ažurirana i zatim pretvorena natrag u InooDB.
UPD2:

Upravo sam primio pismo od 1C-Bitrix sa sljedećim sadržajem:

Zahtjev za reviziju dovršen
"Nakon ažuriranja mariadb-a na 10.4.6, došlo je do pogreške prilikom spremanja elementa infobloka"
Modul: iblock, verzija: nepoznata
Rješenje: odbijeno

Dakle, za sada je očigledno nemoguće ažurirati se na 10.4 🙁

Izvor: www.habr.com

Dodajte komentar