Разработчикам

Форум

[ Закрыто ] VMBitrix 7.4.0 в релизе

Пользователь 381749

Заглянувший

Сообщений: 12 Регистрация: 25.10.2015

#151

13.10.2019 08:32:11

При установки системы на чистую CentOS 7 возникает ошибка:

Код

System update in progress. Please wait.
EPEL repository is already configured on the server.
Getting REMI repository configuration. Please wait.
REMI repository has been configured successfully.
Percona repository configuration has been completed.
Getting Bitrix repository configuration. Please wait.
Bitrix repository has been configured.
System update in progress. Please wait.
Installing php packages. Please wait.
Installing bitrix-env package. Please wait.
Error installing package: bitrix-env
Log file path:  /tmp/bitrix-env-Hhcl1.log

Смотрим логи:

Код

Объем загрузки: 147 M
Объем изменений: 394 M
Downloading packages:
warning: /var/cache/yum/x86_64/7/percona-release-x86_64/packages/Percona-Server-client-57-5.7.27-30.1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
Публичный ключ для Percona-Server-client-57-5.7.27-30.1.el7.x86_64.rpm не установлен
http://repos.1c-bitrix.ru/yum/el/7/x86_64/bx-nginx-1.16.1-1.el7.ngx.x86_64.rpm: [Errno -1] Пакет не соответствует предложенному для загрузки.^M
Предлагается выполнить: yum --enablerepo=bitrix clean metadata
Пробуем другое зеркало.


Error downloading packages:
  1:bx-nginx-1.16.1-1.el7.ngx.x86_64: [Errno 256] No more mirrors to try.

2019-10-13T08:04:03: 12859 : Error installing package: bitrix-env
2019-10-13T08:04:03: 12859 : Log file path:  /tmp/bitrix-env-Hhcl1.log

Если установить пакет в ручную, после того как вылазит ошибка:

Код
yum installl http://repos.1c-bitrix.ru/yum/el/7/x86_64/bx-nginx-1.16.1-1.el7.ngx.x86_64.rpm

А потом продолжить установку - BitrixVM ставиться, правда вызывает вопросы дальнейшая стабильность.

P.S. У BitrixVM Beta проблема такая же.

Пользователь 579081

Заглянувший

Сообщений: 22 Баллов: 2 Регистрация: 06.05.2016

#152

13.10.2019 22:42:07

Код
Updating: bitrix-env noarch 7.4-2.el7 bitrix 6.1 M

Обычно сначала вижу анонс здесь, а потом в консоли, сейчас получилось наоборот.
Что нового в релизе?

Алексей Шафранский Администратор Сообщений: 1103 Баллов: 213 Регистрация: 28.07.2008	#153 0 14.10.2019 16:43:02 red_eye, Лев Немировский, Владислав Пишко, проблема репозитория исправлена, файлы кеша репы перегенерированы. Установка на чистую ОС работает.

Алексей Шафранский

Администратор

Сообщений: 1103 Баллов: 213 Регистрация: 28.07.2008

#154

14.10.2019 16:43:56

Коллеги, виртуальные машины 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.

Всем удачи. Спасибо за обратную связь!

Пользователь 328495

Посетитель

Сообщений: 23 Баллов: 3 Регистрация: 15.05.2019

#155

16.10.2019 13:05:12

После последнего обновления "Корпоративный портал" main (19.0.400) в "Тестирование конфигурации" появилась ошибка "Ошибка! innodb_strict_mode=ON, требуется OFF" при проверке "Режим работы MySQL" переход на VMBitrix 7.4.2 не помогает.

$connection->queryExecute("SET sql_mode=''");
$DB->Query("SET sql_mode=''");
Не помогают.

Алексей Шафранский

Администратор

Сообщений: 1103 Баллов: 213 Регистрация: 28.07.2008

#156

16.10.2019 16:07:34

Зыков Илья, все верно, в модуле main версии 19.0.400 добавилась новая проверка.

Поправить можно так: в файле /etc/mysql/conf.d/z_bx_custom.cnf (или /etc/my.cnf) добавить

Код
[mysqld] innodb_strict_mode = OFF

и перезапустить mysql.

Этот фикс выйдет в следующих обновлениях vmbitrix.

Пользователь 328495

Посетитель

Сообщений: 23 Баллов: 3 Регистрация: 15.05.2019

#157

16.10.2019 18:28:54

Временно можно и так:

http://dev.1c-bitrix.ru/support/forum/messages/forum23/topic115747/message621488/#message621488

Но не могли бы вы ответить на вопрос, а то пока так и не сказали, зачем эта проверка теперь нужна, ведь если этот параметр в OFF, то уменьшается надёжность.
Он ведь давно был в ON (с версии MYSQL >= 5.7.7) и вроде всё работало.

То есть, до этого момента работало не корректно или как? Или это требование исключительно нового модуля?
В таком случае, что работало не корректно?
Ведь этот параметр как раз и позволяет делать только однозначные запросы, а неоднозначные сразу выявлять как ошибочные. А теперь, неоднозначные запросы будут обрабатываться MYSQL по своему усмотрению, возможно, неправильно. Ну и пусть? Зато это не мешает работе новой версии модуля?

Пользователь 3559110

Заглянувший

Сообщений: 2 Регистрация: 17.10.2019

#158

17.10.2019 09:34:02

Внесу свои 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
В еррор логах нджи ничего серьезного.
В еррор логах мускуля тоже вроде нет ошибок критических.

prefork.conf дефолтный

# from bitrix_env
# memory: 2048MB
<IfModule mpm_prefork_module>
StartServers 10
MinSpareServers 10
MaxSpareServers 10
MaxRequestWorkers 10
MaxRequestsPerChild 5000
</IfModule>

Надо добавить, что на локалке стояла сборка с боевого сервака версии 7.3.4, обновление на нее не встало, повисло так же. При попытке остановить процесс и перезапустить процесс дальше была потеряна связь с БД. Пришлось сносить все и экспериментировать с чистого листа...

Что я делаю не так? Почему все умирает празднично после 20 минут работы?

З.Ы.: хорошо что решил потестить обнову на локалке...

З.Ы.Ы.: Увеличение MaxRequestWorkers добавляет времени работы, но в конечном итоге все равно крашится. При этом сама виртуальная машина работает, не работает хост "Firefox не может установить соединение с сервером 192.168.45.182."

Пользователь 3954

Администратор

Сообщений: 2072 Баллов: 290 Регистрация: 28.03.2006

#159

17.10.2019 10:44:50

Если установлено значение innodb_strict_mode=ON, MySQL делает дополнительные проверки запросов, что в ряде случаев приводит к проблемам. Мы сталкивались с ситуациями, когда работающий проект переносится с одной установки на другую и перестаёт работать из-за этого.

Например, ошибка блокирует выполнение запроса и парализует работу:

Код
Row size too large (> 8126)

При этом она не связана со архитектурными ограничениями MySQL, это вопрос "синтетического усиления" правильности. Вопросы формирования SQL должны решаться на уровне приложения, а не базы. Здесь это приводит к проблемам.

Пользователь 2337525

Постоянный посетитель

Сообщений: 180 Баллов: 35 Регистрация: 01.03.2019

#160

17.10.2019 11:23:26

Цитата

Зыков Илья написал:
После последнего обновления "Корпоративный портал" 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 строку

innodb_strict_mode = OFF

В блоке # InnoDB parameters

Мне эта инструкция помогла и ошибка пропала.

Форум

Центр поддержки

Продукты

Управление сайтом

Битрикс24

Интернет-магазин + CRM

Решения

Для интернет-магазинов

Каталог готовых решений

Внедрение

Выбрать партнера

Проверить партнера

Стать партнером