Dobrý deň, drahí Khabroviti! Dovoľte, aby som sa predstavil, Alexander. Systémový administrátor jedného malého, ale hrdého WEB-štúdia. Naozaj chceme, aby všetko fungovalo rýchlo, bezpečne a s čerstvým softvérom. Aby sme to dosiahli, zvýšili sme dokonca balík nagios + PhantomJS na vnútropodnikovom počítači a každých 30 minút sme kontrolovali rýchlosť načítania stránky. V súlade s podmienkami služby tiež sledujeme aktualizácie 1C-Bitrix a pravidelne ich inštalujeme. A potom jedného dňa, po ďalšej aktualizácii, vidíme na admin paneli správu, že od leta 2019 prestáva 1C-Bitrix pracovať s MySQL 5.5 a je potrebné ho aktualizovať. Chalani z ISPSystem sú fešáci a pravidelne rozširujú funkcionalitu panelu, za čo im patrí veľká vďaka. Tentoraz sa ale nedalo všetko naklikať myšou. Ale čo sa stalo a koľko šedivých vlasov mám teraz v fúzoch, nájdete pod strihom.
Existovala iba možnosť nainštalovať „alternatívny server DBMS“, ktorý je nainštalovaný v kontajneri Docker. Samozrejme, chápem, že Docker je veľmi šetrný k zdrojom, ale bez ohľadu na to, ako skvele to funguje, réžia bude stále > 0. A tu sme akoby v desatinách sekúnd bojovali a optimalizovali všetky stránky na vstupe pred zverejnením a podpisom zmluvy. Takže nie moja voľba.
Dobre, čo je v dokumentácii? Zálohujte všetko, pridajte súbor s odkazom na úložisko MariaDB na yum.repos.d, potom
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum bude následne nadávať na skutočnosť, že niekto odstránil balíčky bez jeho vedomia. Ale po prvé - nech prisahá, je to v poriadku. A po druhé, ak vykonáte vymazanie cez yum, potom sa pokúsi zničiť spolu s MariaDB všetko, čo s tým súvisí pomocou závislostí, a to je PHP a ISPManager a PHPmyadmin. Takže s chybami sa budeme zaoberať neskôr.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonVo všeobecnosti bolo všetko nastavené a spustené. Sympatické je, že základy boli povyberané a nebolo potrebné ich obnovovať zo skládok. Skontroloval som stránky - fungujú a rýchlo. Išiel som na pár admin panelov, aby som sa uistil, že nič nespadlo a odhlásil som riaditeľovi, že je všetko OK. Za necelých 30 minút sa ukázalo, že to ani nie je v poriadku...
Keď som sa pokúsil prejsť na admin panel a pridať upraviť čokoľvek do obsahu, vypadla správa
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']Keďže obsah na stránke pridávajú naši zamestnanci, klienti stále nič nevedeli a ešte nás nezačali trhať. Bola to však otázka času, pretože informácie na stránkach treba aktualizovať a mnohí klienti to veľmi pozorne sledujú.
Z textu chyby môžeme usúdiť, že Bitrix sa pokúša pridať nový záznam do databázy, pričom zadáva rovnaký primárny kľúč, aký mal upravovaný článok. Existuje teda dôvod domnievať sa, že problém sa vyskytuje na strane Bitrixu. Prejdite na ich webovú stránku a kontaktujte podporu. Takmer okamžite dostaneme odpoveď „ťažký problém. Poskytnuté starším inžinierom - počkajte ... “
Musel som čakať pomerne dlho (celý dialóg prebiehal od 25.06.2019 do 9.07.2019) a výsledkom bola správa „tento problém nesúvisí s prevádzkou Bitrix CMS, ale súvisí na samotnú prevádzku databázy v mariadb 10.4.6 a žiaľ, keďže chýba strana stránky na vyriešenie tohto problému, bude potrebné prejsť na staršiu verziu MariaDB.“
Sailed ... Myslel som na downgrade na začiatku príbehu, ale že nemôže dôjsť k downgradu. Zlúčte výpisy a znova nasaďte na čerstvo nainštalovaný server. Tie. je dobré, že som neaktualizoval všetky servery naraz. Tie. „len“ sto miest (nervózny smiech :-)). Na podporu tiež povedali: „Ak chcete vyriešiť problém s používaním databázy MariaDB 10.4.6, budete musieť kontaktovať technickú podporu MariaDB, že transakcia nevymaže záznam z databázy, ak bude podaná žiadosť:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Nádej svitla na pár hodín od momentu, keď sme začali komunikovať s podporou MariaDB, no potom som dostal list, v ktorom som bol mimoriadne korektne informovaný, že nie som komerčný používateľ a teda nikto cielene môj problém nerieši, ale existuje fórum na ich stránke a môžete sa tam pokúsiť hľadať možnosti... Nebudem vás nudiť podrobnosťami. Nie sú tam žiadne možnosti.
O! Zakúpili sme licenciu pre ISP!
Ahoj, podpora? Chlapci, pomôžte!
- Ľutujeme, nepodporujeme násilníkov, ktorí menia pôvodné verzie DBMS. Ak chcete, existuje možnosť s alternatívnym serverom v docker.
- Ale ako sa tam dostanú používatelia a databázy? Do prístaviska?
- No, pretiahnite ich tam rukami ...
- Áno! A nezabudnite, že port pre mysql sa zmení a budete musieť prejsť a prepísať všetky konfigurácie.
Ok dakujem, porozmyslam nad tym...
Rozmýšľal som a rozhodol som sa zbúrať 10.4 s kľučkami a nainštalovať 10.2, s ktorým neboli žiadne problémy na iných serveroch.
Proces sa príliš nelíšil od procesu inovácie. Len bolo potrebné zmeniť 10.4 na 10.2 v odkaze na úložisko, resetovať a znova vytvoriť vyrovnávaciu pamäť pre yum. Ešte jedna „maličkosť“: po odstránení 10.4 prejdeme do /var/lib/mysql a odtiaľ všetko vymažeme. Bez tohto kroku po inštalácii 10.2 bude služba neustále padať a uvidíte
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"alebo
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Pred importovaním databáz som najprv nastavil heslo root mysql, ktoré bolo zadané v konfiguráciách poskytovateľa internetových služieb a importoval výpis databázy mysql. Potom, keď už existujú používatelia a práva, jednoducho importujeme všetky databázy používateľov v rade s účtom root.
Text skriptu pre výpis databázy:
#!/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'Pred importovaním databáz ich musíte rozbaliť. Stačí teda spustiť príkaz
gunzip /BACK/*.gzA posledná vec: z nejakého dôvodu sú v názvoch databáz povolené pomlčky (ak ich vytvoríte pomocou ISPmanager). Ale keď vytvárate alebo sa pokúšate nahrať výpis do databázy, ktorá má v názve spojovník, dostanete správu, že syntax dotazu je nesprávna.
Prečítajte si až do konca všetky požehnania. Ospravedlňujem sa za čiarky, ktoré pravdepodobne nie sú oddelené – majú problémy. Ak existujú želania pre návrh v podstate popísané - napíšte osobne, pretože sa bojím, aby mi niečo uniklo. A moc nenadávaj - toto je môj prvý článok 🙂
UPD1:
Takmer som zabudol spomenúť: keď som sa snažil nájsť riešenie problému bez zníženia verzie MariaDB, musel som nejako aktualizovať informácie. Aktualizovalo sa to takto: celá databáza sa skonvertuje z InnoDB na MyISAM, aktualizuje sa infa a potom sa skonvertuje späť na InooDB.
UPD2:
Práve som dostal list od 1C-Bitrix s nasledujúcim obsahom:
Žiadosť o revíziu bola dokončená
"Po aktualizácii mariadb na 10.4.6 sa vyskytla chyba pri ukladaní prvku infobloku"
Modul: iblock, verzia: neznáma
Riešenie: zamietnuté
Takže zatiaľ zrejme nie je možné aktualizovať na 10.4 🙁
Zdroj: hab.com