Dobrý den, vážení Habráci! Dovolte mi se představit, jsem Alexander. Systémový administrátor jedné malé, ale pyšné WEBové agentury. Velmi si přejeme, aby všechno fungovalo rychle, bezpečně a s aktuálním softwarem. Z tohoto důvodu jsme na vnitřním počítači zprovoznili kombinaci nagios+PhantomJS a každých 30 minut kontrolujeme rychlost načítání stránek. V rámci našich služeb také sledujeme aktualizace 1C-Bitrix a pravidelně je instalujeme. A tak jsme jednoho dne po dalším aktualizaci uviděli oznámení v administraci, že od léta 2019 1C-Bitrix přestane fungovat s MySQL 5.5 a je potřeba provést aktualizaci. Kluci z ISPSystem jsou skvělí a pravidelně rozšiřují funkce panelu, za což jim patří velké díky. Ale tentokrát se mi nepodařilo všechno kliknout myší. O tom, co se povedlo a kolik šedivých vlasů teď mám v bradě, se lze dozvědět pod katem.
Byla jen možnost nastavit "alternativní databázový server", který se instaluje v Docker kontejneru. Samozřejmě rozumím, že Docker velmi šetří zdroje, ale ať funguje, jak chce, přesto bude nějaký overhead >0. A my jsme tady s časovými limitami a optimalizujeme všechny weby před jejich publikováním a podpisem smlouvy. Takže to není moje volba.
Dobře, co je napsáno v dokumentaci? Zálohujte všechno, přidejte do souboru yum.repos.d odkaz na repozitář MariaDB, dále
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum bude později hlásit, že někdo odinstaloval nebo nainstaloval balíčky bez jeho vědomí. Ale za prvé — ať si stěžuje, nic se neděje. A za druhé, pokud se odinstalovává přes yum, snaží se spolu s MariaDB odinstalovat i všechno, co je na něm závislé, a to zahrnuje PHP, ISPManager a PHPmyadmin. Takže s těmi problémy se poté vyrovnáme.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonCelkově se všechno nainstalovalo a spustilo. Příjemné je, že databáze se načetly a nemusely se obnovovat z dumpů. Zkontroloval jsem weby — fungují a rychle. Podíval jsem se do několika administrací, abych se ujistil, že se nic neporouchalo, a napsal jsem řediteli, že je všechno v pořádku. Neuplynulo ani 30 minut a už se ukázalo, že to vůbec není v pořádku…
Při pokusu o přístup do administrace a přidání nebo úpravu čehokoliv v obsahu se objevilo hlášení
Chyba dotazu MySQL: INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VALUE, VALUE_NUM) SELECT 10555, 2201, P.ID, '3607', 3607.0000 FROM b_iblock_property P WHERE ID = 184 [[1062] Duplicitní položka '10555' pro klíč 'PRIMARY']Jelikož obsah na web přidávají naše zaměstnankyně, klienti o ničem nevěděli a zatím nás nezačali trhat na kusy. Ale byla to otázka času, protože informace na webech je nutné aktualizovat a na to si mnozí klienti bedlivě dávají pozor.
Z textu chyby lze usoudit, že Bitrix se snaží přidat nový záznam do databáze, přičemž uvádí stejný primární klíč, jaký měl upravovaný článek. To naznačuje, že problém může být na straně Bitrix. Jdeme na jejich web a obracíme se na podporu. Téměř okamžitě dostáváme odpověď: „složitý problém. Předali jsme to starším inženýrům — čekejte…“
Čekání však trvalo docela dlouho (celý dialog probíhal od 25.06.2019 do 9.07.2019) a výsledkem bylo sdělení: „tento problém není spojen s fungováním CMS Bitrix, ale s fungováním samotné databáze v mariadb 10.4.6 a bohužel ze strany webu tuto problém vyřešit nelze, bude nutné přejít na starší verzi MariaDB.“
Dorazili jsme... O downgrade jsem přemýšlel už na začátku příběhu, ale , že žádný downgrade být nemůže. Zálohujte a rozbalte znovu na čistě nainstalovaném serveru. Tedy je dobré, že jsem neaktualizoval všechny servery najednou. Tedy „jen“ stovka webů (nervózní smích :-)). V podpoře také řekli: „Aby bylo možné problém vyřešit při použití databáze MariaDB 10.4.6, budete se muset obrátit na technickou podporu MariaDB, že v transakci nebude možné provést odstranění záznamu z DB, pokud se provede dotaz:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);” Naděje žila několik hodin od začátku komunikace s podporou MariaDB, ale pak přišel e-mail, ve kterém mi bylo velmi korektně sděleno, že nejsem komerční uživatel, a proto se nikdo nebude cíleně zabývat mojí problémem, ale existuje fórum na jejich webu a tam se můžete pokusit hledat řešení... Nechci unavovat detaily. Nepodařilo se tam nic najít.
Oh! My máme zakoupenou licenci na ISP!
— Haló, podpora? Kluci, pomozte nám!
— Omlouváme se, nepodporujeme zmrazování, které mění nativní verze DBMS. Pokud chcete, existuje možnost s alternativním serverem v Dockeru.
— Ale jak se tam dostanou uživatelé a databáze? Do Dockeru?
— No, vy je tam dostanete ručně...
— Ano! A nezapomeňte, že port pro MySQL se změní a budete muset projít všechny konfigurace a přepsat je.
— Dobře, děkuji, budu přemýšlet...
Přemýšlel jsem a rozhodl se, že ručně odstraním 10.4 a nainstaluji 10.2, s kterým nebyly žádné problémy na jiných serverech.
Proces se příliš nelišil od procesu aktualizace. Jen bylo třeba v odkazu na repozitář změnit 10.4 na 10.2, resetovat a znovu vytvořit cache pro yum. A ještě jedna "drobnost": po odstranění 10.4 jdeme do /var/lib/mysql a všechno odtud odstraníme. Bez tohoto kroku bude služba po instalaci 10.2 neustále padat a uvidíte
Nepodařilo se připojit k databázi '' Ztraceno spojení s MySQL serverem při 'čtení počátečního komunikačního paketu', systémová chyba: 104 "Connection reset by peer"Nebo
Ztraceno spojení s MySQL serverem při 'handshake: čtení počátečního komunikačního paketu', systémová chyba: 104Před importem databází jsem nejprve nastavil ten root heslo pro MySQL, které bylo uvedeno v konfiguracích ISP a importoval dump databáze MySQL. A pak, protože už existují uživatelé a práva, jednoduše s účtem root importujeme postupně všechny databáze uživatelů.
Text skriptu pro dump databází:
#!/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'Před importem databází je třeba je rozbalit. Takže jednoduše spustíme příkaz
gunzip /BACK/*.gzA nakonec: z nějakého důvodu jsou v názvu databází (pokud je vytváříte přes ISPmanager) povoleny pomlčky. Ale při vytváření nebo pokusu o nahrání dumpu do databáze, jejíž název obsahuje pomlčku, dostanete zprávu o tom, že syntaxe dotazu je nesprávná.
Kdo dočetl až sem, přeji vše nejlepší. Omlouvám se za pravděpodobně špatně rozestavené čárky — s nimi mám potíže. Pokud máte přání nebo návrhy k podstatě popsaného — napište mi soukromě, neboť v komentářích se obávám, že něco přehlédnu. A prosím, příliš neplačte — to je můj první článek 🙂
UPD1:
Málem jsem zapomněl zmínit: zatímco jsem se snažil najít řešení problému bez downgrade MariaDB, bylo třeba nějak aktualizovat info. Aktualizováno takto: celá databáze se konvertuje z InnoDB na MyISAM, aktualizují se informace a pak se konvertuje zpět do InnoDB.
UPD2:
Právě přišel e-mail od 1C-Bitrix s následujícím obsahem:
Žádost o úpravu byla realizována
„Po aktualizaci mariadb na 10.4.6 chyba při ukládání prvku infobanku“
Modul: iblock, verze: neznámá
Řešení: zamítnuto
Takže zatím to vypadá, že nelze aktualizovat na 10.4 🙁
Zdroj: habr.com
