Dobrý den, milí obyvatelé Chabrovska! Dovolte mi, abych se představil, Alexandre. Správce systému jednoho malého, ale hrdého WEB studia. Opravdu chceme, aby vše fungovalo rychle, bezpečně a s nejnovějším softwarem. Za tímto účelem jsme dokonce nainstalovali na vnitrokancelářský počítač balíček nagios+PhantomJS a každých 30 minut kontrolovali rychlost načítání stránky. Podle podmínek služby také sledujeme aktualizace 1C-Bitrix a pravidelně je instalujeme. A pak jednoho dne, po další aktualizaci, vidíme v admin panelu zprávu, že od léta 2019 přestává 1C-Bitrix fungovat s MySQL 5.5 a musíme aktualizovat. Kluci z ISPSystem jsou fešáci a pravidelně rozšiřují funkčnost panelu, za což jim patří velký dík. Tentokrát ale nebylo možné vše naklikat myší. Ale můžeš zjistit, co se stalo a kolik šedivých vlasů mám teď ve vousech pod ostříhaným.
Existovala pouze možnost nainstalovat „alternativní server DBMS“, který je nainstalován v kontejneru Docker. Samozřejmě chápu, že Docker je se zdroji velmi šetrný, ale bez ohledu na to, jak skvěle funguje, režie bude stále >0. A tady se zdá, že bojujeme v desetinách sekund a optimalizujeme všechny weby na vstupu, než je zveřejníme a podepíšeme dohodu. Takže to není moje volba.
Dobře, co říká dokumentace? Zálohujte vše, přidejte soubor na yum.repos.d s odkazem na úložiště MariaDB a poté
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum následně přísahá, že někdo smazal balíčky bez jeho vědomí. Ale nejdřív ho nech přísahat, je to v pořádku. A za druhé, pokud smazání provedete přes yum, pak se pokusí odstranit spolu s MariaDB vše, co je s ní spojeno závislostí, a to včetně PHP a ISPManager a PHPmyadmin. Proto se budeme nadávkami zabývat později.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonObecně bylo vše nainstalováno a spuštěno. Příjemné je, že databáze byly vyzvednuty a nebylo potřeba je obnovovat z výpisů. Zkontroloval jsem stránky - fungují a jsou rychlé. Šel jsem do několika administrátorských oblastí, abych se ujistil, že nic nespadlo, a napsal jsem řediteli, že je vše v pořádku. O necelých 30 minut později se ukázalo, že to vůbec není v pořádku...
Když jsem se pokusil přejít do oblasti pro správu a přidat a upravit cokoli v obsahu, objevila se zprá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']Vzhledem k tomu, že obsah na stránky přidávají vlastní zaměstnanci, klienti zatím nic nevěděli a ještě nás nezačali trhat. Byla to ale otázka času, protože informace na stránkách je potřeba aktualizovat a řada klientů to sama bedlivě sleduje.
Z textu chyby můžeme usoudit, že Bitrix se pokouší přidat nový záznam do databáze, přičemž zadává stejný primární klíč, jaký byl v upravovaném článku. To znamená, že existuje důvod se domnívat, že problém vzniká na straně Bitrixu. Jdeme na jejich web a kontaktujeme podporu. Téměř okamžitě dostáváme odpověď „složitý problém. Předal to starším inženýrům – počkej...“
Museli jsme čekat poměrně dlouho (celý dialog probíhal od 25.06.2019. června 9.07.2019 do 10.4.6. července XNUMX) a výsledkem byla zpráva „tento problém nesouvisí s provozem Bitrix CMS, ale souvisí s provoz samotné databáze v mariadb XNUMX a bohužel s Na straně webu neexistuje způsob, jak tento problém vyřešit, budete muset přejít na starou verzi MariaDB.“
Dorazili... Na začátku příběhu jsem přemýšlel o downgradu, ale že nemůže dojít k downgradu. Uložte výpisy a znovu nasaďte na kompletně nainstalovaný server. Tito. Je dobře, že jsem neaktualizoval všechny servery najednou. Tito. „jen“ sto stránek (nervózní smích :-)). Podpora také uvedla: „Chcete-li vyřešit problém s používáním databáze MariaDB 10.4.6, budete muset kontaktovat technickou podporu MariaDB, že transakce neodstraní záznam z databáze, pokud bude podán požadavek:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”
Naděje svitla na pár hodin od chvíle, kdy jsem začal komunikovat s podporou MariaDB, ale pak mi přišel dopis, ve kterém mi velmi správně sdělili, že nejsem komerční uživatel a tudíž můj problém nikdo cíleně nevyřeší, ale existuje fórum na jejich webu a tam můžete zkusit hledat možnosti ... nebudu vás nudit podrobnostmi. Nejsou tam žádné možnosti.
O! Koupili jsme ISP licenci!
- Ahoj, podporu? Kluci, pomozte!
— Litujeme, nepodporujeme šmejdy, kteří mění nativní verze DBMS. Pokud chcete, existuje možnost s alternativním serverem v Dockeru.
— Ale jak se tam uživatelé a databáze dostanou? Do dockeru?
- No, přetáhneš je tam rukama...
- 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íky, popřemýšlím o tom...
Přemýšlel jsem o tom a rozhodl jsem se ručně zbourat 10.4 a nainstalovat 10.2, se kterým na jiných serverech nebyly žádné problémy.
Proces se příliš nelišil od procesu aktualizace. Jen jsem musel změnit 10.4 na 10.2 v odkazu na úložiště, resetovat a znovu vytvořit mezipaměť pro yum. No, ještě jedna „maličkost“: po odebrání 10.4 přejděte do /var/lib/mysql a smažte vše odtud. Bez tohoto kroku po instalaci 10.2 bude služba neustále padat a uvidíte
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Nebo
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104Před importem databází jsem nejprve nastavil heslo uživatele root pro mysql, které bylo zadáno v konfiguraci ISP, a importoval výpis databáze mysql. Protože již máme uživatele a práva, jednoduše importujeme všechny databáze uživatelů v řadě pomocí účtu root.
Text skriptu pro výpis databáze:
#!/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 jen spustíme příkaz
gunzip /BACK/*.gzA na závěr: z nějakého důvodu jsou v názvu databáze povoleny pomlčky (pokud ji vytváříte přes ISPmanager). Ale když vytvoříte nebo se pokusíte odeslat výpis do databáze, která má v názvu pomlčku, zobrazí se zpráva, že syntaxe požadavku je nesprávná.
Vše nejlepší těm, kteří dočetli až do konce. Omlouvám se za pravděpodobně špatně umístěné čárky - jsou problém. Pokud máte nějaké návrhy týkající se podstaty toho, co je popsáno, napište do osobní zprávy, protože se obávám, že v komentářích něco přehlédnu. A moc nenadávejte - tohle je můj první článek :)
UPD1:
Málem bych zapomněl zmínit: když jsem se snažil najít řešení problému bez downgradu MariaDB, musel jsem nějak aktualizovat informace. Aktualizace proběhla takto: celá databáze je převedena z InnoDB na MyISAM, informace jsou aktualizovány a poté převedeny zpět na InooDB.
UPD2:
Právě jsem obdržel dopis od 1C-Bitrix s následujícím obsahem:
Žádost o revizi dokončena
"Po upgradu mariadb na 10.4.6 došlo k chybě při ukládání prvku infobloku"
Modul: iblock, verze: neznámá
Řešení: zamítnuto
Takže je zřejmě prozatím nemožné aktualizovat na 10.4 🙁
Zdroj: www.habr.com