Битрикс и обновление 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 обновляться видимо нельзя :-(
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 27

      0
      Так а в чём проблема-то была? Не удаляется почему?
        0
        Меня немного смущает, что внутри транзакции удалённая запись видна. Раньше были флаги совместимости, насколько я помню. Ну и… 10.4.6 — это первый релиз марии ветки 10.4. У меня был недавно плановый апгрейд, но в продакшн я его пока не рискнул.
        А в статье история борьбы, а не победы…
        P.S. А вообще — я подумал — похоже на неверный уровень изоляции транзакций, или что-то подобное.
          0
          Причину найти не удалось ни мне, ни сотрудникам 1С-Битрикс. Просто оказалось, что с MariaDB версий с 10.0 по 10.3 все хорошо, а вышедшая пару недель назад 10.4 содержит какие-то изменения из-за которых начинаются проблемы.
            0
            Ну, тогда это может быть баг где угодно. Хоть в MariaDB хоть в Битриксе. И без баг-репорта его никогда не починят. А у MariaDB-10.2 последний релиз через два года, потом всё.
              0
              Ну когда в битриксе включен режим отладки при выводе ошибки так-же появляется кнопка «отправить запрос в поддержку» и в этом автоматически формируемом запросе как раз и содержится полный баг-репорт со всеми подробностями и о хостинге и о конкретном сайте на котором ошибка произошла. Но ответ разработчиков тем не менее весьма однозначен: «Чинить не будем».
                0
                Ответ разработчиков Битрикса? Ну, у них выбор небольшой, через несколько лет они перестанут поддерживать MariaDB 10.3 и или починят, или уйдут с MariaDB совсем.

                А в MariaDB полный баг репорт не отсылали?
                  0
                  Ответ разработчиков Битрикса?

                  Да.
                  А в MariaDB полный баг репорт не отсылали?

                  Полный — не отсылал. Отправить только текст того запроса который мне из битрикс прислали в тикет. Но они свою позицию обозначили вполне конкретно и полный отчет бы тут ничем не помог.
                    0
                    jira.mariadb.org, не?
                      0
                      Может и стоило. Но тут как-бы не до поиска баг-трэкеров. Тут надо срочно какое-то решение. Я больше всего надеялся на битрикс. Ну а когда понял, что от них решения не будет — на всякий случай решил обратиться к разработчикам MariaDB — просто взял мыло из контактов и написал. Если бы там проблема кого-то волновала, я думаю направили бы по нужному пути. А тут сразу сказали, что либо в сообщество с вопросами либо как нибудь сам :-)
                        0
                        Ну, MariaDB Server — опенсорсный проект. Есть community, баг трекер, mailing list, irc и zulip. Есть кого спросить и где.

                        А обращаться в коммерческую фирму, которая за деньги оказывает услуги поддержки, и просить, чтоб помогли бесплатно — результат будет предсказуем.
          0
          Непонятно зачем вы гзипнули базы при дампе если спустя мнгновение вы решили их обратно разархивировать.
            0
            Все просто. Гзипнул потому, что обычно перед обновлением делаю внеплановый бэкап, обновляюсь и если в течение недели ничего не надо отказывать — удаляю то, что руками гзипнул. Так вот чтобы место не занимать тем, что через неделю должно быть удалено как раз и сжал. Но судьба в лице разработчиков MariaDB и 1С-Битрикс не сговариваясь (я надеюсь :-)) распорядилась иначе и пришлось таки разархивировать. И не через мгновенье, а через 2 недели.
              +1
              Вообще тут стоило сперва развернуть еще один тестовый сервер и там обкатать на паре-тройке сайтов обновление версии БД. Чтобы избежать вот таких факапов.
                0
                Согласен и обычно так раньше и делали. Но тут студия совсем маленькая и держать для тестов дополнительный сервер — не вариант. Помимо сервера же еще надо ставить ISP, а это лицензия. Так что бэкапы, бэкапы и еще раз бэкапы :-)
                  0
                  В ISPmanager если мне не изменяет память есть триал) А для тестов можно поднять виртуалку и прибить через пару часов использования.
                    0
                    Думал об этом. Только вот свежая виртуалка+триал != сервер с лицензией отработавший уже не 1 год. Там уже и некоторые пакеты были заменены на собранные из исходников и что-то обновлялось, а что-то осталось в неизменном виде. Так что эксперимент не чистый получится и есть вероятность получить стабильную виртуалку с триалом и тотально неработающий прод.
                      0
                      Учитывая наличие докера в сюжете, пора остальное тоже перетаскивать в контейнеры и автоматизировать по полной.

                      Невозможность поднять быстро сервер с нужной конфигурацией тоже чревата седыми волосами в бороде, особенно если отличия были достаточно серьезными, с установкой самостоятельно компилируемых пакетов, которые при этом еще нормально не отражены в инструкции.

                      Как Вам ситуация — отпуск на Канарах и случайно (тотально) упавший сервер, а полный бэкап сервера отказывается развернуться, но при этом есть бэкапы сайтов клиентов? Моё предсказание — к длинным матам в монитор планшета, цепляясь по гостиничному вайфаю, пытаясь понять чего ж еще не хватает сайту.
                        0
                        В сюжете от докера как раз и отказался в виду его ненужности в данной ситуации. Да и странно это — собираться на Канары и перед отъездом не забэкапиться\обновить что нибудь.
                        А вообще был у меня как-то случай когда почтовый сервер после отключения (сбой по питанию в ДЦ) не поднялся. Там Zimbra была. Проблема оказалась в том, что я тогда по неопытности перед установкой зимбры не снес дефолтный exim. После ребута сначала поднимался не настроенный дефолтный, а потом зимбровский не мог подняться т.к. порт занят. Долго искал проблему как Вы написали с «длинными матами в монитор планшета» ибо работал тогда на удаленке и куда-то от компа свалил…
                    0
                    Поставьте на своём локальном компьютере виртуалку и на ней издевайтесь над своими сайтами ) Выкатывать такие вещи сразу в прод смерти подобно
              +2

              Я почитал историю изменений, но в чем проблема, не понял. Единственное заметное, что сделали в MariaDB и MySQL в последнее время — включили по умолчанию "строгий режим". Ранее СУБД по умолчанию использовали "нестрогий" режим, который прощал многие ошибки. Например, если вы пытались вставить в строчную колонку слишком длинное значение, СУБД просто обрезала его и давала предупреждение (которое в случае PHP обычно никак не видно на стороне PHP и никак не логгируется). Теперь же в "строгом" режиме, СУБД отказывается выполнять такие некорректные запросы.


              https://mariadb.com/kb/en/library/sql-mode/


              Обратите внимание, что там есть изменеия в 10.2.4:


              From version Default sql_mode setting
              MariaDB 10.2.4 STRICT_TRANS_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

              Strict mode. Statements with invalid or missing data are aborted and rolled back, except that for non-transactional storage engines and statements affecting multiple rows where the invalid or missing data is not the first row, MariaDB will convert the invalid value to the closest valid value, or, if a value is missing, insert the column default value. Default since MariaDB 10.2.4.

              Впрочем, это можно переключить в настройках. Не в этом ли было дело?


              Ну и конечно, поражает качество разработки в Битриксе. Как вам этот гениальный запрос?


              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

              Подзапрос SELECT тут делается только для того, чтобы извлечь P.ID, который явно указан и равен 184. Или это:


              $DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
              $results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”

              Эти гении отечественного программирования из Битрикса про плейсхолдеры или подготовленные запросы не слышали? При их подходе легко допустить инъекцию. Ну и в поддержку MariaDB надо слать итоговые запросы, а не этот кусок PHP-кода.


              Ну и плохо конечно, что вы не смогли разобраться, в чем была причина проблемы.

                0
                MariaDB 10.2.4 STRICT_TRANS_TABLES, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION

                Сразу после обновления зашел в админку одного из сайтов и сделал проверку. Удивился, что ругается на sql_mode который «должен быть пустым» по мнению 1С-Битрикс. Сразу же в my.conf поправил. Но дело явно было не в этом.
                надо слать итоговые запросы, а не этот кусок PHP-кода

                Отправил им в описании и запрос который не выполнился и то, что из поддержки Битрикс пришло. Но молодого человека из MariaDB это не возбудило.
                Выше писали, что есть мэйл-листы и прочие способы связи с сообществом. Это я прекрасно знаю. Но уважаемые комментаторы упускают в рекомендациях одну деталь: Время. У меня более 100 сайтов по которым приходят данные для обновления и обновляться приходится через конвертацию в MyISAM и обратно в InnoDB. Меня в той ситуации могло спасти либо получение быстрого ответа типа «Дятел! Вон там строка в конфиге кривая — поменяй и все будет» или откат на предыдущую версию. Совета от авторов я не получил, а чтобы у сообщества была возможность подискутировать и через неопределенное время прийти к решению и возможно (если нужно) что-то поправить в коде я как раз и написал статью. Ну и конечно чтобы на мои грабли с обновлением не наступали ибо хостингов много, а серверов в организациях с битриксовыми сайтами еще больше и в преддверии прекращения поддержки битриксом MySQL 5.5 наступать будут многие…
                  0

                  В данном случае вы должны были сами выяснить причину проблемы. И только убедившись, что проблема в MariaDB, написав инструкции по воспроизведению бага на чистой базе, можно обращаться в общественную поддержку (в стиле: возьмите чистую базу, выполните запросы A, B, C и получите результат D, хотя по документации (ссылка) должно быть E). А если вы им дали невнятное описание в стиле "я установил такую-то систему от битрикс и что-то она не работает", то, увы, у них тоже времени нет разбираться в вашей проблеме за вас.


                  Я не могу утверждать, что баг именно в битриксе, но вероятность этого высока. Так как такой баг, как не-удаление данных командой DELETE все же был бы заметен большому числу пользователей.

                    0
                    у них тоже времени нет разбираться в вашей проблеме за вас

                    Понимаю и у меня нет никаких претензий к MariaDB, да и быть не может. Ребята — молодцы. Делают крутой продукт и предоставляют его всему миру. Просто у меня было 3 пути:
                    1. Собирать инфу, пытаться разобраться (время), отправлять данные в сообщество и неопределенно долго ждать ответа (еще время)
                    2. Молча откатиться и никого не напрягать (относительно быстро, но геморройно)
                    3. Попробовать собрать что есть под рукой и если сходу никто ничего не подскажет — откатиться. Ну и в любом случае кто-то возможно обратит внимание на проблему и когда придет время — ей займутся и поправят.

                    Что касается «убедиться, что проблема в MariaDB» — тут лично для меня сложно. Не очень понимаю в разработке, поэтому доверился поддержке битрикс которая сказала, что проблема не на их стороне и они ее решать не будут. Так-то им и логи предоставили и доступ на сервер и в админки проблемных сайтов и детальное описание последовательности действий до и во время возникновения проблемы. И судя по их ответам, они все-же воспроизводили ошибку. И как мне кажется, могли бы учитывая сколько лицензий через нашу студию приобретено и преобретается, проявить немного больше внимания к технической проблеме. А так получается «купили лицензию? Молодцы! А теперь угадайте, на какой версии MariaDB купленный продукт заведется и будет стабильно работать».
                      0
                      Теперь-то время есть? Можно предоставить MariaDB всю информацию по проблеме, и тогда будет шанс, что «ей займутся и поправят». А так она через три года опять вылезет, когда 10.4 будет самая старая из живых версий MariaDB и придётся всё-таки на неё переходить.
                0

                А почему вы используете MariaDB вместо, например, Percona 8 ?

                  0
                  А чем Percona лучше MariaDB?
                  0
                  petropavel: Да, теперь время есть. Думал о том, чтобы собрать на виртуалке стенд с теми-же версиями пакетов и скопировать туда какой-то из сайтов для проверки. Может быть вообще удастся самому как-то решить проблему в спокойной обстановке. Но пока не решился. Все-таки не на 10 минут задачка…
                  knutov Потому, что когда на чистый сервер ставишь ISPManager с ним в комплекте ставится именно MariaDB 5.x. Ну и пару лет назад я уже обновлялся при похожих обстоятельствах на 10.0 — тогда все прошло идеально гладко и никто даже испугаться не успел :-) Ну и как по мне — найти что почитать по MariaDB проще чем по всему остальному. Более распространенный вариант.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое