Проблема инфоблоков+ (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:

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

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