Я понимаю, что это «Блог компании Infobox» и всё такое, но про StartSSL уже писано не мало статей, а уж как установить сертификат в конкретное ПО и подавно. Может вы будете постить достойную и интересную техническую информацию о реализованных вещах, а не использовать Хабр как свою базу знаний(в ней я, кстати, данной статьи не наблюдаю)?
Если число голосующих узлов будет нечётным, то не будет ситуации когда кластер развалится на две ЛЮБЫЕ части и при этом перестанет функционировать. И нету ни какой разницы произойдёт это при 2,4 или 6 узлах. Суть проблемы не меняется.
Если Вы считаете что конкретно Ваша инсталяция в силу расположения или схемы включения не способна развалиться на 2 половины, то наш разговор я считаю без полезным. Всё остальное я уже описал выше.
Речь о любом кластерном решении и Galera не исключение. Если у Вас будет кластер из 4-х нод, то в качестве необходимого для кворума, сколько нод Вы укажите? А теперь предположим что кластер развалился пополам. Если в качестве кворума было указано:
2 ноды — то каждая половина решит что она главная и будет существовать независимо. Вот и коллизия данных.
3 ноды — кластер просто перестанет существовать, т.к. каждая половина решит что её мало.
Что значит где почитать? Что по Вашему такое 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. Но в случае мультиплексора работы нужно совершить ещё больше.
А уж нажатие стрелки вверх на клавиатуре для гулянья по истории, уж ни как не входит в манипуляцию курсором.
Если Вы считаете что конкретно Ваша инсталяция в силу расположения или схемы включения не способна развалиться на 2 половины, то наш разговор я считаю без полезным. Всё остальное я уже описал выше.
2 ноды — то каждая половина решит что она главная и будет существовать независимо. Вот и коллизия данных.
3 ноды — кластер просто перестанет существовать, т.к. каждая половина решит что её мало.
Вот у percona есть про это, нашёл.
Попробую найти где-нить строки хоть в чей-нибудь документации… Где-то явно оно есть.
Тут указано про минимум 3 сервера, но они явно упустили момент с чётным числом узлов.
А ещё всё это становится более шатким, если Вы хотите как я иметь 5,6,7… мастеров.
Соединены ли у Вас мастера в рамках ЛВС или через Интернет?
А где гарантия что лог-транзакций консистентен? И дело даже не в наличии лога и его целостности а в том что, что commit в базу не означает что данные дошли до физического диска и миновали в т.ч. его кэш.
Чем происходит переключение режимов работы DRBD? Что за софт принимает решения?
Вообще-то, если рухнет питание на master'е и часть записей MySQL окажется в кэше виртуалки, то мы на Slave'е, который станет Master'ом через несколько секунд, получим капусту вместо данных и далеко не факт, что mysql repair сможет нам помочь. Разве что у нас везде работает Direct-IO и мы не встрянем в такую ситуацию.
Почему в DRBD взяли Protocol B, а не C?
А уж нажатие стрелки вверх на клавиатуре для гулянья по истории, уж ни как не входит в манипуляцию курсором.
> Я обычно курсором повторяю предыдущую команду
> А зачем мышь?
Не находите противоречий?