Bitrix és a MariaDB legfrissebb stabil verziójára való frissítés

Jó napot kívánok, tisztelt Habr-lakók! Engedjék meg, hogy bemutatkozzam, Alekszandr vagyok. Egy kis, de büszke WEB-stúdió rendszergazdája. Nagyon szeretnénk, ha minden gyorsan, biztonságosan és friss szoftverrel működne. Ezért még egy nagios+PhantomJS kombinációt is beállítottunk az irodai számítógépen, és 30 percenként ellenőrizzük az oldalak betöltési sebességét. A karbantartási feltételek szerint figyeljük a 1C-Bitrix frissítéseit is, és ezeket rendszeresen telepítjük. Történt pedig, hogy egy újabb frissítés után az admin felületen megjelent a hír, miszerint 2019 nyarától a 1C-Bitrix nem fog működni a MySQL 5.5-tel, és frissíteni kell. Az ISPSystem srácai nagyszerűek, folyamatosan bővítik a panel funkcionalitását, ezért külön köszönet nekik. De ezúttal nem tudtam minden kattintással megoldani. Hogy mi is történt, és hogy most hány ősz hajszál van a szakállamban, azt a továbbiakban olvashatják.

Csak egy alternatív adatbázis-szerver telepítési lehetőség volt, amely Docker-konténerben működik. Tisztában vagyok vele, hogy a Docker nagyon gazdaságosan bánik az erőforrásokkal, de akármennyire jól is működik, még mindig lesz valamekkora overhead >0. Mi itt a tizedmásodpercekért küzdünk, és a belépés előtt minden webhelyet optimalizálunk, mielőtt közzétennénk és szerződést írnánk alá. Tehát ez nem az én választásom.
Rendben, mi van írva a dokumentációban? A backup mindent, hozzáadni egy yum.repos.d fájlban a MariaDB-repository hivatkozását, ezután

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

A Yum később panaszkodni fog, hogy valaki csomagokat törölt/telepített az engedélye nélkül. De egyrészt - hagyja csak panaszkodni, nem nagy ügy. Másrészt, ha a yum segítségével távolítunk el, akkor megpróbálja a MariaDB-vel együtt törölni az összes olyan csomagot is, amely rá van utalva, beleértve a PHP-t, ISPManagert és a PHPmyadmin-t is. Szóval a panaszokkal majd foglalkozunk később.


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

Összességében minden fel lett telepítve és működik. Kellemes meglepetés volt, hogy az adatbázisok maguktól csatlakoztak, és nem kellett őket visszaállítani a dumpokból. Ellenőriztem a webhelyeket - működnek és gyorsak. Beléptem néhány adminisztrátori felületre, hogy megbizonyosodjak arról, hogy semmi sem esett ki, és írtam a direktoromnak, hogy minden rendben. Nem telt el 30 perc, és kiderült, hogy egyáltalán nem minden rendben...

Amikor megpróbáltam belépni az admin felületen, és bármit hozzáadni/szerkeszteni a tartalomban, hibaüzenet jelent meg.

MySQL Lekérdezési Hiba: 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] Kiürült bejegyzés '10555' a 'PRIMARY' kulcsra]

Mivel a weboldal tartalmát a munkatársaink adják hozzá, az ügyfelek még nem tudtak semmit és addig nem kezdték el darálni minket. De ez csak idő kérdése volt, mert a weboldalakon az információt frissíteni kell, és erre sok ügyfél saját maguk figyelnek és alaposan.

A hibaüzenet alapján arra lehet következtetni, hogy a Bitrix megpróbál egy új bejegyzést hozzáadni az adatbázishoz, miközben ugyanazt a primary key-t jelölte meg, mint ami a szerkesztett cikké volt. Ezért joggal gyanakodhatunk, hogy a probléma a Bitrix oldaláról származik. Lépjünk a weboldalukra és keressük fel a támogatást. Szinte azonnal megkapjuk a választ, hogy "bonyolult probléma. Átadva a vezető mérnököknek – várj..."

Sokat kellett várni (az egész párbeszéd 2019.06.25. és 2019.07.09. között zajlott), és az eredmény egy üzenet lett: "ez a probléma nem kapcsolódik a Bitrix CMS működéséhez, hanem a mariadb 10.4.6 adatbázis működéséhez, és sajnos a weboldalon ezt a problémát megoldani nem lehet, át kell térnie egy régebbi MariaDB verzióra."

Megérkeztünk... A downgrade-ról már a történet elején gondolkodtam, de itt fekete-fehéren van megfogalmazva, hogy semmilyen downgrade nem lehetséges. Mentse le a dumpokat és telepítse újra tisztán szerveren. Tehát jó, hogy nem frissítettem egyszerre az összes szervert. Tehát "csak" száz weboldal (ideges nevetés:-)). A támogatásban azt is mondták: "A probléma megoldásához, ha a MariaDB 10.4.6 adatbázist használja, lépjen kapcsolatba a MariaDB műszaki támogatásával, mivel a tranzakció végrehajtásakor nem hajtják végre a bejegyzés törlését az adatbázisból, ha a következő lekérdezést végzi:

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

Néhány órán át élt a remény a MariaDB támogatásával folytatott beszélgetések kezdete óta, de aztán jött egy levél, amelyben rendkívül korrekt módon közölték, hogy nem vagyok kereskedelmi felhasználó, ezért senki sem fogja tudatosan megoldani a problémámat, de van egy fórum az oldalunkon, ahol próbálkozhatok lehetőségeket keresni... Nem fogom untatni a részletekkel. Nincs ott lehetőség.
Ó! Hiszen van megvásárolt licencünk az ISP-nél!
— Helló, támogatás? Fiúk, segítséget kérek!
— Sajnálom, nem támogatjuk azokat a fagyasztásokat, amelyek a DBMS natív verzióit módosítják. Ha szeretné, van egy alternatív szerver lehetőségünk Dockerben.
— De hogyan fognak oda jutni a felhasználók és az adatbázisok? Dockerben?
— Nos, a kezeitekkel kell őket átkonvertálni...
— Igen! És ne felejtsétek el, hogy a MySQL port meg fog változni, és mind a konfigurációs fájlokon végig kell menni és újra kell írni.
— Oké, köszönöm, gondolkodom rajta...
Gondolkodtam, és úgy döntöttem, hogy kézi úton eltávolítom a 10.4-et, és telepítem a 10.2-t, amellyel más szervereken nem volt probléma.

A folyamat nem különbözött nagyon az frissítési folyamattól. Csak a repository hivatkozásban a 10.4-et 10.2-re kellett cserélni, törölni és újra létrehozni a yum gyorsítótárat. Ja, és még egy "apróság": a 10.4 eltávolítása után menjünk a /var/lib/mysql mappába, és mindent onnan töröljünk. E lépés hiányában a 10.2 telepítése után a szolgáltatás folyamatosan le fog állni, és azt fogjátok látni,

Nem sikerült csatlakozni az adatbázishoz '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Vagy

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

Mielőtt importáltam az adatbázisokat, először beállítottam a MySQL root jelszót, amely az ISP konfigurációs fájlokban volt megadva, és importáltam a MySQL adatbázis dumpját. Nos, és mivel a felhasználók és az engedélyek már megvannak, egyszerűen a root fiókkal importáljuk az összes felhasználói adatbázist.

A dump adatbázisok szkriptje:

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

Az adatbázisok importálása előtt ki kell csomagolni őket. Tehát futtassuk egyszerűen a következő parancsot:

gunzip /BACK/*.gz

És végül: valamilyen oknál fogva az adatbázisok nevében (ha ISPmanageren keresztül hozod létre őket) engedélyezettek a kötőjelek. De amikor létrehozol egy adatbázist, vagy próbálsz dumpot feltölteni egy adatbázisba, amelynek nevében kötőjel van, abban az esetben hibaüzenetet kapsz arról, hogy a lekérdezés szintaxisa helytelen.

Akik eljutottak a végéig, minden jót kívánok. Elnézést, ha valamikor nem helyesen raktam le a vesszőket — a helyzet velük súlyos. Ha van javaslatotok a leírtakkal kapcsolatban, írjatok privátban, mert a megjegyzésekben félek, hogy valamit kihagyok. És ne haragudjatok túlságosan — ez az első cikkem 🙂

UPD1:

Majdnem elfelejtettem megemlíteni: míg próbáltam megoldást találni a problémámra anélkül, hogy visszalépnék MariaDB-re, valahogy frissíteni kellett az információt. Úgy frissítettem, hogy az egész adatbázist átkonvertáltam InnoDB-ből MyISAM-be, frissítettem az információt, majd visszakonvertáltam InnoDB-be.
UPD2:

Éppen most kaptam egy e-mailt a 1C-Bitrix-től a következő tartalommal:

A fejlesztési kérelem végrehajtásra került.
«A mariadb 10.4.6-ra frissítés után hiba történt az infoblock elem mentésekor.»
Modul: iblock, verzió: ismeretlen
Megoldás: elutasítva

Tehát egyelőre valószínűleg nem lehet frissíteni 10.4-re 🙁

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster