Коллеги, виртуальные машины VMBitrix 7.4.2 и VMBitrix.CRM 7.4.2 вышли в релиз. В этой версии основные изменения - исправление выдачи ssl сертификатов от LetsEncrypt, переход на версию API v2.
rpm пакеты доступны для CentOS 6 (поддержка продолжается, только для VMBitrix) и CentOS 7. Если у Вас версии машины 7.4.1 и ниже - обновитесь.
Релиз минорный, изменения небольшие, поэтому sh-скрипты и образы не менялись.
Основные исправления: Изменен сервер выдачи сертификатов для LetsEncrypt, переход на версию API v2. API v1 будет окончательно отключено LetsEncrypt-ом 31 октября 2019.
После последнего обновления "Корпоративный портал" main (19.0.400) в "Тестирование конфигурации" появилась ошибка "Ошибка! innodb_strict_mode=ON, требуется OFF" при проверке "Режим работы MySQL" переход на VMBitrix 7.4.2 не помогает.
$connection->queryExecute("SET sql_mode=''"); $DB->Query("SET sql_mode=''"); Не помогают.
Но не могли бы вы ответить на вопрос, а то пока так и не сказали, зачем эта проверка теперь нужна, ведь если этот параметр в OFF, то уменьшается надёжность. Он ведь давно был в ON (с версии MYSQL >= 5.7.7) и вроде всё работало.
То есть, до этого момента работало не корректно или как? Или это требование исключительно нового модуля? В таком случае, что работало не корректно? Ведь этот параметр как раз и позволяет делать только однозначные запросы, а неоднозначные сразу выявлять как ошибочные. А теперь, неоднозначные запросы будут обрабатываться MYSQL по своему усмотрению, возможно, неправильно. Ну и пусть? Зато это не мешает работе новой версии модуля?
Внесу свои 5 копеек. Ставлю, как обычно, битриксВМ на виртуалбокс (для теста, разработок), путем скачивания образа со страницы загрузок. Версия 7.4.0. При попытке обновления любым способом до 7.4.1 вешается, как писали выше. Выбор варианта виртуализации в виртуалбоксе ничего не меняет (раньше вообще не знал про эту настройку). Так что после перебора всех вариантов забил на обновление. Начинаю работать с 7.4.0. Где-то после 10-20 минут работы хост тупо умирает. Причем в ТОР нет ни апача, ни энджи, ни мускуля. Апач и нджи перезапускаются нормально, а БД вешается намертво. Приходится перезапускать хост. В проверке системы "Ошибка! innodb_strict_mode=ON, требуется OFF". В еррор логах апача [mpm_prefork:error] [pid 2762] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting В еррор логах нджи ничего серьезного. В еррор логах мускуля тоже вроде нет ошибок критических.
Надо добавить, что на локалке стояла сборка с боевого сервака версии 7.3.4, обновление на нее не встало, повисло так же. При попытке остановить процесс и перезапустить процесс дальше была потеряна связь с БД. Пришлось сносить все и экспериментировать с чистого листа...
Что я делаю не так? Почему все умирает празднично после 20 минут работы?
З.Ы.: хорошо что решил потестить обнову на локалке...
З.Ы.Ы.: Увеличение MaxRequestWorkers добавляет времени работы, но в конечном итоге все равно крашится. При этом сама виртуальная машина работает, не работает хост "Firefox не может установить соединение с сервером 192.168.45.182."
Если установлено значение innodb_strict_mode=ON, MySQL делает дополнительные проверки запросов, что в ряде случаев приводит к проблемам. Мы сталкивались с ситуациями, когда работающий проект переносится с одной установки на другую и перестаёт работать из-за этого.
Например, ошибка блокирует выполнение запроса и парализует работу:
Код
Row size too large (> 8126)
При этом она не связана со архитектурными ограничениями MySQL, это вопрос "синтетического усиления" правильности. Вопросы формирования SQL должны решаться на уровне приложения, а не базы. Здесь это приводит к проблемам.
Зыков Илья написал: После последнего обновления "Корпоративный портал" main (19.0.400) в "Тестирование конфигурации" появилась ошибка "Ошибка! innodb_strict_mode=ON, требуется OFF" при проверке "Режим работы MySQL" переход на VMBitrix 7.4.2 не помогает.
$connection->queryExecute("SET sql_mode=''"); $DB->Query("SET sql_mode=''"); Не помогают.
Вчера по этому поводу получил ответ от поддержки:
В новой версии модуля main появилась проверка параметра innodb_strict_mode, у вас он в значении ON, для корректной работы требуется OFF, вам необходимо обратиться к вашему администратору сервера для исправления данного параметра. Если вы используете нашу виртуальную машину, то для исправления необходимо подключиться к серверу по FTP и добавить в файлы /etc/my.cnf, /etc/alternatives/my.cnf и /etc/bitrix-my.cnf строку
Денис Шаромов написал: Например, ошибка блокирует выполнение запроса и парализует работу: КодRow size too large (> 8126)При этом она не связана со архитектурными ограничениями MySQL, это вопрос "синтетического усиления" правильности.
Вам, конечно, виднее, но может надо было как в руководстве написано действовать, а не получить возможность тихо угробить данные. IMHO:
Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
Цитата
Денис Шаромов написал: Мы сталкивались с ситуациями, когда работающий проект переносится с одной установки на другую и перестаёт работать из-за этого. Row size too large (> 8126).
Скорее всего кодировка в таблице при переносе с однобайтовой на многобайтовую изменилась.
Дмитрий Дёмин написал: Скачанная с сайта виртуальная машина для VirtualBox версии 7.4.0 при попытке обновления до 7.4.1 умирает в процессе. Т.е. процесс зависает намертво, после перезагрузки машина не запускается с ошибками. С этим сталкивался уже не раз, благо на тестовых машинах.
При этом с версии 7.3.x до 7.4.1 обновляется без проблем.
Цитата
Ад Мин написал: Внесу свои 5 копеек. Ставлю, как обычно, битриксВМ на виртуалбокс (для теста, разработок), путем скачивания образа со страницы загрузок. Версия 7.4.0. При попытке обновления любым способом до 7.4.1 вешается, как писали выше. Выбор варианта виртуализации в виртуалбоксе ничего не меняет (раньше вообще не знал про эту настройку). Так что после перебора всех вариантов забил на обновление. Начинаю работать с 7.4.0. Где-то после 10-20 минут работы хост тупо умирает. Причем в ТОР нет ни апача, ни энджи, ни мускуля. Апач и нджи перезапускаются нормально, а БД вешается намертво. Приходится перезапускать хост. В проверке системы "Ошибка! innodb_strict_mode=ON, требуется OFF". В еррор логах апача [mpm_prefork:error] [pid 2762] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting В еррор логах нджи ничего серьезного. В еррор логах мускуля тоже вроде нет ошибок критических.
Надо добавить, что на локалке стояла сборка с боевого сервака версии 7.3.4, обновление на нее не встало, повисло так же. При попытке остановить процесс и перезапустить процесс дальше была потеряна связь с БД. Пришлось сносить все и экспериментировать с чистого листа...
Что я делаю не так? Почему все умирает празднично после 20 минут работы?
З.Ы.: хорошо что решил потестить обнову на локалке...
З.Ы.Ы.: Увеличение MaxRequestWorkers добавляет времени работы, но в конечном итоге все равно крашится. При этом сама виртуальная машина работает, не работает хост "Firefox не может установить соединение с сервером 192.168.45.182."
Дмитрий Дёмин, Ад Мин, добрый день. Спасибо за сигнал. Провели расследование. Детали ниже.
Итак: - чистый образ 7.4.0 для VirtualBox - на VirtualBox у машины время при старте произвольное (пример, в Калининграде у меня 12:12, по логу время "окт 17 15:12:25 localhost.localdomain mysqld[2792]: Version: '5.7.26-29' socket...") - mysqld стартует с этим временем - потом запускается ntpd, который синхронизирует время (итого получаем Москву - 13:12, я не менял часовой пояс, все по умолчанию) - запускаем обновление машины - при любом рестарте mysqld (в том числе и из обновления пакета) процесс зависает на очистке страниц, в логе (на время тут не обращаем) идут в цикле записи вида: ... Oct 17 12:54:47 localhost mysqld: 2019-10-17T09:54:47.711249Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool Oct 17 12:55:48 localhost mysqld: 2019-10-17T09:55:48.066399Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool Oct 17 12:56:48 localhost mysqld: 2019-10-17T09:56:48.409220Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool Oct 17 12:57:48 localhost mysqld: 2019-10-17T09:57:48.759395Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool ...
Баг в MySQL: Исправление: Fixed as of the upcoming 5.7.27, 8.0.17 release
В нашем образе версии 7.4.0 версия MySQL сервера 5.7.26 (Server version: 5.7.26-29 Percona Server). Через обновления прилетает как раз версия с фиксом - Percona-Server-server-57-5.7.27-30.1.el7.x86_64.rpm. Образы мы конечно пересоберем, выпустим новые. По срокам пока ничего сказать не могу.
Временное решение проблемы: консоль сервера, открыть два экземпляра. В первой запустить апдейт машины всех пакетов. Ждем когда зависнет (обычно рестарт mysqld будет на нашем пакете, в консоли увидите "Updating: bitrix-env-7.4-2.el7.noarch 235/448") Во второй убить процесс mysqld, например через htop или командой kill. В первой процесс обновления пойдет дальше, обновления поставятся. Или же второй вариант - до обновления пакетов остановить mysqld.
На других образах для иных типов виртуализации такого не замечено. VMWare/HyperV обновились без проблем.
Прочитал в первом посте, что есть возможность выбрать php 7.2.
Значит ли это, что битрикс избавился от mbstring.func_overload?
И какая сейчас самая свежая версия PHP на которой гарантированно последня версия битрикса будет работать? В чейнджлогах например вижу комментарии о поддержке php 7.3
Прочитал в первом посте, что есть возможность выбрать php 7.2.
Значит ли это, что битрикс избавился от mbstring.func_overload?
И какая сейчас самая свежая версия PHP на которой гарантированно последня версия битрикса будет работать? В чейнджлогах например вижу комментарии о поддержке php 7.3
Михаил Басманов, в меню машины есть мастер перехода на PHP 7.2 и откат назад на 7.1 (если какие-либо проблемы возникнут). В скором времени эта версия PHP станет версией по умолчанию. От mbstring.func_overload пока не избавились, работы идут. Но это не проблема виртуальной машины, а модулей продукта. На 7.2 работает сервис Битрикс24 и все его порталы. Гарантированно) Следовательно те же модули в поставке коробка будут работать. По 7.3 вы правы, поддержка идет, api модулей правится, обновления выпускаются. Коробочные версии Управление сайтом и Битрикс24 работают на этой версии PHP. По сторонним модулям зависит от поддержки их разработчиками.
Из 3-ёх коробок только одна смогла пройти первый шаг и обновить версию до 7.4.2: 1) консоль сервера - yum clean all && yum -y update Из 3-ёх коробок все 3 не смогли обновиться на втором шаге, ошибка: 2) через меню машины, 1.Manage servers in the pool > 4. Update packages on host, указываем имя сервера и тип обновления (all)
