У меня биллинг написан был нами без учета мастер-мастер репликации. В один прекрасный момент я взял, и поднял мастер-мастер репликацию. И биллинг туда перевел. И десяток популярных движков для сайтов на этом кластере сидели.... Так что не рассказывайте.
Если уж так не нравится репликация - поднимите сервер базы данных отдельно. Только как вы его защищать от падения будете....
уговорили, откуда мне сирому основы работы Сети то знать... я тут так, провайдером работаю...
Итак, вернемся к вопросу. "Сегодня утром возникла ситуация, когда у хостера были проблемы с провайдером". Что в данном случае будет? Праавильно, connection failed. Описанный вами вариант размещается весь целиком у этого самого хостера. Если нет - то я с интересом послушаю, как вы поверх интернета файловую систему разворачивать будете... С негарантированными задержками и транспортом. Ну или просто репликацию ФС. Как развернете и заработает - можете посылать свое резюме в IBM,Google и т.п. Оторвут с обоими руками...
;) Между тем описанное мной решение реализуется буквально за несколько часов и спокойно работает. Нет, если речь идет о сайтах уровня lj.ru или vk.com - то да, там все ваши страшные слова нужны. А если речь идет просто о сайте небольшой компании, которая не хочет зависеть от одного хостера - то тут специалист "сильно от 80к" просто не нужен
и что теперь? Не предлагать? По крайней мере человек будет знать, в какую сторону смотреть
И насчет днс - вы не правы. Если хост резолвится в несколько адресов и часть адресов недоступна - то броузер будет перебирать адреса дальше, пока не соединится. Проверено на опыте, так не только броузеры себя ведут. Я в свое время так PPTP VPN сервера резервировал.
не совсем. Мы получаем одну точку отказа. Что будет, если откажет вот этот третий сервер? Правильно, вся связка перестанет работать. В моем 1-м варианте оба сервера равноправны. И сайт будет недоступен только в случае отказа одновременно обоих хостеров.
Если уж мы ставим балансировщик - его тоже надо резервировать ;) И мы все равно приходим к моему варианту, усложненному тем, что кроме рабочих серверов мы зарезервировали еще и балансировщики...
Тогда уж стоит идти в сторону облаков...
тогда еще проще.
включаем роутер в сеть lan портом, wan вообще не задействуем. Отключаем на роутере dhcp сервер, настраиваем wifi так, как вам удобно.
После этого ваш ноут подключается к вифи, и сразу попадает в вашу локальную сеть. Никаких натов и пробросов портов настраивать не надо.
--skip-grant-tables в параметрах запуска - вообще он у вас запущен в режиме игнорирования прав доступа. Обычно это используется в том случае, если забыли рутовый пароль. Стандартная процедура такова: остановить сервер, добавить параметр, запустить сервер, зайти под рутом, сервер не будет спрашивать пароль, установить пароль рута, остановить сервер, убрать параметр, запустить сервер в штатном режиме.
Вот я бы вам рекомендовал назначить пароль пользователя root:
mysql -u root -p
mysql> use mysql;
mysql> update user set password=PASSWORD("newpass") where User='root';
mysql> flush privileges;
mysql> quit
Это установит одинаковый пароль рута для всех хостов, которые описаны в параметрах доступа
Потом остановите сервер, уберите параметр --skip-grant-tables из строки запуска и запустите в штатный режим. И попробуйте подключиться.
пока без понятия ;) я вообще проверял с днс серверов на Украине и в Германии - оба не знают ип вашего домена. Так что всетаки проверьте все. Вы правильные ns сервера указали? Домен не обслуживается на ns серверах reg.ru?
Руслан Федосеев
@martin74ua Автор вопроса, куратор тега Linux
Да, я правил текст вопроса. Возможно не все видят, поэтому сдублирую
PS. Прошу прощения, разобрались в чем проблема. Связи между dhcp v4 и multicast нет никакой.
При написании ACL ошиблись, и вместо
deny ip any 224.0.0.0 15.255.255.255
написали
deny ip any 224.0.0.0 31.255.255.255
Т.е. забанили сеть 224.0.0.0/3, в которую входит 255.255.255.255
Так что мы сами себе злобные буратины.
Картина мира восстановлена, прошу прощения за отнятое время.
