Что значит где почитать? Что по Вашему такое splitbrain и почему он происходит?
Попробую найти где-нить строки хоть в чей-нибудь документации… Где-то явно оно есть.
Тут указано про минимум 3 сервера, но они явно упустили момент с чётным числом узлов.
не стоит… Лучше, это когда число голосов (ноды+арбитраторы) нечётное, иначе splitbrain более вероятен. Хотя это зависит от конкретной схемы включения, тем не менее нечётное число всегда предпочтительней.
По моим изысканиям всё упирается в RTT. Т.к. на каждый запрос(или коммит, точно не скажу) происходит согласование со всеми остальными мастерами, и когда они дадут согласие, тогда только сервер получивший запрос начнёт его выполнять. Посему маленький запрос на INSERT может вместо пары микросекунд выполняться до 200милисекунд из-за того что согласование произошло между серверами стоящими в России и Америке, например.
А ещё всё это становится более шатким, если Вы хотите как я иметь 5,6,7… мастеров.
Каковы потери производительности, которые уходят на согласование запроса со всеми мастерами(режим-то синхронный)? Желательно в процентах и в секундах.
Соединены ли у Вас мастера в рамках ЛВС или через Интернет?
Т.е. если Master упал по причине того что на ДЦ упал метеорит, то ни какая автоматика не включит Slave в работу? Нужно ручное вмешательство?
База потом сама восстанавливается из лога транзакций при включении
А где гарантия что лог-транзакций консистентен? И дело даже не в наличии лога и его целостности а в том что, что commit в базу не означает что данные дошли до физического диска и миновали в т.ч. его кэш.
Про базу понял. Я думал мы на другом уровне работаем (внутри VM).
Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?
Вообще-то, если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь. Разве что у нас везде работает Direct-IO и мы не встрянем в такую ситуацию.
Ни слова про репликацию БД и про кластеризацию роли Master'а, с переездом или в MM режиме. А ведь база есть практически у всех. Так же не видел описания того работает ли DRBD в MM режиме или переключение мастера чем-то управляется.
Почему в DRBD взяли Protocol B, а не C?
Если речь идёт о курсоре, которым можно что либо выделить, то речь идёт либо о перемещении манипулятора типа «мышь»/TrackPoint/TouchPad, либо комбинации клавиш для перемещения курсора в мультиплексоре, например screen. Но в случае мультиплексора работы нужно совершить ещё больше.
А уж нажатие стрелки вверх на клавиатуре для гулянья по истории, уж ни как не входит в манипуляцию курсором.
Попробую найти где-нить строки хоть в чей-нибудь документации… Где-то явно оно есть.
Тут указано про минимум 3 сервера, но они явно упустили момент с чётным числом узлов.
А ещё всё это становится более шатким, если Вы хотите как я иметь 5,6,7… мастеров.
Соединены ли у Вас мастера в рамках ЛВС или через Интернет?
А где гарантия что лог-транзакций консистентен? И дело даже не в наличии лога и его целостности а в том что, что commit в базу не означает что данные дошли до физического диска и миновали в т.ч. его кэш.
Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?
Вообще-то, если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь. Разве что у нас везде работает Direct-IO и мы не встрянем в такую ситуацию.
Почему в DRBD взяли Protocol B, а не C?
А уж нажатие стрелки вверх на клавиатуре для гулянья по истории, уж ни как не входит в манипуляцию курсором.
> Я обычно курсором повторяю предыдущую команду
> А зачем мышь?
Не находите противоречий?
А вообще если не следишь за тем, что пишешь то ССЗБ. И не важно на "!!" ты нарвёшься или ещё на какой функционал.