Доброго часу доби, шановні хабрівчани! Дозвольте представитися, Олександре. Системний адміністратор однієї маленької, але гордої 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 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']Оскільки контент на сайт додають наші співробітниці, клієнти ще нічого не знали і поки не почали рвати нас на частини. Але це було питання часу, бо інфу на сайтах треба оновлювати і ось за цим багато клієнтів стежать самі і уважно.
З тексту помилки можна дійти невтішного висновку у тому, що Битрикс намагається додати новий запис у основу у своїй вказавши той-таки primary key, що у редагованої статті. Значить, є підстави підозрювати, що проблема виникає на боці Бітрікс. Йдемо на їхній сайт і звертаємося на підтримку. Майже одразу отримуємо відповідь “складна проблема. Віддали старшим інженерам – чекайте…”
Чекати довелося досить довго (весь діалог відбувався в період з 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!
- Алло, підтримка? Хлопці, допоможіть!
— Вибачте, ми не підтримуємо відморозків, які нативні версії СУБД змінюють. Хочете — є варіант із альтернативним сервером у докері.
— Але як туди потраплять користувачі та бази? У докер?
— Ну, ви їх туди руками затягнете…
- Так! І не забудьте, що порт для 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:
Ледве не забув згадати: поки я намагався знайти вирішення проблеми без downgrade MariaDB, треба було якось інфу оновлювати. Оновлювалася так: вся база конвертується з InnoDB в MyISAM, оновлюється інформація і потім конвертується назад в InooDB.
UPD2:
Щойно надійшов лист від 1С-Бітрікс наступного змісту:
Заявка на доопрацювання реалізована
"Після оновлення mariadb до 10.4.6 помилка при збереженні елемента інфоблоку"
Модуль: iblock, версія: не відома
Рішення: відхилено
Так що поки до 10.4 оновлюватись мабуть не можна 🙁
Джерело: habr.com