Имеется простой мастер-слейв. Весело растет нагрузка.
Иногда падают серверы (блин, вчерась упал).
Прокоментируйте, пожалуйста, варинаты на вырост:

1. Мастер-слейв. перекинуть на слейв часть чтения
Это самое легкое но не решает проблему стабильности.

2. мастер-мастер. Как оно? пишут что плохо если
разойдутся данные -- трудно синхронизировать.

3. Кластер от Оракла -- пишут что все будет солидно и красиво.
Хотят десяткИ килодолларов в год.

4. есть ли другие бесплатные или недорогие кластерные решения?

5. Перкона вроде имеет какойто НДБ Кластер но сами пишут что
это не для обшего пользования.

Сапсибо заранее за на водки.

Arhat109javajdbc,

если "растет нагрузка" по чтению, то перекинуть всё чтение на слейв - вполне решение. При дальнейшем росте - увеличиваем кол-во слейвов и распределяем "чтение" между ними.

если растет "запись" ... наверное Оракл. И десятки килобаксов - того стоят.

пока наш стартап на вышел на черное, десятки килобаксов
за одну ноду в год как-то не смотрятся...
Конечно хочется "всего и шоб красиво"...

netwind,

Спасибо за коментарии:

Сервер но то чтоб упал. Мы запросили удвоить память.
датацентр сказал Ок, потушили сервер, добавили в конфигурации
памяти и он во сне умер -- второй день лучшие специалисты
сего милого заведения (щоб они были здоровы!) не могу его оживить.

Оракловский кластер:
http://www.mysql.com/products/cluster/
Я Ораклю доверяю, очевидно продукт нормальный, но
10К за ноду в год... может через годик и дорастем.

на Галеру посмотрю, спасибо за на водку.

ScareCrowавторИногда падают серверы (блин, вчерась упал).
можно купить взрослый сервер со взрослым Юниксом. IBM с Parallel Sysplex переживает даже взрыв одного из датацентров.

да-да, блейды, рейды, реданданси, оптоволокна..... видел такой
ОРКЛ на предыдушей работе ... где-то 2М$ в первый год .
Я бы не возразил...

netwind,

OK, интересно , спасибо!

>> Ключевой вопрос - какая нагрузка растет.

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

>> Поэтому, прежде чем куда-то бежать, собираете slow log со временем long_query_time=0,
анализируете с помощью pt-query-digest, и делаете выводы.

Спасибо за наводку на pt-query-digest.
Собствено, примерно так и делается:
появился хороший монитор/онлайн дашборд от нашего провайдера,
выдается нагрузка на веб сервера, на базу, медленые квери
видны через 3 минуты в прямой подвязке к апликационному коду
который это все сделал. После некоторых релизов просто полдня проходилось
ловить грубые запросы и оптимизировать налету.
Причем иногда тормоза связаны с N+1 проблемой
выдачи информации на экран, т.е. надо чинить апликацию тоже.

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

>> Для масштабирования чтения - самое стабильное решение.
>> Репликации уже сто лет в обед, странно, что Вы называете это нестабильным решением.

Я имел ввиду 4то мастер все равно один. Раз 3 месяца
у провайдера кто-то "наступает на шнур" и мы
идем курить на минут 20-30


javajdbc2. мастер-мастер. Как оно? пишут что плохо если
разойдутся данные -- трудно синхронизировать.


>> Для масштабирования записи это не годится. Для чтения - ничем не отличается от №1.

ок, понятно

javajdbc4. есть ли другие бесплатные или недорогие кластерные решения?

5. Перкона вроде имеет какойто НДБ Кластер но сами пишут что
это не для обшего пользования.


>> Percona XtraDB Cluster не решает задачу масштабирования записи по определению.
>> Итого.
>> Для масштабирования чтения - read_only реплики.

Угу, вот думаю как КПИ-дашбоард на слейв переводить для начала

>> Для масштабирования записи:
>> * Больше RAM (i.e. InnoDB buffer pool)

Угу, хостинг виртуальнуй, опция добавки памяти всегда есть

>> * SSD

дорого (для нас) пока, но идея хорошая

>> Sharding

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

#############

Спасибо за советы!