Qest, точно так же как и с маленькими, только думать придется чаще.
И на самом деле обновление информации есть даже в sphinx. Но не обязательно нужно бросаться реализовывать это, когда можно продумать структуру обычной бд mysql.
Существует множество странных вопросов навсегда оставшихся без ответа. Особенно много их задают пациенты психиатрических лечебниц. Этот вопрос именно такой.
Расскажите лучше какой результат вы хотите получить.
Вообще, для справки : sphinx помимо обычного api, реализует альтернативный интерфейс для доступа похожий на протокол mysql. Язык, который там реализован называется SphinxQL. Поэтому к sphinx можно подключаться из php как к серверу mysql с помощью функций mysql.
Каким образом вы решили, что это поможет вам обновлять базу mysql не понятно.
Тогда это уже не парковка, а хостинг.
Действительно ли нужны эти папки ? неужели нельзя однотипные странички выводить ?
Все бы нормально и понятно, но зачем прикрывать это "проблемами с производительностью и безопасностью" ?
А зря. Вам могли бы подсказать альтернативные решения.
Парковка ведь не подразумевает разнообразный контент. Иначе это называлось бы хостингом.
По сути в апаче вам нужен один единственный виртуалхост, но скрипты должны определять какой именно домен обрабатывают и генерировать нужное содержимое страницы.
Segey, остальное нужно просто спроектировать и настроить.
если вы гуглите и ничего не понимаете, значит и объяснения на форуме вам будут давать больше вопросов чем ответов.
Видеосайту обычно не нужна репликация базы. Им нужно забить дешевые гигабитные линки на всех серверах. Для этого достаточно копировать файлы видео на несколько раздающих серверов.
Для кодирования делают специальные кодировочные фермы. По-моему даже готовые скрипты типа AVS имеют платную опцию для построения этих ферм.
Ради одного кодирования видео городить кластеры неразумно.
Да, в течении некоторого небольшого времени TTL в проекте этой схемы некоторые пользователи получали бы ошибки.
Однако, плюсы тоже есть :
- Более широкий выбор схем дублирования. можно задействовать резервные сервера, которые не работают постоянно и не обязаны быть такими же быстрыми как основные.
- К асинхронной односторонней репликации данных в другой ДЦ совсем другие требования по скорости. Она гораздо быстрее и проще, чем поддержание актуальных копий данных на каждом сервере для RR. Синхронная репликация в другой ДЦ может вообще так медленно работать, что функционирование RR-кластера будет невозможно.
- Можно в некоторой степени устроить распределение нагрузки по географическому признаку как в BGP.
- По сравнению с BGP, стоимость организации мизерная. В минимальной конфигурации нужно всего лишь два VPS в разных ДЦ.
Все это было бы, если бы не поведение IE.
Для RR получаем, что некоторые пользователи, браузеры которых не поддерживают RR особым образом при наступлении сбоя в 50% случаев не смогут открыть сайт до устранения сбоя. Как много таких браузеров еще нужно выяснить.
В браузере могли реализовать работу с RR, но для работы с DNS-файловером точно не нужно никакого особенного кода в программе. Этим она и лучше.
По-моему, все прекрасно понятно. Перечитывайте.
Если каждый из dns-серверов осуществляет мониторинг доступности серверов сайта, то он может выдавать клиентам IP сайта в зависимости от доступности сервера(-ов).
При разрешении имен, библиотеки dns, обязаны опрашивать следующий ns-сервер, если очередной не отвечает. Это поведение dns было задумано с самого начала и документировано. Именно этим оно и лучше.
Нет. Допускаю, что решение об использовании RR было принято только ради балансировки. Все остальное вы придумали.
Возможность его осуществлять весьма скромными техническими ресурсами. Ну это без учета проблем синхронизации.
Могло и так быть, раз противное не доказано.
