Битрикс и обновление MariaDB до последней стабильной версии

Доброго времени суток, уважаемые Хабровчане! Разрешите представиться, Александр. Системный администратор одной маленькой но гордой 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-common

Yum впоследствии будет ругаться на то, что кто-то пакеты удалялставил без его ведома. Но во первых — пусть ругается, ничего страшного. А во вторых если делать удаление через 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