Понял. Я уже наклепал пару лишних функций на php, master_query(), slave_query() и т д, которые проверяют наличие подключения и выбирают сервера по списку в порядке приоритета, раз mysql-proxy заставлять работать нет смысла то перехожу на эту систему...
Поставь самопальный скрипт на морду, который не будет использовать БД и прочие дела, грузящие сервер, скрипт дает юзеру куку-флаги редирект на себя. Если после этого юзер пришел без куки - бан ему (блеклист), если с кукой - уже давай контент сайта. Должно помочь.
Как наиболее жесткий метод борьбы с ДДОС - закешировать весь контент и отдавать его nginx'ом, но над реализацией надо подумать. Я эту идею так и не реализовал, доведя только до уровня отдачи какой-то устаревшей страницы вместо последней актуальной в случае отсутствия ответа от БД по too many connections (когда-то такое было на хостинге)
Пока перевожу движок с php/mysql на mysqli. Будет 1 мастер и 2 слейва.
Вопрос выбора архитектуры: в php добавить проверку при проблемах с коннектом подключаться к другому серверу с кешем этого флага на файле (чтобы при падении каждое открытие страницы не ломилось на дохлый серв) + проверка куда слать запрос (запись в мастер, чтение на слейв) или подключаться только на localhost, где поставить mysql-proxy? Как лучше?
С одной стороны, пишут что mysql-proxy дает потерю производительности (хотя я не понимаю откуда, если и БД и прокси будут на одном VPS и пинг не должен расти), с другой мой самодел на php будет по сути повторять код mysql-proxy.
Дублирование данных must have это я уже решил, хотя Вы правы, вопрос скорее о выборе архитектуры. Я думал Master-Master, но меня уже почти убедили что лучше Master-Slave, 2 веб сервера. Падал mysql 2 раза за последние 3 или 4 месяца, один раз упал утром, а я об этом узнал только вечером когда добрался до компьютера. Скорость закачки с сайта зависит от географии, а посетители грубо говоря со всего мира. Плюс мало ли вдруг забуду вовремя продлить один из серверов. Плюс мало ли будет ддос атака на один из них или на соседей, а ляжет половина ДЦ.
MySQL proxy ставить или нет? Можно же подключаться ко 2 серверу при отсутствии коннекта к первому, а чтобы не ждать mysql connection timeout каждый раз - при пропадании сервера писать файл-флаг, который будет периодически устаревать, а до тех пор php будет подключаться к альтернативному серверу - итого при проблемах только 1 страница будет открываться 30 секунд, остальные быстро.
У меня нет опыта работы с репликацией, потому и начал с того что прошу совета тех, у кого опыт есть.
Т.е. рекомендуете делать master-slave и 2 постоянных коннекта от php 1 для SELECT (рандом мастер-слейв) и 2й для UPDATE / INSERT (только мастер) в предположении что когда мастер упадет сайт работать будет но не будет обновляться?
Защититься от простоев невозможно, каждый хостинг рано или поздно присылает уведомления о технических работах.
Плюс репликация это лишний бекап и возможность поднять сайт (или не ронять его вообще) в случае краша диска на сервере, плюс это снижение нагрузки на 1 сервер и в случае географического разнесения - уменьшение пинга и времени закачки для конечных посетителей. А еще примитивный анти-ддос и еще много чего.
извините, но АП. Не верю что никто не работал с репликацией
ЛУчше так:
.htaccess
index.php
+ robots.txt не забудь
Адресация сохраняется + можно контроллировать заходы на зеркала и когда они кончатся не продлевать старые домены. Я так "оптимизировал расходы" одной фирмы, зарегистрировавшей с десяток доменов в разных зонах под 1 сайт
вариант от siv1987 по идее рабочий, но я бы делал на php через ob_start поиском сигнатуры и подменой, т.к. там же явно не все таблицы всех страниц заменить надо
P.S. а зачем ьаблицу дивами заменять? Проще на таблицу CSS переписать
IGMP? IPTV proxy? подробнее о технологии
