|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте!
Прочитал много статей по этому поводу. Каша, если честно. Нужно построить MySQL кластер, объединяющий в себе как балансировку нагрузки, так и высокую доступность.
На www.mysql.ru/docs/man/Replication_FAQ.html писали:
"В настоящее время мы работаем над интеграцией системы автоматического выбора головного сервера в MySQL, но пока эта функция не будет готова, придется создавать собственные средства контроля."
Это про репликацию. Все бы ни чего, но когда упадет мастер, надо что бы автоматически выбирался новый без вмешательства из вне. А после подъема мастера, тот либо остается репликой, либо после репликации переходит в мастер, а та реплика на свое место.
Кто может поделиться решением или предложить что нибудь?
www.opennet.ru/base/net/mysql_cluster_2.txt.html (мне так проще объяснить будет)
В случае построение кластера, как я понял данные между mysql-ndb-1 и mysql-ndb-2 реплицируются, а то есть делают балансировку нагрузки и высокую доступность?
Не понял зачем тут этот сервер mysql-api-1?
Все бы ни чего, но, как я понял, если падает сервер и консоль управления на mgmt, то падает весь кластер?
Как можно этот сервер и консоль управления на mgmt перевести в высокую доступность?
В смысле нужно добавить еще один сервер и реплицировать данные между ними? Как это реализовать, подскажите.....
З.Ы: Извиняюсь, если что не так, заранее. Спасибо за понимание. Жду ответов...
Отредактированно borodatych (14.07.2010 15:39:11)
Неактивен
Готового хорошего решения автоматического переключения мастера нету.
Можно переключать вручную по мере необходимости.
HA и балансировка — это разные вещи. Даже если у Вас есть две SQL-ноды,
то HA — это возможность одной из них упасть. А балансировка — это свойство
клиентской среды уметь начать посылать запросы на другую SQL-ноду.
mgmt-нода не нужна во время работы кластера. Она служит как tie-breaker
в случае полного рабочего кластера. Ну и любая SQL-нода может выполнять
ее функции (в отсутствие живой mgmt).
Неактивен
1. Вы писали готового хорошего. Мне бы любое посмотреть. Как за основу что бы взять. Как у вас это реализовано?
2. То что HA и LB - разные вещи знаю, но все равно спасибо за ответ. Очень разумно с вашей стороны, учитывая не четкость моих вопросов. Из-за невнимательности прочитанной статьи, извиняюсь, я предположил что кластер сразу и HA и LB. Там же по русски в начале написано:"Кластерное решение на базе MySQL является отказоустойчивым, избыточным и масштабируемым решением для баз данных".
Как я понял из статьи:
1. В определенный момент времени работает только один из mysql-ndb серверов.
2. mysql-api выступает как tie-breaker.
3. mgmt выступает как сервер и консоль управления, а так же в случае падения mysql-api и tie-breaker.
Если не прав поправьте. Могу недопонимать сути.
Так как у нас сервера mysql-ndb-1 и mysql-ndb-2 хоть и реплицируется/синхронизируются между собой (не знаю как правильно выразиться) и в определенный момент времени работает только один из mysql-ndb серверов, то тогда что нам мешает его реплицировать?
Как это будет работать? И зачем нам mysql-api и mgmt как два разных сервера, нельзя ли их объединить в один?
З.Ы: Извиняюсь, если что не так, заранее. Спасибо за понимание. Жду ответов...
Неактивен
Реализовано ручным переключением мастера, если этот падает 
1. неверно, работают оба ndb (иначе как бы Вы записывали данные синхронно?).
Более того, если нод у Вас большее количество, то и данные Вы можете при SELECT
получать одновременно с нескольких датанод.
2. да, если нет живой mgm-ноды
3. mgm нода по умолчанию имеет приоритет выше, чем sql-нода, а не ниже, как
Вы описываете.
Что касается количества машинок — это всё делается для того, чтобы не было ситуа-
ции split brain. Представьте, что у Вас только две машинки — как должна вести себя
каждая из них, если другая недоступна? Моргнула сеть? У нее или у меня? Может,
другая умерла? В случае 3 машинок в кластере — на эти вопросы можно получить
ответы. В случае 2 — нет.
Неактивен
Значит, возможно грубо, MySQL кластер можно сравнить с RAID1 массивом?
Тогда в принципе, исходя из специфике RAID1 - обеспечивает приемлемую скорость записи и выигрыш по скорости чтения при распараллеливании запросов, можно сказать, что MySQL кластер с одной стороны балансирует нагрузку, как в ситуации с репликами, с другой стороны является отказоустойчивым?
Спасибо за терпение. Жду ответов...
Неактивен
Ну, какая-то аналогия есть, а при увеличении количества нод — с raid10
Неактивен
Зная что у меня не будет многоэтажных джоинов, что лучше использовать MySQL репликацию или MySQL кластер?
В чем преимущество и недостатки обоих вариантов, может кто сравнивал или просто знает?
Неактивен
Лучше использовать то, что Вам нужно. Более того, одно другое не исключает
Неактивен
Спасибо огромное за ответы.
Вы как психолог: "Лучше использовать то, что Вам нужно"
Не поймите не правильно, просто улыбнуло.
Это как: "Нужно сделать так как Вы думаете будет правильно, что Вам сердце подсказывает"
Был бы хайд, можно было и под него.
Еще вопросик....
Какие +/- в том или ином подходе?
К примеру...
MySQL кластер:
- Плохо работает с многоэтажными джоинтами
+ При падение одного сервера, роль управление переходит на другой
MySQL репликация:
- При падение мастера, не реализован выбор другого мастера из существующих реплик.
+ Простота реализации
З.Ы: Извиняюсь за сравнение. Не в упрек. От души)
Отредактированно borodatych (16.07.2010 09:32:07)
Неактивен
Хм. Ну это правда разные вещи.
Кластер. Синхронное обновление данных на всех нодах. Одна сущность с
несколькими (обычно) точками входа. Хранится в памяти. Хорошо справля-
ется с точечными запросами (например, достать данные по главному ключу),
отвратительно справляется с более сложными запросами, т.к. требует пере-
кидывать цельные таблицы по сети с ноды data на ноду sql.
Репликация. Асинхронное обновление. Несколько сущностей. Могут быть
из-за асинхронности разнесены, например, в разные датацентры. Справляется
с запросами так, как справляется конкретный элемент репликации (т.е. если
это один демон, то как один демон, а если это кластер, то см. выше).
Ни то, ни другое не обеспечивает балансировки нагрузки без дополнительных
усилий. Кластер обладает повышенной устойчивостью к падению отдельных
нод при должной настройке.
Неактивен
Кластер.
Хранится в оперативке, на сколько я помню, часть данных. Плюс - скорость. Минус - в случае сбоя потери той части которая была в оперативке. Что Вы подразумеваете под словом сложный запрос? Такой запрос как при SQL-injection? Или для кластера 2-3 джоинта - это уже сложный запрос?
Репликация.
Очень хороша из-за гибкости. Тут сложно реализовать HA.
Что означает справляется с запросами так, как справляется конкретный элемент репликации? Если возможно, по подробней...
Почему же? У обоих случаев основная идея идет в балансировки нагрузки?
Что Вы подразумеваете под дополнительными усилиями?
Что мы имеем....
MySQL кластер:
+ Синхронное обновление (сопоставимо с RAID1 в простом варианте)
+ При падение одного сервера, роль управление переходит на другой
+ Хранит данные в оперативки, что обеспечивает высокую скорость
- Из того что хранит данные в оперативки, есть шанс потерять ту часть, которая в оперативке
- Плохо работает с многоэтажными джоинтами
- Ресурсоемкое решение (для нормальной работа минимум необходимо 3-и узла, лучше 4-е)
MySQL репликация:
+ Простота реализации
+ Гибкость, можно реплицировать отдельные таблицы, хоть столбцы (как я понял)
+ Для реализации достаточно 2-х узлов
- При падение мастера, не реализован выбор другого мастера самостоятельно из существующих реплик
- Из-за асинхронного обновление, актуальность реплик отстает (что если реплики не обновились, а мастер умер)
Хочется до конца добить эту тему...
Отредактированно borodatych (16.07.2010 15:42:37)
Неактивен
Основная идея кластера - совокупность машинок, которая может продолжать обслуживать клиентов ари выпадении любой из них. Основная идея репликации - передавать данные с одного сервера на другой. Нужна HA? Вам кластер. Нужно передать даные? Вам репликацию.
Неактивен
Мне в итоге надо получить кластер HA+LB
Такая схема может быть реализована?
[mgmt]----[api-nod]---------[storage-nod1(master)]----------[storage-nod1(slave)]
| | |
| | `-----[storage-nod1(slave)]
[storage-nod2(master)]------'
| |
[storage-nod2(slave)] [storage-nod2(slave)]
Извините за "тупизм" конечно же, но:
www.mysql.ru/docs/man/Replication_Intro.html
В первом абзаце четко сказано, что
"К числу преимуществ, которые обеспечивает репликация, относится повышение скорости и надежности. Чтобы обеспечить надежность, можно установить две системы и при возникновении проблем с головным сервером переключаться на резервную копию. Для увеличения скорости можно перенаправлять те запросы, которые не обновляют данные, на сервер с копиями. Разумеется, это даст эффект лишь в том случае, если запросы, не обновляющие данные, преобладают, но, как правило, чаще всего так и бывает."
www.opennet.ru/base/net/mysql_cluster_2.txt.html
Тут в самом начале:
"Кластерное решение на базе MySQL является отказоустойчивым, избыточным и масштабируемым решением для баз данных, основанным на открытых исходных текстах."
То есть:
Репликация больше подходит для LB, но можно реализовать и HA, хотя бы через костыль
Кластер больше подходит для HA, но можно реализовать LB, путем распределения запросов
З.Ы: Спасибо за понимание. Жду ответов...
Отредактированно borodatych (17.07.2010 12:42:52)
Неактивен
Хм. Попробую еще раз. У Вас есть зубы. Вы умеете грызть яблоко. За один раз
вы можете грызть не больше одного яблока. Вот LB — это механизм предоставле-
ния Вам одного из нескольких яблок так, чтобы они все были отъедены прибли-
зительно одинаково. Этого механизма нет ни в кластерной корзине яблок, ни в
репликационной.
Репликационная корзина: вы подкрашиваете яблоко красным — и другое яблоко
тоже становится красным.
Кластерная корзина: вы одновременно подкрашиваете все яблоки красным.
--
Касательно картинки — в кластере нет мастеров и реплик, там есть датаноды.
Данные делятся между ними автоматически. Вы можете влиять лишь на общее
количество копий данных внутри всего кластера.
--
P.S. Мы не несем ответственности за то, что написано на mysql.ru. Более того,
есть только один правильный источник информации о MySQL — mysql.com. Но
за информацию, размещенную там, мы тоже, кстати, ответственности не несем
Неактивен
Согласен что практика расходится с теорией.
Все русскоязычные сайты, которые я, да и не только по ходу дело, прочел под LB понимают репликацию, не уж то все заблуждаются?
Мне тяжко дается буржуйский, если в этом есть реализация LB+HA, не расходящаяся с практикой, то я прочту конечно же!
Вот линк: www.howtoforge.com/loadbalanced_mysql_cluster_debian
Гляньте "краем глаза" тут все нормально? Тут LB+HA?
Или, по возможности, если не под грифом секретно, то приведите/пните на свой ресурс, где можно освоить данный материал!
А то что я понял из русскоязычных ресурсов, дак это:
Репликация больше подходит для LB, но можно реализовать и HA, хотя бы через костыль
Кластер больше подходит для HA, но можно реализовать LB, путем распределения запросов
И....
MySQL кластер:
+ Синхронное обновление (сопоставимо с RAID1 в простом варианте)
+ При падение одного сервера, роль управление переходит на другой
+ Хранит данные в оперативки, что обеспечивает высокую скорость
- Из того что хранит данные в оперативки, есть шанс потерять ту часть, которая в оперативке
- Плохо работает с многоэтажными джоинтами
- Ресурсоемкое решение (для нормальной работа минимум необходимо 3-и узла, лучше 4-е)
MySQL репликация:
+ Простота реализации
+ Гибкость, можно реплицировать отдельные таблицы, хоть столбцы (как я понял)
+ Для реализации достаточно 2-х узлов
- При падение мастера, не реализован выбор другого мастера самостоятельно из существующих реплик
- Из-за асинхронного обновление, актуальность реплик отстает (что если реплики не обновились, а мастер умер)
Это стереть из памяти, дабы не засорять и от того опухший мозг?
p.s: Про яблоки конечно смешно получилось. Я конечно не гуру, но и не настолько туг!
p.p.s: Один-Один)))))) (Это про яблоки и психолога
)
Отредактированно borodatych (19.07.2010 12:04:33)
Неактивен
Все сайты пишут, что LB можно сделать на базе репликации. Это означает, что готового
решения нету, но, используя репликацию, можно достаточно просто написать приложение,
которое делало бы балансировку своими силами.
Да, статья хорошая, балансировка там делается через IPVS. Жаль, что разбита на страницы, —
читать не очень удобно. Но идеи там правильные. Именно так и делают кластеры.
Неактивен
К минусам MySQL кластера стоит добавить и кол-во оперативной памяти, необходимой для работы:
- На 1Gb базы - 1.1Gb оперативной памяти
Ладно с кластерами все ясно, спасибо за ответы...
Можно ваш примерчик приложения или ваши линки на материал реализации LB на базе репликации?
Отредактированно borodatych (19.07.2010 15:22:24)
Неактивен
Эм. Мы такое не публиковали. А чем Вам не понравилась статья с IPVS? Делаете
репликацию, делаете IPVS над репликами, ходите на чтение в получившийся
балансер над репликами и на запись в мастер (да, тут, в отличие от кластера,
нужно все равно делать балансировку внутри приложения — правда всего между
двумя соединениями и по очень простым правилам выбора).
Неактивен
Насколько я понял IPVS - это модуль ядра?!
Кстати сейчас поддерживается две виртуальных машины на одной физической?
(Раньше надо было патчить. Опять же так писали, как на самом деле не знаю)
Все статьи в инете про IPVS ведут на материал с настройками WEB серверов.
Ни одной статьи про распределение запросов или что то намекающее на мускул.
Подтолкните в нужном направление....
Может поможет вам помочь мне разобрать мою кашу:
ipvsadm - для управления правилами модуля ядра IPVS, как я понял опять же.
Если в этой статье, хотя там речь идет о веб сервере, есть нужный мне материал, ткните носом в абзац.
www.ibm.com/developerworks/ru/library/l-linux-ha/
p.s: Не судите строго. Мозг уже плавится. Жду ответов и пояснений.....
Неактивен
ipvs — это алгоритм балансировки. Вообще, интересно, что Вы даете ссылки
на нормальные статьи, но при этом их не читаете, и предлагаете мне их прочесть
Ну, листинг 5 симпатичный Ну и man ipvsadm.
Неактивен
Ну и надо понимать, что ipvs — он просто балансирует. Если нода упадет, то
на нее надо перестать передавать трафик, т.е. какую-то пингалку надо будет
таки написать.
Неактивен
В том то и дело что я эти статьи прочитал раза по 3 уже как минимум.
В сумме за 20 дней я прочел около 120 статей раза по 3, некоторые даже больше.
Представляете какая свалка инфы у меня в голове.
И я хочу хоть как то это упорядочить, отсеять ненужное и записать уже в мозг.
Для меня этот материал новый, поэтому многого не до понимаю.
Теперь, возможно, задам наитупейшие вопросы:
1. Как лучше разделять информацию на WEB сервер, MySQL сервер и Storage или все таки на LA и HA?
2. LVS и LVM - это одно и тоже организованно средствами Xen и управляющееся с помощью xen-drbd?
3. Все это крутится на LVS, которые крутятся на нескольких физических машинах?
4. Любой LVS я могу использовать как под WEB сервер чисто, так и объединить его с MySQL сервером и Storage-ом?
5. У них есть общие модули, компоненты, что там еще, такие как Heartbeat, IPVS, но разные средства управления?
6. В случае для WEB сервера - Heartbeat+mon+ipdsadm+keepalive?
7. В случае для MySQL - Heartbeat+ldirectord+UltraMonkey?
8. В случае для Storage - Heartbeat+GFS+DRBD+GNBD+keepalive?
Отредактированно borodatych (20.07.2010 09:05:52)
Неактивен
Все это в конечном счете пересекается.
MySQL хранит данные для чего ей нужен хороший Storage.
Для безотказной работы пользователей надо обеспечить доступ в сайту, а это WEB, который в свою очередь работает с MySQL, которая работает с данными на Storage.
От суда следует что стоит разделать всю инфу на HA и LB
Надо HA - смотри в сторону Heartbeat, надо LB - смотри в сторону IPVS
Когда во всем интернете MySQL, WEB и Storage рассматривают отдельно, как будто они независимы и ни как между собой не взаимодействуют.
З.Ы: Спасибо за понимание. Жду ответов...
Неактивен
Ох. Видимо, и правда слишком много статей перечитали
Давайте попробую ответить, но не в порядке задавания вопросов, а в логическом.
Может быть, будет чуть понятнее. Пытаемся построить защищенную от сбоев обору-
дования систему.
1. Начнем с одной машинки. Если мы хотим, чтобы на ней сохранялась информа-
ция, то нам нужно резервирование по диску. Резервирование подразумевает, что
если выпадает диск, то мы должны выжить *системой в целом*. Если при этом сис-
тема состоит из небольшого количества машинок, то желательно сделать так, чтобы
выпадение отдельного диска не убивало систему. Мы делаем RAID (1, 10, 5, 6, …).
Это критично делать, например, на мастере репликации — так его гораздо сложнее
убить.
2. Помимо диска на машинке может ломаться много чего другого. Например, сетевая
карта / провод / свитч. Для этого делают резервирование по сети. В linux это назы-
вается bonding.
3. К сожалению, современные технические ограничения не позволяют резервировать
процессоры / память / системную шину / контроллеры дисков. В этом случае прийдется
останавливать машинку.
4. Перебираемся на более высокий уровень. У нас есть несколько машинок, мы хотим
попробовать сделать так, что если какая-то из машинок все-таки выпадает, то система
оставалась в целом рабочей. Для этого мы, например, настраиваем кластер, который
будет своими внутренними процессами регулировать возможность выпадения отдельных
машинок. Или, например, настраиваем несколько реплик в схеме репликации. Тогда
выпадение отдельной реплики не убивает данные из системы. Здесь же, видимо, надо
упомянуть названные Вами технологии типа DRBD — это тоже способ сохранить данные
при вылетании одиночной машинки.
5. Наконец, поднимаемся еще выше. Сохранения данных не достаточно для бесперебой-
ной работы системы: ведь если вылетит элемент, с которым мы общаемся в данный момент,
то связность мы потеряем: надо будет переконфигурировать ПО, это простой работы сис-
темы. Поэтому мы поднимаем балансер над точками входа в систему (sql-нодами кластера,
репликами, веб-серверами, …).
6. Предыдущий пункт хорош, но есть одно но: балансер — это тоже машинка, он тоже
может умереть. Поэтому мы делаем несколько балансеров и настраиваем алгоритмы
(heartbeat, keepalive, …), которые бы делали один балансер активным, а второй — пас-
сивным. Пассивный балансер не делает в общем случае ничего. Он стоит в горячем ре-
зерве. Как только он перестает получать от активного балансера информацию «все хоро-
шо, я жив, обслуживаю», он становится активным.
7. Все вышесказанное относится к MySQL ровно так же, как и к любой другой системе.
Если, например, у Вас сайт, то нужно делать:
- балансер(ы) на входе из внешней сети
- машинки на которых крутится веб-сервер
- балансер(ы), в который пойдут приложения с веб-серверов для доступа к данным
- машинки, на которых крутится СУБД
Если есть бэкенды или стораджи — над ними тоже надо делать балансеры.
8. Наконец, надо понимать, что могут падать свитчи — надо делать резервирование
по свитчам.
9. Наконец, надо понимать, что эта штука крутится в одном ДЦ — надо делать резер-
вирование по ДЦ.
И так далее. Всё зависит от того, сколько сил и ресурсов вы готовы вложить в отказо-
устойчивость системы. Обычно хватает устойчивости данных к потерям (кстати, бэкапы
при этом не забывайте, никакие технические ухищрения не спасут от DROP TABLE нера-
дивого разработчика).
P.S. И — мы сильно ушли от тематики MySQL
Неактивен
Вот теперь каша в голове чуток упорядочивалась и можно приступать к практике.
Ни то что бы полный порядок, но многое прояснилось. Дальше дело техники.
Без вас я бы на порядок дольше приходил бы к такому просветлению.
Выражаю свою искрению благодарность за столь подробный и развернутый ответ.
Неактивен
