Для начала, хорошо-бы, создать static.lib.rus.ec с книгами, на отдельном сервере. Используя только "static html"(генерировать скриптом, периодически).
А для "фич" использовать javascript и ajax.
Небудет всех "фич", но такой сервер выдержит, с честью, даже нагрузку на всю ширину канала.
А потом, если понравится, писать что-то вроде StillLife Витуса Вагнера.

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

Ещё меня вот какой вопрос волнует: кэшируются ли как-то страницы (читай "запросы к базе данных") или для каждого юзера каждая страница, включая главную, собирается за ново из данных базы? Мне кажется сам сайт может сам контент кэшировать, обновляя кэш только при вносимых изменениях. Тогда для каждого юзера страницы будут не собираться, а только высылаться.

условия, как я понимаю, как раз такие, что стандартное решение не прицепишь, а именно: IP может быть произвольным и зеркало может исчезнуть в любой момент. Главный сервер можно заставить вести подписку зеркал следующим образом:

1) чел, у которого копия сайта (скажем исключительно download-часть) заходит на lib.rus.ec/mirrors/subscribe?now, чем его IP вносится в живой список зеркал и участвует далее в механизме распределения нагрузки.
2) либрусек с того момента начинает пинговать сервер раз в минуту и выносит его IP из списка, если сервер не пронинговался 3 раза подряд с таймаутом в 10 секунд.
3) выбор зеркала делать на основе отчёта ps (unix) и данных о ширине канала (тут некоторый задел для творчества): загрузка . Где зеркала на виндах, либо разгрузку делать по рандому, либо придумать простой критерий выбора. Либо вообще всегда выбирать по рандому, но в данной задаче это может оказаться неэффективным, но для запуска пойдёт. Впрочем, всё зависит от того, какие каналы, какие вычислительные мощности, какие ОС будут у зеркал и сколько их будет. Возможно рандом окажется более оправданной концепцией и более простой в реализации.

Вот всё, что нужно. Демиургам сайта нужно лишь определить, какие части кода сайта жрут больше 1) трафика 2) камня, а затем определить, что из этого можно разделить без массивного кодирования.

Для начала хотя бы обрисуйте цифры, какие части сайта сколько каких ресурсов жрут, чтобы все видели и думали предметно, нежели абстрактно.

Действительно похоже на P2P, однако это скорее ad-hoc симбиоз централизованного Web-подхода и P2P распределения. Для юзера всё прозрачно, для исполнителей (повелителей зеркал) элементарно, для либрусека - самомасштабируемая подмога за цену минимальных пальцодвижений. Живучесть великолепная, масштабируемость замечательная. Единственное, уход серверов в любой момент конечно даст о себе знать, но хуже, чем сейчас, будет вряд ли.

Списки зеркал, кстати, всё-равно хорошо бы иметь в явном виде, чтобы FlashGet-ом, например, выкачивать со всех зеркал одновременно - там можно задавать список зеркал.

Беда с мускулом в такой схеме не решается кстати. Предложенное очевидно помогло бы разгрузить проблемы трафика, которые пока остро не стоят. Из реализуемого для мускула наверное только разделение форумов на корню - разные машины, разные базы данных - всё отдельно. Но опять же: нужны конкретные цифры по загрузке ЦПУ, - всё станет очевидно.

bw

Да хз... Есть сервер. Че на нем вообще делать надо, чтобы зеркало заработало? Че на нем сделать надо, чтобы сервер автоматом синхронизировал бд? Ну и т.д... Проще говоря: как правильно прикрутить движок к "пустому" серверу :)