Согласен, частный случай, когда сайт пытается получить удаленный ресурс и упирается в скорость этого ресурса или в сетевой таймаут, выходит за рамки статьи.
В этом случай сперва придется поработать с ltrace или strace.
Блокировать так же стоит с умом) если будет ожидание по сетевому таймауту то ничем хорошим это не закончится.
Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
Вариантов множество, но тут вопрос немного о другом.
Постараюсь написать об этом в будущих статьях. По вопросам хостинга, можем обсудить в skype. Мы не конкурируем с хостинговыми компаниями. Хостинг под конкретные проекты, которые беремся ускорять.
Прочитал как роман. У Вас отлично получается передавать события. Даже столь техническая тема, раскрыта вами и прочитана мною с огромным удовольствием. Спасибо Вам большое.
READ COMMITTED Нечто похожее на уровень изоляции Oracle. Все выражения SELECT… FOR UPDATE и SELECT… LOCK IN SHARE MODE блокируют только индексные записи и не блокируют интервал перед ними. Поэтому они позволяют свободно добавлять новые записи после заблокированных. UPDATE и DELETE, которые используют уникальный индекс и уникальные условия поиска, блокируют только найденную индексную запись, и не блокируют интервал перед ней. Но в UPDATE и DELETE диапазонного типа в InnoDB должны установить блокировку следующего ключа или интервальную блокировку и блокировать добавления другими пользователями в интервал, покрытый диапазоном. Это необходимо, т.к. «фантомные строки» должны быть блокированы для успешной работы репликации и восстановления в MySQL. Согласованное чтение работает как и в Oracle: каждое согласованное чтение, даже внутри одной транзакции, устанавливает и читает свой собственный снимок.
Арбиттратор это служба galera без mysql )
те она просто поддерживает кворум, следит за порядком коммитов и составом участников. равнозначный член кластера без данных.
я не буду указывать число нод в кворуме. Он будет выбирать это самостоятельно. Почему кластер должен развалится пополам? Если будет 4 ноды и они развалятся пополам, то будет 2 ноды по 2. Как вы сами и сказали, оба этих кластера не будут жизнеспособными.
Я бы еще согласился если бы нод было 5,6 или более.
splitbrain возможен когда ноды теряют согласование транзакций, так как они не знаю какая имеет верное состояние в данных момент. Это возможно, лишь когда нод 2. Все что выше, за счет других нод или арбитратторов, это кворум и splitbrain не может быть. Хоть четное их чесло, хоть нет. Речь ведь о Galera?
В этом случай сперва придется поработать с ltrace или strace.
Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
Вариантов множество, но тут вопрос немного о другом.
те она просто поддерживает кворум, следит за порядком коммитов и составом участников. равнозначный член кластера без данных.
Я бы еще согласился если бы нод было 5,6 или более.