чтобы быстро открывался. вот вылетит сайт из индекса - узнаете почему это важно.
проблемы возникают при специфических одновременных редактированиях одной и той же записи:
например
на сервере1 : update tab set val=val+1 where id=123
на сервере2: update tabl set val=val*2 where id=123
оба изменения проигрываются на обоих серверах и на них получаются разные данные, в зависимости от порядка исполнения и НИКАКИХ ОШИБОК репликации не возникает. Просто логическое расхождение. Поэтому master-slave самый безопасный механизм репликации.
что вам мешает при редактировании делать подключение к другой базе данных ?
остальное на сайте будет работать локально, а администраторская часть будет подключаться удаленно к master-серверу.
и если редакторы правят записи по смыслу одинаково, то может и можно игнорировать такой эффект. ну запишется в неизвестном порядке одна из правильных правок и что.
врете. игнорировать таблицы нельзя. можно игнорировать базы данных.
но это может вызвать трудноуловимые глюки, поэтому рекомендуют выставить для игнорируемых таблиц engine=blackhole. таким образом можно игнорировать и таблицы, но трафик на передачу этих обновлений при этом расходуется, конечно.
обычно да.
можно настроить репликацию master-master "по кругу" и обновлять обе базы, но это вызывает еще более трудноуловимые глюки в некоторых видах запросов. постарайтесь что-нибудь придумать чтобы обновлять в одном месте.
не получится - значит пытайтесь master-master. может, в вашем случае прокатит.
проблема в том, что вы нескоро узнаете о рассинхронизировавшейся базе.
Это вы так думаете пока с openx не столкнулись.
Boris A Dolgov, по дефолту, если вы ее не выключили, то каждый незарегистрированный( кто не отключил кукисы, но таких просто нет). откуда вам заранее знать какая из тем станет популярной? так что пометка тем будет сломана глобально на всем форуме. даже не сломана, а испорченна - будут отображаться странички с чужой пометкой, разные темы будут подсвечены как непрочитанные.
Boris A Dolgov, и у гостей в vbulletin отключалась пометка прочитанных тем. она там есть.
я уже молчу про запароленные разделы и тд.
Живой форум кешировать бесполезно. Форум могут кешировать только сеонизаторы, потому что поисковики могут и посмотреть позавчерашнюю информацию, а людям нужна свежая.
На развитом форуме еще хуже. Против кеширования работает пометка прочитанных тем, список "кто в этой теме?", игнорирование пользователями друг друга, баны и т. д. То есть информация во многом уникальная для каждого пользователя.
С точки зрения диагностики, важнее разнести задачи по массивам. Тогда намного проще на глаз оценить какая из задач дает большую нагрузку, независимо от программы и встроенных в нее возможностей диагностики.
И можно, например, низкоприоритетным задачам не давать разогнаться. Причем абсолютно точно известно, что они не повлияют на производительность важных задач.
и снова приходим к mysql-proxy.
Так тогда вообще изначально не нужно было париться.
Хорошие скрипты, типа vbulletin, кстати, логически разделяют master и slave. Многоходовые операции чтения, логика которых может поломаться из-за задержки репликации, тоже на мастер посылаются.
Himiko, это не глюк. просто скрипт такой без учета состояний кодировок написан. транзакции, например, он не прерывает.
зачем тестировать haproxy, если он не отделяет запись от чтения ?
