Comments 27
Так а в чём проблема-то была? Не удаляется почему?
Меня немного смущает, что внутри транзакции удалённая запись видна. Раньше были флаги совместимости, насколько я помню. Ну и… 10.4.6 — это первый релиз марии ветки 10.4. У меня был недавно плановый апгрейд, но в продакшн я его пока не рискнул.
А в статье история борьбы, а не победы…
P.S. А вообще — я подумал — похоже на неверный уровень изоляции транзакций, или что-то подобное.
А в статье история борьбы, а не победы…
P.S. А вообще — я подумал — похоже на неверный уровень изоляции транзакций, или что-то подобное.
Причину найти не удалось ни мне, ни сотрудникам 1С-Битрикс. Просто оказалось, что с MariaDB версий с 10.0 по 10.3 все хорошо, а вышедшая пару недель назад 10.4 содержит какие-то изменения из-за которых начинаются проблемы.
Ну, тогда это может быть баг где угодно. Хоть в MariaDB хоть в Битриксе. И без баг-репорта его никогда не починят. А у MariaDB-10.2 последний релиз через два года, потом всё.
Ну когда в битриксе включен режим отладки при выводе ошибки так-же появляется кнопка «отправить запрос в поддержку» и в этом автоматически формируемом запросе как раз и содержится полный баг-репорт со всеми подробностями и о хостинге и о конкретном сайте на котором ошибка произошла. Но ответ разработчиков тем не менее весьма однозначен: «Чинить не будем».
Ответ разработчиков Битрикса? Ну, у них выбор небольшой, через несколько лет они перестанут поддерживать MariaDB 10.3 и или починят, или уйдут с MariaDB совсем.
А в MariaDB полный баг репорт не отсылали?
А в MariaDB полный баг репорт не отсылали?
Ответ разработчиков Битрикса?
Да.
А в MariaDB полный баг репорт не отсылали?
Полный — не отсылал. Отправить только текст того запроса который мне из битрикс прислали в тикет. Но они свою позицию обозначили вполне конкретно и полный отчет бы тут ничем не помог.
jira.mariadb.org, не?
Может и стоило. Но тут как-бы не до поиска баг-трэкеров. Тут надо срочно какое-то решение. Я больше всего надеялся на битрикс. Ну а когда понял, что от них решения не будет — на всякий случай решил обратиться к разработчикам MariaDB — просто взял мыло из контактов и написал. Если бы там проблема кого-то волновала, я думаю направили бы по нужному пути. А тут сразу сказали, что либо в сообщество с вопросами либо как нибудь сам :-)
Непонятно зачем вы гзипнули базы при дампе если спустя мнгновение вы решили их обратно разархивировать.
Все просто. Гзипнул потому, что обычно перед обновлением делаю внеплановый бэкап, обновляюсь и если в течение недели ничего не надо отказывать — удаляю то, что руками гзипнул. Так вот чтобы место не занимать тем, что через неделю должно быть удалено как раз и сжал. Но судьба в лице разработчиков MariaDB и 1С-Битрикс не сговариваясь (я надеюсь :-)) распорядилась иначе и пришлось таки разархивировать. И не через мгновенье, а через 2 недели.
Вообще тут стоило сперва развернуть еще один тестовый сервер и там обкатать на паре-тройке сайтов обновление версии БД. Чтобы избежать вот таких факапов.
Согласен и обычно так раньше и делали. Но тут студия совсем маленькая и держать для тестов дополнительный сервер — не вариант. Помимо сервера же еще надо ставить ISP, а это лицензия. Так что бэкапы, бэкапы и еще раз бэкапы :-)
В ISPmanager если мне не изменяет память есть триал) А для тестов можно поднять виртуалку и прибить через пару часов использования.
Думал об этом. Только вот свежая виртуалка+триал != сервер с лицензией отработавший уже не 1 год. Там уже и некоторые пакеты были заменены на собранные из исходников и что-то обновлялось, а что-то осталось в неизменном виде. Так что эксперимент не чистый получится и есть вероятность получить стабильную виртуалку с триалом и тотально неработающий прод.
Учитывая наличие докера в сюжете, пора остальное тоже перетаскивать в контейнеры и автоматизировать по полной.
Невозможность поднять быстро сервер с нужной конфигурацией тоже чревата седыми волосами в бороде, особенно если отличия были достаточно серьезными, с установкой самостоятельно компилируемых пакетов, которые при этом еще нормально не отражены в инструкции.
Как Вам ситуация — отпуск на Канарах и случайно (тотально) упавший сервер, а полный бэкап сервера отказывается развернуться, но при этом есть бэкапы сайтов клиентов? Моё предсказание — к длинным матам в монитор планшета, цепляясь по гостиничному вайфаю, пытаясь понять чего ж еще не хватает сайту.
Невозможность поднять быстро сервер с нужной конфигурацией тоже чревата седыми волосами в бороде, особенно если отличия были достаточно серьезными, с установкой самостоятельно компилируемых пакетов, которые при этом еще нормально не отражены в инструкции.
Как Вам ситуация — отпуск на Канарах и случайно (тотально) упавший сервер, а полный бэкап сервера отказывается развернуться, но при этом есть бэкапы сайтов клиентов? Моё предсказание — к длинным матам в монитор планшета, цепляясь по гостиничному вайфаю, пытаясь понять чего ж еще не хватает сайту.
В сюжете от докера как раз и отказался в виду его ненужности в данной ситуации. Да и странно это — собираться на Канары и перед отъездом не забэкапиться\обновить что нибудь.
А вообще был у меня как-то случай когда почтовый сервер после отключения (сбой по питанию в ДЦ) не поднялся. Там Zimbra была. Проблема оказалась в том, что я тогда по неопытности перед установкой зимбры не снес дефолтный exim. После ребута сначала поднимался не настроенный дефолтный, а потом зимбровский не мог подняться т.к. порт занят. Долго искал проблему как Вы написали с «длинными матами в монитор планшета» ибо работал тогда на удаленке и куда-то от компа свалил…
А вообще был у меня как-то случай когда почтовый сервер после отключения (сбой по питанию в ДЦ) не поднялся. Там Zimbra была. Проблема оказалась в том, что я тогда по неопытности перед установкой зимбры не снес дефолтный exim. После ребута сначала поднимался не настроенный дефолтный, а потом зимбровский не мог подняться т.к. порт занят. Долго искал проблему как Вы написали с «длинными матами в монитор планшета» ибо работал тогда на удаленке и куда-то от компа свалил…
Поставьте на своём локальном компьютере виртуалку и на ней издевайтесь над своими сайтами ) Выкатывать такие вещи сразу в прод смерти подобно
Я почитал историю изменений, но в чем проблема, не понял. Единственное заметное, что сделали в 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-кода.
Ну и плохо конечно, что вы не смогли разобраться, в чем была причина проблемы.
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 наступать будут многие…
В данном случае вы должны были сами выяснить причину проблемы. И только убедившись, что проблема в MariaDB, написав инструкции по воспроизведению бага на чистой базе, можно обращаться в общественную поддержку (в стиле: возьмите чистую базу, выполните запросы A, B, C и получите результат D, хотя по документации (ссылка) должно быть E). А если вы им дали невнятное описание в стиле "я установил такую-то систему от битрикс и что-то она не работает", то, увы, у них тоже времени нет разбираться в вашей проблеме за вас.
Я не могу утверждать, что баг именно в битриксе, но вероятность этого высока. Так как такой баг, как не-удаление данных командой DELETE все же был бы заметен большому числу пользователей.
у них тоже времени нет разбираться в вашей проблеме за вас
Понимаю и у меня нет никаких претензий к MariaDB, да и быть не может. Ребята — молодцы. Делают крутой продукт и предоставляют его всему миру. Просто у меня было 3 пути:
- Собирать инфу, пытаться разобраться (время), отправлять данные в сообщество и неопределенно долго ждать ответа (еще время)
- Молча откатиться и никого не напрягать (относительно быстро, но геморройно)
- Попробовать собрать что есть под рукой и если сходу никто ничего не подскажет — откатиться. Ну и в любом случае кто-то возможно обратит внимание на проблему и когда придет время — ей займутся и поправят.
Что касается «убедиться, что проблема в MariaDB» — тут лично для меня сложно. Не очень понимаю в разработке, поэтому доверился поддержке битрикс которая сказала, что проблема не на их стороне и они ее решать не будут. Так-то им и логи предоставили и доступ на сервер и в админки проблемных сайтов и детальное описание последовательности действий до и во время возникновения проблемы. И судя по их ответам, они все-же воспроизводили ошибку. И как мне кажется, могли бы учитывая сколько лицензий через нашу студию приобретено и преобретается, проявить немного больше внимания к технической проблеме. А так получается «купили лицензию? Молодцы! А теперь угадайте, на какой версии MariaDB купленный продукт заведется и будет стабильно работать».
А почему вы используете MariaDB вместо, например, Percona 8 ?
petropavel: Да, теперь время есть. Думал о том, чтобы собрать на виртуалке стенд с теми-же версиями пакетов и скопировать туда какой-то из сайтов для проверки. Может быть вообще удастся самому как-то решить проблему в спокойной обстановке. Но пока не решился. Все-таки не на 10 минут задачка…
knutov Потому, что когда на чистый сервер ставишь ISPManager с ним в комплекте ставится именно MariaDB 5.x. Ну и пару лет назад я уже обновлялся при похожих обстоятельствах на 10.0 — тогда все прошло идеально гладко и никто даже испугаться не успел :-) Ну и как по мне — найти что почитать по MariaDB проще чем по всему остальному. Более распространенный вариант.
knutov Потому, что когда на чистый сервер ставишь ISPManager с ним в комплекте ставится именно MariaDB 5.x. Ну и пару лет назад я уже обновлялся при похожих обстоятельствах на 10.0 — тогда все прошло идеально гладко и никто даже испугаться не успел :-) Ну и как по мне — найти что почитать по MariaDB проще чем по всему остальному. Более распространенный вариант.
Sign up to leave a comment.
Битрикс и обновление MariaDB до последней стабильной версии