Добър ден, уважаеми Хабровчани! Позволете ми да се представя, Александър. Системен администратор на една малка, но горда WEB-студия. Много искаме всичко да работи бързо, безопасно и с актуален софтуер. Заради това дори инсталирахме на вътрешния офис компютър комбинацията nagios+PhantomJS и на всеки 30 минути проверяваме скоростта на зареждане на страниците. Според условията на обслужване, също така следим за актуализации на 1С-Битрикс и периодично ги инсталираме. И ето, веднъж след поредната актуализация виждаме съобщение в админ панела, че от лятото на 2019 година 1С-Битрикс спира да работи с MySQL 5.5 и трябва да се обновим. Момчетата от ISPSystem са страхотни и редовно разширяват функционалността на панела, за което им благодаря. Но този път не успяхме да натиснем всичко с мишката. А какво се получи и колко бели косми сега в брадата ми можете да научите по-долу.
Имаше само вариант да се инсталира "алтернативен сървър на СУБД", който се инсталира в Docker-контейнер. Разбира се, осъзнавам, че Docker е много икономичен с ресурсите, но каквото и да е, все пак ще има overhead >0. А ние тук сме на времеви интервали от стотни на секундата и оптимизираме всички сайтове на входа преди да ги публикуваме и подпишем договор. Така че това не е моят вариант.
Ок, какво пише в документацията? Резервно копие на всичко, добавяне на файл в yum.repos.d с линк към репозитория MariaDB, след това
rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-commonYum впоследствие ще се оплаче, че някой е изтривал/инсталирал пакети без негово знание. Но на първо място — нека се оплаква, няма нищо страшно. А на второ, ако премахнете през yum, той опитва да изтрие и всичко, свързано със зависимости с MariaDB, а това е и PHP и ISPManager и PHPmyadmin. Затова след това ще разгледаме оплакванията.
yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-commonВ общи линии всичко беше инсталирано и заработи. Приятно е, че базите данни се активираха и не трябваше да ги възстановявам от дампове. Проверих сайтовете — работят и бързо. Влязох в няколко админ панела, за да се уверя, че нищо не е отпаднало, и информирах директора, че всичко е ОК. Не минаха и 30 минути, когато стана ясно, че всъщност не е ОК...
При опит да вляза в админ панела и да добавя/редактирам каквото и да било в съдържанието, се появяваше съобщение
Грешка в MySQL запит: 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] Дублирано записване '10555' за ключ 'PRIMARY']Тъй като съдържанието на сайта се добавя от нашите служители, клиентите все още не знаеха нищо и не започнаха да ни разкъсват. Но това беше въпрос на време, тъй като информацията на сайтовете трябва да се актуализира и много клиенти сами следят внимателно за това.
От текста на грешката можем да заключим, че Битрикс се опитва да добави нова запис в базата, указвайки същия основен ключ, който е имала редактираната статия. Значи има основания да подозираме, че проблемът възниква от страна на Битрикс. Отиваме на сайта им и се обръщаме за помощ. Почти веднага получаваме отговор „сложен проблем. Предаден на старши инженери — чакайте…“
Чакаше се доста дълго (целият диалог се водеше в периода от 25.06.2019 до 9.07.2019 г.) и резултатът беше съобщение „този проблем не е свързан с работата на CMS Битрикс, а е свързан с работата на самата база данни в mariadb 10.4.6 и, за съжаление, от страна на сайта няма възможност да се реши този проблем, необходимо е да се премине на по-стара версия на MariaDB.“
Припливахме… Помислих за downgrade още в началото на историята, но , че никакъв downgrade не може да бъде. Сливайте дампове и разгръщайте отново на чисто инсталирано сървър. Тоест, хубаво е, че не съм обновил всичките сървъри наведнъж. Тоест, „всичко“ — стотина сайта (нервна смях:-)). Още в поддръжката казаха: „За да решите проблема при използване на база MariaDB 10.4.6, е необходимо да се свържете с техническата поддръжка на MariaDB, тъй като в транзакцията не могат да се изтриват записи от БД, ако се извършва запитване:
$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);” Надеждата гореше няколко часа от момента на започване на общуването с поддръжката на MariaDB, но след това дойде писмо, в което много коректно ми съобщиха, че не съм търговски потребител и затова никой няма да решава конкретно проблема ми, но има форум на сайта им и там може да се опита да се потърсят варианти… Няма да ви уморявам с подробности. Няма варианти там.
О! Имаме купена лицензия за ISP!
— Алло, поддръжка? Ребята, помогнете!
— Извинявайте, ние не поддържаме отморозъци, които сменят оригиналните версии на СУБД. Искате ли — има опция с алтернативен сървър в Docker.
— Но как ще достигнат потребителите и базите? В Docker?
— Ами вие ще ги пренесете ръчно…
— Да! И не забравяйте, че портът за mysql ще се промени и ще трябва да прегледате всички конфигурации и да ги препишете.
— Ок, благодаря, ще помисля…
Помислих и реших наистина да изтрия 10.4 и да инсталирам 10.2, с което не съм имал проблеми на другите сървъри.
Процесът не се различаваше много от обновяването. Просто трябваше да смените 10.4 с 10.2 в линка на репозитория, да нулирате и да създадете кеша за yum отново. И още една 'малка подробност': след изтриването на 10.4 отивате в /var/lib/mysql и изтривате всичко оттам. Без тази стъпка след инсталирането на 10.2, услугата постоянно ще пада и ще виждате
Не можа да се свърже с базата данни '' Загубена връзка с MySQL сървъра при 'четене на началния комуникационен пакет', системна грешка: 104 "Връзката е нулирана от страна на партньора"Или
Загубена връзка с MySQL сървъра при 'ръкуване: четене на началния комуникационен пакет', системна грешка: 104Преди да импортирам базите, първо установих паролата root за mysql, която беше записана в конфигурацията на ISP и импортирах дампа на mysql базата. А след това, тъй като потребителите и правата вече съществуват, просто с акаунта root импортирам последователно всичките потребителски бази.
Текст на скрипта за дамп на базите:
#!/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'Преди импорта на базите, трябва да ги разархивирате. Затова просто изпълнете командата
gunzip /BACK/*.gzИ накрая: по някаква причина в имената на базите (ако ги създавате чрез ISPmanager) са допустими тирета. Но при създаването или опита за зареждане на дамп в база, която има тире в името, получавате съобщение, че синтаксисът на заявката е неправилен.
На тези, които прочетоха до края, всичко най-добро. Извинявам се за вероятно неправилно поставените запетаи — с тях е затруднение. Ако имате предложения по съществото на описаното — пишете ми на лични, защото в коментарите се страхувам да не пропусна нещо. И не бъдете прекалено строги — това е моята първа статия 🙂
UPD1:
Че почти забравих да спомена: докато опитвах да намеря решение на проблема без понижение на MariaDB, трябваше да обновявам информацията. Обновяваше се така: цялата база се конвертира от InnoDB в MyISAM, обновява се информацията и после се конвертира отново в InnoDB.
UPD2:
Току-що получих имейл от 1С-Битрикс с следното съдържание:
Заявката за доработка е реализирана
«След обновлението на mariadb до 10.4.6 грешка при запазването на елемент от инфоблока»
Модул: iblock, версия: неизвестна
Решение: отказано
Така че за момента не е възможно актуализирането до 10.4 🙁
Източник: habr.com
