mysql кластер на высоконагруженном проекте вместо master-slave связок на нодах

[440hz]

mysql кластер на высоконагруженном проекте вместо master-slave связок на нодах

высоконагруженный проект распределяет нагрузку между нодами. на каждой ноде поднят слейв с мастера и все запросы на SELECT идут локально, а все записи идут на мастер удаленно.

возника идея заменить связку master-slave(s) на нодах на mysql-кластер. есть какие-нить мысли у народа на этот счет? столи ли смотреть в эту сторону? ведь выход из строя одной из нод как раз не повлияет на работу кластера и всей системы целиком. балансер просто выключит ее из обработки запросов, а ввод новой ноды не будет сложным при вставке ее в кластер?

p.s. везде будет стоять FreeBSD 7.0 и mysql 5.2

 

[pilot911]

а чем не устраивает первый вариант ? например, фотофайл именно его и использует

 

[440hz]

pilot911

1. если мастер ляжет куда будут писать приложения? в возух?
2. мастер все равно ограничен мощностью и когда-нить она превысит допустимую и тогда все ляжет.

 

[fixxxer]

тут два решения - шардинг и кластер.
если делать шардинг, берем базовую для проекта сущность а точнее ее ид (например идентификатор пользователя) и определяем на каком сервере он живет (либо статической пробивкой связей user id - server id, либо алгоритмом типа ketama). в этом случае надо избегать вариантов когда требуется сбор данных с нескольких серверов, например дублированием.
если кластер - то вот и расскажешь как оно работает %)

 

[MiksIr]

440 ни один кластер/репликация не маштабирует апдейты. Асинхронная репликация позволяет "сгладить" пики апдейтов, но не масштабировать их, синхронная репликация и подавно только ухудшает производительность по апдейтам.

Что нужно делать, так это асинхронную репликацию, систему мониторинга жизни мастера и переключение одного из слейвов в режим мастера при падении первого. Переключение софта на новый мастер можно осуществить как банальным переключением IP адреса мастера на другую ноду, так и каким-нибудь балансировщиком, которому при переключении скажут новый адрес мастера.

Конкретных решений под MySQL я не ориентируюсь
Решение MySQL cluster стоит использовать если нужна 100% консистентность данных на нодах, т.е. что бы информация появлялась на всех нодах одновременно и сразу после апдейта.

-~{}~ 28.08.08 16:59:

Ну да, а если уткнулись в производительность по апдейтом, то только разбразывание по серверам структуры БД... или табличками, если есть несколько равнонагруженных или партишенинг (ну тот самый шардинг)

 

[440hz]

MiksIr

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

так же хочется попробовать это в живую, т.к. много читал но не делал.

а обсчет статистики будет вообще на отдельном сервере. в кластер пойдут только агрегированные данные.

так же memcache там будет. только пок не знаю как он себя будет вести на несольких серверах.

ну в общем буду отписываться только куда лучше в этот тред или в тот что в хостинге?

можно создать отдельный тред где я все опишу если кому это интересно. но это как админы решат.

а вообще кто-нить имел дело в живую с кластером?

 

[MiksIr]

Давай тогда ставь постгрес и будем вместе пробовать мультимастер решения для него

 

[fixxxer]

насколько я понимаю задачу там же вроде можно заранее готовить очереди что куда идет
этакий prediction hash

 

[440hz]

MiksIr
да не. я пока на MySQL посижу. постгресс плохо знаю. боюсь накосячу. потом разгребать...

-~{}~ 28.08.08 17:31:

Автор оригинала: fixxxer
насколько я понимаю задачу там же вроде можно заранее готовить очереди что куда идет
этакий prediction hash

это ты о чем?

 

[флоппик]

Конкретных решений под MySQL я не ориентируюсь

Mysql Proxy ?

 

[pilot911]

пиши в этой ветке, как и что делается

насколько я знаю, мемкеш можно уже сейчас запускать с пулом серверов, он сам отслеживает живые серваки и имеет механизм восстановления

 

[MiksIr]

не, мемкеш сам ничего не умеет
умеют клиентские библиотеки, но и они о восстановлении речи не ведут, да и не надо это - мемкеш не позиционируется как гарантирующий хранение.
а что умеют библиотеки, так это на основе ключа по своему алгоритму определить ноду и туда этот ключ записать...
в большинстве случаев при добавлении нового сервера мемкеш, так как количество серверов меняется, то слетает все распределение ключей и вся информация теряется
как поступать с ключами ноды помеченной как мертвая тож решает клиент - отмапить ее временно в другую ноду или просто проигнорить.

 

[Wicked]

в большинстве случаев при добавлении нового сервера мемкеш, так как количество серверов меняется, то слетает все распределение ключей и вся информация теряется

- это как раз если не использовать ...

алгоритм типа ketama

 

[MiksIr]

А, ну это по сути "запустим пул серверов с десятком фейковых" при условии что библиотека мапит мертвые сервера в живые. Для PHP это единственный вариант, ибо там ketama нет