Если для решения проблемы "Got error 139 from storage engine" вы воспользоваться советов приведенным в посте Инфоблоки+ и "Got error 139 from storage engine" у вас может возникнуть следующая проблема:
При работе в базе разваливается одна из таблиц при этом в логи сервера БД валяться ошибки с сообщением 'нет доступа к странице xxx возможно она повреждена или удалена' (нет оригинала сообщения поэтому вольная интерпритация).
При этом база в общем то работает и даже из поврежденной таблици можно вытащить всю информацию кроме конкретной записи и того что после нее.
Данная ошибка возникает из за того что после увеличения страницы памяти при пересборке мускуля видимо отключается или перестает корректно работать проверка на максимальную длину строки таблицы. Таким образом если у вас теоретически при заполнение все полей эта вставка будет больше 32 кБ произойдет описанная выше ошибка.
Чтобы избежать ее небходимо:
1. для инфоблоков с большим количеством свойств проверить не превышает ли теоретически они этот предел (в таблицах b_iblock_element_prop_xxs).
2. ну и делать чаще дамп
Если же произошла ошибка то помогает только удаление целиком таблици и восстановление ее из дампа либо того что удалось вытащить, но лучше при возникновении этой ошибки удалить и восстановить целиком базу так как иногда наблюдался "пост эффект" (аналогичная ошибка на других таблицах на которых она теоретически не должна была появляться).
В целом же если учесть это и в проверить то других ошибок не возникает, база работает стабильно.
А что если, например, сделать одно множественное свойство для текстовых характеристик?
Так-то да. Но: - там ограничение на 255 символов - есть ряд свойств, обладающие списочными значениями (например,, тот же размер колес из примера выше редактору проще выбирать из списка)
В общем с одной стороны да, можно закастомизировать свой тип свойств со всякими рюшечками, но очень сильно будет жать ограничение символов.
В PostgreSQL кластеризация работает из коробки. Недавно была задачка на VPS с весьма low-end характеристиками установить Битрикс и Zabbix в одном флаконе. Для Битрикса использовалась Percona XtraDB. После старта сервера Zabbix, сервер перконы ложился напочь. Ok. Пусть Битрикс живёт со своей Percona, а Zabbix мы отправим в SQLite. Заработало. Но (ессно) медленно. Ok. Поставим рядом PostgreSQL и пусть Zabbix работает с PostgreSQL, а Битрикс со своей перконой. И вот тут всё сложилось: все работают, никто не тормозит. Возникает вопрос: почему бесплатный Zabbix можно поставить и на SQLite, и на MySQL, и на PostgreSQL, и на Oracle, и на IBM DB2, а в Битрикс надо выбирать между MySQL и Oracle? При том что PostgreSQL оказывается явно производительней хвалёных форков MySQL "из коробки" и всё это происходит на фоне воплей об импортозамещении? Вопрос риторический, ответов не жду..
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».