Добър ден, уважаеми Хабровчани! Позволете ми да се представя, Александър. Системен администратор на една малка, но горда WEB-студия. Много искаме всичко да работи бързо, сигурно и с актуален софтуер. Затова дори стартирахме на вътрешния компютър комбинация nagios+PhantomJS и на всеки 30 минути проверяваме скоростта на зареждане на страниците. Според правилата на обслужването, следим и за актуализациите на 1С-Битрикс и редовно ги инсталираме. И ето, веднъж след поредната актуализация виждаме съобщение в админ панела, че от лятото на 2019 1С-Битрикс спира да работи с MySQL 5.5 и е необходимо обновление. Ребята от ISPSystem са страхотни и редовно разширяват функционалността на панела, за което им благодаря. Но този път не успяхме да кликнем всичко с мишката. А за това, което успяхме и колко сиви коси сега има в брадата ми, може да се научи под кат.
Имаше само опция да се инсталира "алтернативен сървър на СУБД", който се инсталира в Docker контейнер. Разбира се, осъзнавам, че Docker е доста икономичен с ресурсите, но колкото и да работи добре, оверхед все пак ще има >0. А ние тук се борим за десетични части от секундата и оптимизираме всички сайтове преди да ги публикуваме и да подпишем договора. Така че това не е моят вариант.
Добре, какво пише в документацията? Backup на всичко, добавяне на файл в 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."
Приплуваме... Помислях за даунгрейд още в началото на историята, но , че никакъв даунгрейд не може да има. Изтеглете дамповете и разгръщайте отново на чисто инсталиран сървър. Тоест, добре е, че не обнових всичките сървъри наведнъж. Тоест "всичко" сто сайта (нервно смях:-)). Още в поддръжката казаха: "За решаване на проблема при използване на база 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, и импортирах дампа на базата. А след това, тъй като потребителите и правата вече съществуват, просто с акаунта 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
