mysql-репликация с блек джеком - поделитесь опытом

извините, но АП. Не верю что никто не работал с репликацией

Если единственная причина, по которой вы решили задать столько вопросов, случайное нахождение этих статей - вам это не нужно.

уверен, что это будет самым полезным ответом :

Найдите один надежный, хостинг который не будет простаивать. И все.

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

Плюс репликация это лишний бекап и возможность поднять сайт (или не ронять его вообще) в случае краша диска на сервере, плюс это снижение нагрузки на 1 сервер и в случае географического разнесения - уменьшение пинга и времени закачки для конечных посетителей. А еще примитивный анти-ддос и еще много чего.

Metal_Messiah, саму репликацию mysql настроить тривиально. Для этого даже в phpmyadmin мастер настройки есть. Механизм репликации master-slave достаточно надежен, обкатан годами и постарше некоторых посетителей форума будет (14 лет ему, с версии 3.23.15 ).

Нетривиально же решить все остальные смежные вопросы. Один сервер - одна проблема. Два связанных сервера - восемь проблем !

Исходя из постановки ваших вопросов, я делаю вывод, что вам очень много придется разбираться с ними.

Оно вам надо ? Какая такая гигантская выгода в итоге получится от освоения этой массы смежных технологий?

Отказоустойчивость ? Да терпят все. Как только у %%хостернейм%% возникают проблемы, соответствующая тема затухает на следующий день же после исправления этих проблем.

Ну сходите в раздел Хостинг. Там раз в полгода такие темы возникают. А давно что-то не было их.

Т.е. рекомендуете делать master-slave и 2 постоянных коннекта от php 1 для SELECT (рандом мастер-слейв) и 2й для UPDATE / INSERT (только мастер) в предположении что когда мастер упадет сайт работать будет но не будет обновляться?

Metal_Messiah, мы сейчас о том как сделать рабочей конкретную технологию или о выборе архитектуры вообще?

Можете делать. А можете не делать. Оптимальный выбор зависит от разных факторов, которые вы тут не изложили.

но исходя из описания

и того как я оцениваю доходность и требования к отказоустойчивости у подобных сайтов, я рекомендовал бы этого не делать вообще. Так никто не делает.

Сколько раз в день у вас падает VPS и почему это вообще происходит ? Не проще ли поменять ?

Дублирование данных must have это я уже решил, хотя Вы правы, вопрос скорее о выборе архитектуры. Я думал Master-Master, но меня уже почти убедили что лучше Master-Slave, 2 веб сервера. Падал mysql 2 раза за последние 3 или 4 месяца, один раз упал утром, а я об этом узнал только вечером когда добрался до компьютера. Скорость закачки с сайта зависит от географии, а посетители грубо говоря со всего мира. Плюс мало ли вдруг забуду вовремя продлить один из серверов. Плюс мало ли будет ддос атака на один из них или на соседей, а ляжет половина ДЦ.

MySQL proxy ставить или нет? Можно же подключаться ко 2 серверу при отсутствии коннекта к первому, а чтобы не ждать mysql connection timeout каждый раз - при пропадании сервера писать файл-флаг, который будет периодически устаревать, а до тех пор php будет подключаться к альтернативному серверу - итого при проблемах только 1 страница будет открываться 30 секунд, остальные быстро.

У меня нет опыта работы с репликацией, потому и начал с того что прошу совета тех, у кого опыт есть.

Пока перевожу движок с php/mysql на mysqli. Будет 1 мастер и 2 слейва.

Вопрос выбора архитектуры: в php добавить проверку при проблемах с коннектом подключаться к другому серверу с кешем этого флага на файле (чтобы при падении каждое открытие страницы не ломилось на дохлый серв) + проверка куда слать запрос (запись в мастер, чтение на слейв) или подключаться только на localhost, где поставить mysql-proxy? Как лучше?

С одной стороны, пишут что mysql-proxy дает потерю производительности (хотя я не понимаю откуда, если и БД и прокси будут на одном VPS и пинг не должен расти), с другой мой самодел на php будет по сути повторять код mysql-proxy.

Не тем вы занимаетесь, имхо