1. [B]Требования к серверу (Минимум для 2025 года)[/B]
Обычный виртуальный хостинг не справится. Вам понадобится выделенный сервер (Dedicated) или мощный VPS/VDS.
Процессор: Минимум 8–12 ядер (Ryzen 7/9 7000+ серии или современные Xeon), так как Bitrix требователен к частоте на одно ядро.
Оперативная память (RAM): Минимум 32–64 ГБ. Большой объем нужен для кэширования (Memcached/Redis) и стабильной работы MySQL/PostgreSQL.
Дисковая подсистема: Только NVMe SSD. Объем базы данных и файлов (особенно картинок) для 19 сайтов быстро вырастет до сотен гигабайт.·
БД: Обязательная настройка индексов и оптимизация my.cnf.
2. [B]Технические последствия[/B]
Единая точка отказа: Если упадет база данных или произойдет критическая ошибка в коде ядра, лягут все 19 сайтов одновременно.
Раздувание базы данных: Таблицы поискового индекса (b_search_content), статистики и логов будут расти в 19 раз быстрее. Это замедлит выполнение SQL-запросов.
Конфликты обновлений: При обновлении модулей или ядра Bitrix изменения применяются сразу ко всей сети. Если кастомный код на одном сайте несовместим с обновлением, проблемы могут возникнуть на всех остальных.
Сложность бэкапа: Создание резервной копии всей системы будет занимать много времени и места. Восстановить один конкретный сайт из общего бэкапа будет крайне сложно.
[B]Ответ разработчиков bitrix: ( неже ответ который я считаю не развернутый или невминяемый )[/B]
[COLOR=#0a0a0a]1. Указанная «единая точка отказа» не является следствием выбранной схемы многосайтовости, а представляет собой стандартное свойство любой архитектуры, в которой сайты работают на одном сервере и используют общую базу данных. В случае отказа MySQL недоступность затронет все сайты ([B]ВОПРОС БЫЛ НЕ ПРОПАДЕНИЯ СЛУЖБЫ MYSQL, ПАДЕНИЕ ЛЮБОЙ ОБЩЕЙ ТАБЛИЦЫ[/B]) вне зависимости от того, реализованы они как многосайтовость Bitrix или как отдельные проекты на одном сервере, поэтому данный риск не относится к недостаткам текущего решения и устраняется организационными мерами - резервным копированием, мониторингом и при необходимости репликацией БД.[/COLOR]
[COLOR=#0a0a0a]2. Критические ошибки в ядре не возникают спонтанно и, как правило, являются следствием некорректных обновлений или изменений. ([B] опять мутный ответ, ведь вопрос был другой, на сколько это эфективно, затронет одна ошибка все сайты или нет[/B] ) В рабочем процессе обновление ядра и модулей Bitrix выполняется предварительно на тестовом сайте, что позволяет выявить возможные несовместимости и исключить их попадание в продакшен. Такой подход является стандартной практикой и минимизирует риски возникновения критических сбоев на всех сайтах.[/COLOR]
[COLOR=#0a0a0a]3. Рост базы данных определяется объёмом контента и посещаемостью, а не количеством сайтов. При корректной настройке очистки и кэширования размер базы данных остаётся под контролем ([B] опять уход куда-то воблока, вапрос был не как решать проблему а являится ли это проблемой как таковой, эфективно ли это[/B] ).[/COLOR]
[COLOR=#0a0a0a]4. Все сайты используют единый шаблон и общую кодовую базу без модификаций ядра. Обновления системы выполняются централизованно и не создают дополнительных рисков по сравнению с поддержкой одного сайта ([B] ахахах, тут я вооще ржал как конь... т.е. многосайтовость даже лдче при обновлении чем один сайт.. [/B]).[/COLOR]
[COLOR=#0a0a0a]5. Создание резервной копии занимает столько же ресурсов, ([B] опять уход в некуда, вопрос был на сколько эфективны бекапы если нужно откатить один сайт .. а не все сайты[/B] ) сколько и на простом сайте с аналогичным кол-во контента. Так же резервное копирование выполняется на уровне сервера и охватывает файлы и базу данных целиком. Это наиболее надёжный и распространённый способ защиты данных на VPS. Восстановление при авариях выполняется быстро и предсказуемо.[/COLOR]
[B]( лично я с этим не согласен и ответ не был дан... ) прошу прокасультировать..[/B]
