LINUX.ORG.RU
ФорумAdmin

master-master и fault recovery

 fault recovery, ,


0

1

Собственно вопрос такой. Допустим есть какая-нибудь MariaDB с настроенной master-master репликацией. Везде и всюду масса хаутушек как чего и куда на предмет поднятия и всего такого. Но всё это резко заканчивается на том моменте где «а вот мы выключаем одну из машин и база всё равно доступна». Тем не менее, самый интересный вопрос - а как же предполагается возвращать сдохшую тачку после ремонта в строй вообще никак и нигде не освещён, или упомянут очень мутно и весьма неопределённо. Только не говорите мне, что нужно таки остановить базу (собственно маразм же - ведь всё затевается как раз чтобы больше никогда не пришлось останавливать базу) и заново вот это всё дрочево с позицией бинлога и всё такое.

Другой вариант - drbd например. Ну умолчим, что эти гандоны так и не приняли в апстрим Protocol D, и master-master там через жоппу, но тем не менее. Вопрос тот же - fault recovery там опять ручками и с бубном?

В общем вопрос такой - Есть SQL БД. Нужно как-то организовать master-master репликацию или там распределённое хранилище (опять же master-master, чтобы не париться с переключением выжившего slave в master) чтобы fault recovery либо поддавался автоматизации, либо происходил без лишних телодвижений при возвращении умершей тачки в строй. Доступность базы с 2-х машин одновременно не нужна. Ну как hardware raid 1 - прям на ходу вынул сдохший диск, вставил новый и вообще не паришся ни о чём. вот хочу то же самое, только с машинами целиком. Сдохла тачка, монтажник подключает новую (можно с заранее установленной идентичной системой, для простоты) - и всё само восстанавливается без лишних телодвижений и остановки БД.

Есть чо?

★★★★★

Последнее исправление: Stanson (всего исправлений: 2)

fault recovery либо поддавался автоматизации

плохая идея

Доступность базы с 2-х машин одновременно не нужна

Зачем тебе тогда master-master?

generator ★★★
()
Ответ на: комментарий от generator

плохая идея

Чем она плохая? RAID 1 это делает на ура без бубна и геморроя. Вынул-вставил, в самом прямом смысле. Чем другие варианты зеркалирования-репликации хуже и почему они внезапно должны быть геморройными в момент fault recovery?

Зачем тебе тогда master-master?

Чтобы машины равноценны были и в произвольный момент можно было перевести полноценную работу с базой на другую машину без лишних телодвижений и колдунства.

В общем, требуется отсутствие single point of failure, чем страдают почти все варианты кластеризации. Поэтому master-master весьма желателен.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

RAID 1 это делает на ура без бубна и геморроя

Ну так и возьми RAID, в чём проблема?

Чтобы машины равноценны были и в произвольный момент можно было перевести полноценную работу с базой на другую машину без лишних телодвижений и колдунства.

Тогда тебе нужна репликация по сети. glusterfs, например, как я понимаю.

generator ★★★
()

Master-master нужен для балансировки пишущей нагрузки, а не для fault recovery. Для fault recovery достаточно синхронного standby.

anonymous
()

Новая нода в Галере (ведь мастер мастер в Машке только так делается) поднимается абсолютно автоматически безо всякой остановки других нод - откуда этот бред про остановку активной ноды? И бинлоги там никакие не используются.

blind_oracle ★★★★★
()

А с DRBD SQL лучше вообще не пытаться скрестить - даже учитывая то, что база выживет (InnoDB) - восстанавливаться при перезапуске на второй ноде оно будет очень долго при наличии большого кол-ва транзакций в логе.

blind_oracle ★★★★★
()
Ответ на: комментарий от generator

Ну так и возьми RAID, в чём проблема?

Сдыхает например не диск, а БП или материнка. И толку от RAID? Поэтому нужно 2 машины.

Тогда тебе нужна репликация по сети. glusterfs, например, как я понимаю.

Ну например да. Где можно почитать о последовательности действий когда сдохла одна нода, была заменена и её нужно вернуть в строй? Не о том, как установить с нуля и не о том, как замечательно всё сохраняется при сдыхании ноды, а о том, как именно восстановить сдохшую ноду.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Для fault recovery достаточно синхронного standby.

Хорошо. Какова последовательность действий для полноценного возвращения отказавшей ноды? И заодно, какова последовательность действий при отказе ноды?

Второй вопрос при master-master решается например просто поднятием алиаса с ИП умершей ноды на интерфейсе. Всё. Что нужно делать при твоём варианте?

ЗЫ: fault recovery != fault tolerance

Stanson ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Новая нода в Галере (ведь мастер мастер в Машке только так делается)

Нет, галера не подходит, ибо минимальное количество нод должно быть 1. И все ноды должны быть абсолютно равноценны. В галере минимальное количество нод - 3. И мастер-мастер не только галерой можно.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

А с DRBD SQL лучше вообще не пытаться скрестить - даже учитывая то, что база выживет (InnoDB) - восстанавливаться при перезапуске на второй ноде оно будет очень долго при наличии большого кол-ва транзакций в логе.

Да, это одна из проблем, если использовать репликацию на уровне ФС и ниже без репликации самого процесса DB (как в xen + remus).

Stanson ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Новая нода в Галере поднимается абсолютно автоматически безо всякой остановки других нод

Это, кстати, если SST посредством xtrabackup делается. В остальных случаях какая-то нода будет заблокирована READ LOCK на время трансфера.

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Нет, галера не подходит, ибо минимальное количество нод должно быть 1

Никто не мешает.

И все ноды должны быть абсолютно равноценны.

Они в Галере абсолютно равноценны

В галере минимальное количество нод - 3

С чего бы это? Просто это минимально адекватное количество чтобы избежать сплит-брейна. Ты можешь указать вес одной из нод выше стандартного, тогда при отключении 1 ноды из 2 другая не уйдёт в защитный режим. Можно сделать 2 ноды данных + 1 нода арбитр.

Не бывает хорошего мультимастера без кворума, вне зависимости от типа кластеризации.

И мастер-мастер не только галерой можно.

Нормальный - только галерой. Или ты имеешь в виду MySQL Cluster? Это своеобразная поделка с in-memory работой. Или ты про бинлоги перекрёстно? Это вообще ужос.

blind_oracle ★★★★★
()
Ответ на: комментарий от Stanson

Это, кстати, если SST посредством xtrabackup делается.

Ну так кто ж мешает то его использовать? Всякие rsync не особо актуальны.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Нормальный - только галерой. Или ты имеешь в виду MySQL Cluster? Это своеобразная поделка с in-memory работой. Или ты про бинлоги перекрёстно? Это вообще ужос.

У галеры оказались некоторые косячищи в общем-то. Нумер раз - только InnoDB, которая не сильно годится для хранения миллионов говен, типа логов и пр. объёмистого хлама с полнотекстовым поиском и преимущественным чтением. Нумер два - в таблице обязательно должен быть primary index. Нумер три - не гарантируется последовательность autoincrement, что в общем-то нестрашно, но печально.

MySQL Cluster сам по себе хренов тем, что есть single point of failure - «головная» машина.

Бинлоги перекрёстно - оно даже работает, но косяки там ещё более весёлые, а возвращение тачки в строй - ещё те пляски с бубном.

В принципе, если от MyISAM избавлюсь и что-нибудь придумаю с выборами primary в 2-хмашинной конфигурации (ну или третью тачку поставлю, в конце-концов, хотя не хотелось бы), то для меня в общем-то галера как-то подойдёт. Но как универсальное решение в целях fault tolerance & high availability в отличие от xen+remus+drbd-protoD совсем не годится, ибо решает проблему только БД. Эх если бы не упорыши пишушие drbd....

Stanson ★★★★★
() автор топика
Ответ на: комментарий от Stanson

Нумер раз - только InnoDB, которая не сильно годится для хранения миллионов говен, типа логов и пр. объёмистого хлама с полнотекстовым поиском и преимущественным чтением.

Нормально совершенно хранит. Сам пользую базу с десятком-другим таблиц, в которых по 20+ миллионов записей в каждой, причём большая часть из них часто обновляемы. Полнотекстовый поиск - да, нету, но никто не мешает снаружи прикрутить Сфинкс и юзать его плугин к MySQL если надо.

Нумер два - в таблице обязательно должен быть primary index.

Ну, это в общем признак хорошего дизайна. Даже если ты не сделаешь явного PK, то InnoDB сделает скрытый за тебя.

MySQL Cluster сам по себе хренов тем, что есть single point of failure - «головная» машина.

Там нет SPOF, ты что-то не так понял про его архитектуру. Но вот вся его эта in-memory сущность меня напрягает.

blind_oracle ★★★★★
()

Берешь Pacemaker, дисковый массив(если данные сверхважные, то 2 каскадом, ибо настоящие гуру считают массив SPOF, не смотря на резервирование блоков питания и контроллеров), LVM, аттачишь раздел с массива по FC, дальше всё скучно, сам разберёшься.

zolden ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.