Давно с MySQL NDB Cluster еще 5.x игрался, поэтому могут быть не свежие или ошибочные воспоминания.
>как я понял, надо например четыре ноды (две data, одна sql, одна mgm), данные таблиц лежат на data-нодах, а сама database где, на sql? то есть на sql мы определяем database, а для каждой таблицы делаем engine = ndbcluster. Если мы собираем минимальный то надо три хоста. Два mysql и они же data и один mgm (там тулза тупо смотрит кто упал), он выступает куратором, к ресурсам не трудоёмкое вообще.
>и тогда если кто-то забудет указать engine = ndbcluster, то что таблица в кластер не попадает? Да. Она не будет реплицироватся на ноды кластера. Надо ещё учесть, что этот engine имеет свои особенности и отличия от InnoDB. Например она in-memory. Это надо учесть.
>что будет, если упадет одна из нод data примерно понятно, а что если упадёт сервер с mgm нодой? короче, отказоустойчивость не совсем понятна. В случае с тремя хостами. Две базы и один куратор. Одна из data node является активной, все остальные являются пассивными. Куратор занимается тем, что мониторит все хосты, и в случае падения активной ака мастер ноды, передаёт её роль на другие пасивные. Поэтому в случай падения куратора, у нас всё работает. Только в случай падения мастер ноды, роль не переключится на пассивные ноды. Поэтому схема из трех нод, спокойно работает при отказе одного любого хоста. Или двух хостов только в одном случае, если отказывает пассивная нода и куратор.
Использовал подобную тему в трех нодной конфигурации. Где у меня было 90% таблиц только для чтения, и они оставались в InnoDB. И было ещё несколько таблиц которые изменялись активно. Их только и перевели в ndb cluster и они синхронизировались. В принципе все ок работало..
соответственно, если у нас БД вырастает больше RAM одной из нод, то мы начинаем выбирать, какие таблицы мы будем хранить, а с какими мы потенциально будем развлекаться в случае краха того хоста, на котором они лежат. а у этих таблиц (которые в RAM и которые на диске одной из нод) могут быть ключи перекрестные... это я размышляю вслух. что-то не весело получается, учитывая размеры БД и объем RAM - её пускай и 48гиг, но она не растет, а БД очень даже.
Просто не знаю тонкостей, но имеет ли вообще смысл применять тут кластер на основе mysql ndb cluster. Если есть три ноды. То процесс более без болезненный это сделать мастер и два слейва, и уже распределять запросы на изменения к мастеру, а чтение рулить на слейв и один из них и бэкапить. Или как написано ниже, можно посмотреть в сторону групповых репликаций.
прихожу к мнению, что надо оставить так же, как есть сейчас (master-slave репликация). получается, что со времен mysql 4.0 легче удобнее и надежнее не стало.
>как я понял, надо например четыре ноды (две data, одна sql, одна mgm), данные таблиц лежат на data-нодах, а сама database где, на sql? то есть на sql мы определяем database, а для каждой таблицы делаем engine = ndbcluster.
Если мы собираем минимальный то надо три хоста. Два mysql и они же data и один mgm (там тулза тупо смотрит кто упал), он выступает куратором, к ресурсам не трудоёмкое вообще.
>и тогда если кто-то забудет указать engine = ndbcluster, то что таблица в кластер не попадает?
Да. Она не будет реплицироватся на ноды кластера. Надо ещё учесть, что этот engine имеет свои особенности и отличия от InnoDB. Например она in-memory. Это надо учесть.
>что будет, если упадет одна из нод data примерно понятно, а что если упадёт сервер с mgm нодой? короче, отказоустойчивость не совсем понятна.
В случае с тремя хостами. Две базы и один куратор.
Одна из data node является активной, все остальные являются пассивными. Куратор занимается тем, что мониторит все хосты, и в случае падения активной ака мастер ноды, передаёт её роль на другие пасивные. Поэтому в случай падения куратора, у нас всё работает. Только в случай падения мастер ноды, роль не переключится на пассивные ноды.
Поэтому схема из трех нод, спокойно работает при отказе одного любого хоста. Или двух хостов только в одном случае, если отказывает пассивная нода и куратор.
Использовал подобную тему в трех нодной конфигурации. Где у меня было 90% таблиц только для чтения, и они оставались в InnoDB. И было ещё несколько таблиц которые изменялись активно. Их только и перевели в ndb cluster и они синхронизировались. В принципе все ок работало..
Reply
Reply
Если есть три ноды. То процесс более без болезненный это сделать мастер и два слейва, и уже распределять запросы на изменения к мастеру, а чтение рулить на слейв и один из них и бэкапить. Или как написано ниже, можно посмотреть в сторону групповых репликаций.
Reply
получается, что со времен mysql 4.0 легче удобнее и надежнее не стало.
Reply
Leave a comment