Добър ден, скъпи хабровци! Позволете ми да се представя, Александър. Системен администратор на едно малко, но гордо WEB-студио. Наистина искаме всичко да работи бързо, безопасно и с нов софтуер. За да направим това, ние дори повдигнахме пакета nagios + PhantomJS на вътрешноофисния компютър и на всеки 30 минути проверяваме скоростта на зареждане на страницата. Съгласно условията на услугата, ние също следим актуализациите на 1C-Bitrix и ги инсталираме редовно. И тогава един ден, след следващата актуализация, виждаме съобщение в админ панела, че от лятото на 2019 г. 1C-Bitrix спира да работи с MySQL 5.5 и трябва да бъде актуализиран. Момчетата от ISPSystem са красавци и редовно разширяват функционалността на панела, за което им благодаря. Но този път не беше възможно да щракнете върху всичко с мишката. Но какво се случи и колко сиви косми има сега в брадата ми, можете да намерите под подстригването.
Имаше само опция за инсталиране на „алтернативен DBMS сървър“, който е инсталиран в контейнера на Docker. Разбира се, разбирам, че Docker е много пестелив с ресурси, но колкото и страхотно да работи, режийните разходи пак ще бъдат > 0. И тук ние, като че ли, се бием за десети от секундата и оптимизираме всички сайтове на входа преди публикуване и подписване на споразумение. Така че не е моят избор.
Добре, какво има в документацията? Архивирайте всичко, добавете файл с връзка към хранилището на MariaDB към yum.repos.d, след което
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 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']Тъй като съдържанието на сайта се добавя от нашите служители, клиентите все още не знаеха нищо и все още не бяха започнали да ни разкъсват. Но беше въпрос на време, защото информацията в сайтовете трябва да се актуализира и много клиенти следят това много внимателно.
От текста на грешката можем да заключим, че Bitrix се опитва да добави нов запис към базата данни, като същевременно посочва същия първичен ключ, който имаше редактираната статия. Така че има причина да се подозира, че проблемът възниква от страна на Bitrix. Отидете на техния уебсайт и се свържете с поддръжката. Почти веднага получаваме отговора „труден проблем. Дадох го на старши инженери - изчакайте ... "
Трябваше да чакам доста дълго време (целият диалог се проведе от 25.06.2019 г. до 9.07.2019 г.) и резултатът беше съобщението „този проблем не е свързан с работата на Bitrix 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.
- Но как потребителите и базите данни ще стигнат до там? До докер?
- Е, влачиш ги там с ръцете си ...
- Да! И не забравяйте, че портът за mysql ще се промени и ще трябва да преминете и пренапишете всички конфигурации.
Добре, благодаря, ще помисля...
Помислих и реших да разруша 10.4 с дръжки и да инсталирам 10.2, с който нямаше проблеми на други сървъри.
Процесът не беше много по-различен от процеса на надграждане. Само беше необходимо да промените 10.4 на 10.2 във връзката към хранилището, да нулирате и да създадете отново кеша за yum. Е, още една „дреболия“: след премахване на 10.4 отиваме в /var/lib/mysql и изтриваме всичко от там. Без тази стъпка, след инсталиране на 10.2, услугата постоянно ще се срива и ще видите
Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"Или
Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 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, информацията се актуализира и след това се преобразува обратно в InooDB.
UPD2:
Току-що получих писмо от 1C-Bitrix със следното съдържание:
Заявката за преразглеждане е завършена
„След актуализиране на mariadb до 10.4.6 възникна грешка при запазване на елемента на информационния блок“
Модул: iblock, версия: неизвестна
Решение: отхвърлено
Така че засега очевидно е невъзможно да се актуализира до 10.4 🙁
Източник: www.habr.com