Пока перевожу движок с 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? подробнее о технологии
Фильмы на ВКонтакте заливать от имени десятка разных аккаунтов с разных IP без пересечений чтоб не банили - вот бесплатное решение.
А если серьезно - правильно сказали, для движка один, для видео-контента пачка серверов, в виде CDN или подобия CDN, популярные видео раскладваются на максимуме серверов, малопопулярные на 1 хватит, движок сайта смотрит в базу на каких серверах лежит запрошенный файл, смотрит их доступность (проверка кроном раз в 5 мин и флаги в таблице) и выдает рандомный адрес, я так хостинг картинок делал - при закачке картинки пользователем она заливалась сразу на 2-3 сервера.
siv1987, спасибо, помогло
проверку даты убрал.
Плюс к тому у меня был косяк - если новостей по теме найдено меньше N, делался 2й запрос выборки M последних по дате новостей, где использовалось WHERE date>(time()-86400) - т.о. запрос каждую секунду менялся и не кешировался, округлил это число до 5000 секунд, теперь кешируется.
tls,
по сути этот перенесенный сайт и есть вся нагрузка. остальное - мелочи, машина почти простаивала.
Пока как результат после десятка просмотренных страниц время порядка 0.05 сек, максимум выброс 1 секунда с мелочью.
Завтра еще посмотрю в конце дня по логу MYSQL запросы в пиковое время, на которые уходит более секунды, если что буду пробовать InnoDB.
