Jó napot, kedves Khabroviták! Engedje meg, hogy bemutatkozzam, Alexander. Egy kicsi, de büszke WEB-stúdió rendszergazdája. Nagyon szeretnénk, ha minden gyorsan, biztonságosan és friss szoftverrel működne. Ehhez még a nagios + PhantomJS köteget is megemeltük az irodán belüli számítógépen, és 30 percenként ellenőrizzük az oldal betöltési sebességét. A szolgáltatási feltételeknek megfelelően az 1C-Bitrix frissítéseit is figyeljük és rendszeresen telepítjük. Aztán egy nap, a következő frissítés után egy üzenetet látunk az adminisztrációs panelen, amely szerint 2019 nyara óta az 1C-Bitrix nem működik a MySQL 5.5-tel, és frissítésre szorul. Az ISPSystem srácai jóképűek, és rendszeresen bővítik a panel funkcionalitását, amiért külön köszönet nekik. De ezúttal nem lehetett mindenre kattintani az egérrel. De hogy mi történt, és mennyi ősz szőr van most a szakállamban, az megtalálható a vágás alatt.
Csak egy „alternatív DBMS-kiszolgáló” telepítésére volt lehetőség, amely a Docker-tárolóban van telepítve. Persze megértem, hogy a Docker nagyon takarékos az erőforrásokkal, de bármennyire is jól működik, a rezsi akkor is > 0 lesz. És itt tartunk, mintegy tizedmásodpercek alatt harcolunk, és a bejáratnál optimalizáljuk az összes webhelyet, mielőtt közzétesszük és aláírjuk a megállapodást. Szóval nem az én választásom.
Oké, mi van a dokumentációban? Készítsen biztonsági másolatot mindenről, adjon hozzá egy fájlt a MariaDB tárhelyre mutató hivatkozással a yum.repos.d fájlhoz, majd
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum ezt követően esküdni fog arra, hogy valaki a tudta nélkül távolította el a csomagokat. De először is – esküdjön meg, semmi baj. Másodszor pedig, ha a törlést a yumon keresztül hajtod végre, akkor a MariaDB-vel együtt megpróbálja lerombolni mindazt, ami függőségeken keresztül kapcsolódik hozzá, ez pedig a PHP és az ISPManager és a PHPmyadmin. Tehát később foglalkozunk a hibákkal.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonÁltalában mindent beállítottak és elkezdtek. A jó dolog az, hogy az alapokat felszedték, és nem volt szükség szeméttelepről helyreállítani. Megnéztem az oldalakat - működnek és gyorsan. Elmentem pár adminisztrációs panelre, hogy megbizonyosodjak arról, hogy semmi nem esik le, és leiratkoztam a rendezőnek, hogy minden rendben van. Kevesebb, mint 30 perc alatt kiderült, hogy egyáltalán nincs rendben...
Amikor megpróbáltam az adminisztrációs panelre lépni, és bármit módosítani akartam a tartalomban, kiesett egy üzenet
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']Mivel az oldal tartalmát munkatársaink adják hozzá, az ügyfelek még mindig nem tudtak semmit, és még nem kezdtek el minket szétszakítani. De ez idő kérdése volt, mert az oldalak információit frissíteni kell, és ezt sok ügyfél nagyon szorosan követi.
A hiba szövegéből arra következtethetünk, hogy a Bitrix megpróbál új rekordot hozzáadni az adatbázishoz, miközben ugyanazt az elsődleges kulcsot adja meg, mint a szerkesztett cikk. Tehát van okunk gyanítani, hogy a probléma a Bitrix oldalán jelentkezik. Látogasson el a webhelyükre, és lépjen kapcsolatba az ügyfélszolgálattal. Szinte azonnal azt a választ kapjuk, hogy „nehéz probléma. Odaadta a vezető mérnököknek - várjon ... "
Elég sokat kellett várnom (az egész párbeszéd 25.06.2019-9.07.2019-ig zajlott), és az eredmény az volt, hogy „ez a probléma nem a Bitrix CMS működésével kapcsolatos, hanem összefügg magának az adatbázisnak a működéséhez a mariadb 10.4.6-ban, és sajnos az oldal oldalán ez a probléma megoldása hiányzik, ezért át kell térni a MariaDB régi verziójára.”
Vitorlázva... A történet elején a visszaminősítésre gondoltam, de hogy nem lehet leminősítés. A kiíratások egyesítése és újratelepítés egy frissen telepített kiszolgálón. Azok. még jó, hogy nem frissítettem egyszerre az összes szervert. Azok. „csak” száz oldal (ideges kuncogás :-)). Támogatásként azt is elmondták: „A probléma megoldásához a MariaDB 10.4.6 adatbázis használatakor fel kell vennie a kapcsolatot a MariaDB műszaki támogatásával, hogy a tranzakció ne töröljön egy rekordot az adatbázisból, ha kérés érkezik:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
A remény pár óráig csillant attól a pillanattól kezdve, hogy elkezdtünk kommunikálni a MariaDB támogatásával, de ekkor kaptam egy levelet, amelyben rendkívül korrekt tájékoztatást kaptam, hogy nem vagyok kereskedelmi felhasználó, ezért senki nem fogja szándékosan megoldani a problémámat, de van egy fórumot a webhelyükön, és megpróbálhatsz ott lehetőségeket keresni… Nem untatlak a részletekkel. Ott nincs lehetőség.
RÓL RŐL! Megvásároltuk az ISP licencét!
Hello, támogatás? Srácok, segítsetek!
- Sajnáljuk, nem támogatjuk azokat a gengsztereket, akik megváltoztatják a DBMS natív verzióit. Ha szeretné, lehetőség van egy alternatív szerverrel a dockerben.
- De hogyan fognak odáig eljutni a felhasználók és az adatbázisok? Dockerhez?
- Hát, te húzd oda őket a kezeddel...
- Igen! És ne felejtse el, hogy a mysql portja megváltozik, és át kell mennie és át kell írnia az összes konfigurációt.
Oké, köszi, átgondolom...
Gondoltam és úgy döntöttem, hogy lebontom a 10.4-et fogantyúkkal, és telepítem a 10.2-t, amivel más szervereken nem volt probléma.
A folyamat nem sokban különbözött a frissítési folyamattól. Csak a 10.4-et 10.2-re kellett módosítani a tárhelyre mutató hivatkozásban, alaphelyzetbe állítani és újra létrehozni a yum gyorsítótárát. Nos, még egy „apróság”: a 10.4 eltávolítása után megyünk a /var/lib/mysql-be, és onnan törölünk mindent. E lépés nélkül a 10.2 telepítése után a szolgáltatás folyamatosan összeomlik, és látni fogja
Не удалось подключиться к базе данных '' 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 inital communication packet', system error: 104Az adatbázisok importálása előtt először beállítottam az ISP konfigurációkban megadott mysql root jelszót, és importáltam a mysql adatbázis kiíratását. Nos, mivel már vannak felhasználók és jogok, egyszerűen importáljuk az összes felhasználói adatbázist egymás után a root fiókkal.
Parancsfájl az adatbázis kiíratásához:
#!/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 csak futtassa a parancsot
gunzip /BACK/*.gzÉs az utolsó dolog: valamiért megengedettek a kötőjelek az adatbázisnevekben (ha az ISPmanager segítségével hozza létre őket). De amikor egy kiíratást hoz létre vagy próbál feltölteni egy olyan adatbázisba, amelynek nevében van kötőjel, egy üzenetet kap arról, hogy a lekérdezés szintaxisa hibás.
Olvassa el az összes áldás végéig. Elnézést kérek a nagy valószínűséggel szóközzel nem szereplő vesszőkért – bajban vannak. Ha van egy lényegében leírt ajánlatra vonatkozó kívánság - írja meg személyesen, mert a megjegyzésekben félek lemaradni valamiről. És ne káromkodj túl sokat – ez az első cikkem 🙂
UPD1:
Majdnem elfelejtettem megemlíteni: miközben a MariaDB leminősítése nélkül próbáltam megoldást találni a problémára, valahogy frissítenem kellett az infókat. Így lett frissítve: a teljes adatbázist InnoDB-ből MyISAM-be konvertálják, az infát frissítik, majd visszakonvertálják InooDB-be.
UPD2:
Most kaptam egy levelet az 1C-Bitrixtől a következő tartalommal:
A felülvizsgálati kérelem teljesítve
"A mariadb 10.4.6-ra való frissítése után hiba történt az infoblokk elem mentésekor"
Modul: iblock, verzió: ismeretlen
Megoldás: elutasítva
Tehát egyelőre láthatóan lehetetlen frissíteni 10.4-re 🙁
Forrás: will.com