klondike

Корпоративный блог студии "Клондайк"

Клондайк интернет маркетинга - WEB, SEO, SMM


Previous Entry Share Next Entry
Болдырев Михаил
klondike

Проблема инфоблоков+ (CMS 1C-Битрикс) и "Got error 139 from storage engine"

Исходные данные: Сайт на CMS 1С-Битрикс, Сервер – виртуальная машина 1С-Битрикс

Проблема: ошибка обращения к БД

Проявление проблемы: сайт не работает, ошибка MySQL "Got error 139 from storage engine".
Ошибка возникает из-за того, что в инфоблоке+ у нас много свойств (больше 80) и каждое свойство может содержать объёмный блок с контентом. В результате суммарная длина полей типа TEXT и VARCHAR в строке таблицы `b_iblock_element_prop_sXX` превышала ограничение MySQL на длину строки таблицы (примерно половина от размера страницы памяти 16 кБ).
Уменьшить количество свойств в инфоблоке в виду задач по проекту и нехватки времени не представляется возможным.


Рисунок: скриншот инфоблока со свойствами:
До возникновения проблемы

Рассмотрим варианты решения проблемы:


  1. Удалить MySQL, собрать MySQL из исходников изменив UNIV_PAGE_SIZE  и UNIV_PAGE_SIZE_SHIFT. Тем самым увеличив размером страниц памяти. Как описано до нас: http://dev.1c-bitrix.ru/community/webdev/user/8078/blog/1797/

  2. Переделать инфоблок+ и вынести группы свойств в отдельный инфоблок.

Плюсы и минусы вариантов решений

1. Мы получаем кастомизированную MySQL и теперь данный сайт привязан к определённой конфигурации сервера. При том, что сайт не является мега проектом, кастомизировать сайт под сервер проще, чем наоборот.

Возможные осложнения:


  • При сборке  MySQL из исходников потребуется удалить существующую БД. А следовательно приостановить все веб сайты на данном сервере. Включая доступы до FTP и web админки (при хранение данных в MySQL)$

  • При  установки MySQL из исходников  могут быть не найдены зависимые пакеты, компилятор  и т.д. Потребуется дополнительно установить все недостающие зависимости. Возможно, это приведет к увеличению простоя.

  • После сборки пакета он может  некорректно установится, мало вероятно, но возможность все еще остается, если мы говорим о боевом сервере данная возможность нас не радует.

  • Непредвиденные вещи. Linux, FreeBSD и т.д. не всегда гладко и хорошо работают при кастомизации. Фактически данный пункт включает в себя следующее: «Дать голову на отсечение, что все пройдет гладко, мы не сможем»,  собственно как и точные сроки простоя. Хоть и  операция займет займёт не более 20 минут, но не имея клона  боевого сервера для теста, лучше не рисковать.

  • В последствие возможно появление проблем, природа которых ближе к архитектуре  самого MySQL нежели  к привычной сфере PHP.

  • В нашем случае база данных была бы повреждена в 2:00 ночи. Утилита mysqlcheck   проверяющая  БД каждую ночь сочтет данную таблицу ошибочной и «востоновит» а фактически затрет ее.

  • Возможны проблемы при оптимизации БД утилитами.

  • При переносе сайта на другой сервер, БД умирает. При переносе сайта на сервер с отсутствием доступа ROOT SSH сайт вообще невозможно будет корректно запустить!

2. Модификация программного кода. Здесь необходима работа программиста. А также получаем не очень правильную структуру с точки зрения удобства заполнения контента.

Выбрали вариант 2:
После решения проблемы

ИТОГ: Вынесли некоторые свойства в отдельный связанный элемент.

Если у Вас есть комментарии и предложения, пишите!

  • 1
очень полезно, спасибо

  • 1
?

Log in

No account? Create an account