|
Задавайте вопросы, мы ответим
Вы не зашли.
Собираемся спланировать и спроектировать рост нашего стартапа.
В данный момент 1 сервер с nginx + mysql. Начало пути - пользователей в базе чуть меньше 10k.
Приложение уже умеет рулить write/read запросы на разные mysql сервера. Пока не используем естественно.
Следующим шагом планируем мастер-мастер репликацию с mysql-proxy как вот в этой статье:
http://habrahabr.ru/blogs/ubuntu/104342/
Но нас больше всего волнует 3-ий шаг, когда серверов mysql нужно будет более 2-ух. Какие структуры связок mysql серверов используют в таких случаях для обеспечения быстродействия и отказоустойчивости? Нужно ли будет использовать кластер, круговую репликация master-master с mysql-proxy, или как mysql рекомендует http://dev.mysql.com/doc/refman/5.0/en/ … n-scaleout ?
Интересны мысли, мнения и рекомендации на счёт различных структур связок mysql серверов.
И ещё вопрос по структуре
http://dev.mysql.com/doc/refman/5.0/en/ … n-scaleout
что делать если 1 master перестанет справляться с write запросами?
Заранее благодарю.
Неактивен
Почитайте комментарии к статье на хабре. На хабре, к сожалению, умные
люди пишут не статьи, а вопросы 
Самый главный вопрос — зачем proxy. Он правда в той конфигурации лиш-
ний. Более того, у Вас будут проблемы с кодировками с использованием
этого приложения.
Что касается master-master — нужно при написании приложений всегда
иметь схему в голове. Нужно понимать, что любые некоммутативные запро-
сы (то есть те, у которых важен порядок выполнения) приведут к тому, что
у Вас будут разные данные на двух мастерах.
Упрощенный пример — добавление новой строки в таблицу и удаление строк.
Допустим, изначально у Вас пустые таблицы на обеих машинках. На одну ма-
шинку приходит запрос добавления строки, а на другую — удаления всех
строк из таблицы. В результате после отработки репликации у Вас будет стро-
ка только на одной из машинок.
При использовании кластера тоже есть свои ограничения — будут быстро ра-
ботать точечные запросы (например, выборка по ключу), но при этом будут
медленно работать агрегирующие запросы (например, достать данные за пос-
ледний месяц).
Именно поэтому чаще всего применяют обычную репликацию и шардирова-
ние. Шардирование позволяет (при разумной организации) практически неог-
раниченное масштабирование на запись, а добавление реплик — на чтение.
Неактивен
