Меню
Что нового?

PHP Application and MySQL репликация

Kathrin

Новичок
В продолжении

http://phpclub.ru/talk/threads/php-application-and-mysql-шардинг.72233/

Сейчас я не представляю себе как будет работать шардинг вместе с репликацией.
Ведь пишется теперь все на мастер а читается со слейва/слейвов.И на мастере получается таблица новостей одна.
Как можно объеденить шардинг с репликацией?И нужно ли это, думаю да, таблица то большая?

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

Стоит вопрос, а как балансировать нагрузку на слейвах, допустим их там 10 будет?

Читала, что можно делать схему мастер-мастер но это по идее просто зеркало, может я не права?
Так же читала что один из слейвов может быть мастером для других

..........мастер
............|.......|
......мастер..слей.слейв
.......|......|
слейв слейв

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

мастер...........мастер
.....|.......|............|........|
слейв слейв слейв слейв

Получается при такой схеме, пои дее можно добавить шардинг (таблица режется на несколько мастеров).
Пишем на один из мастеров, а читаем с одного из слейвов, на стороне приложения все усложняется.
И как балансировать не очень понятно.

Читала, что появился, какой то MySQL Proxy, который позволяет все разрулить, может даже шардинг (написать что то на Lua). Толком не поняла, там больше про балансировку было.

Читала что в Mongo все это реализовано и полностью прозрачно для разработчика, через один узел идут запросы, на стороне приложения нечего делать не нужно. На стороне монго, все балансируется, шардится и реплецируется/кластеризируется (об это пока мало читала)

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

Может есть хорошие статьи или видео с конференций.Спсибо.

Далее тема о кластерах http://phpclub.ru/talk/threads/php-application-and-mysql-кластер.72235/ ))
 

Kathrin

Новичок
Больше конкретных вопросов по совету Фаната.

1. При использовании репликации на уровне приложения необходимо делать правки? Или MySQL Proxу все решит с записью и чтением?
2. Зачем схема мастер-мастер?
3. мастер...........мастер
.....|.......|............|........|
слейв слейв слейв слейв
Как балансировать мастеров и слейвово? Такая схема только для шардинга? Если нет то для каких задач и как используется подобная схема?

Спасибо!
 
флоппик

флоппик

promotor fidei
Команда форума
Партнер клуба
2. Мастер-мастер как правило, нужен тогда, когда не хватает скорости записи.
В веб-приложениях есть особенность касающаяся балансировки — это случай GET after POST — т.е. отображение данных после их обновления. Так, например, после обновления профиля пользователя данные нужно считать с того же мастера, на котором произошла запись, т.к. репликация обычно не успевает распространить изменения, но их нужно отобразить пользователю, для того что бы он понял что операция завершилась успехом. Скорее всего, это придется делать уже в приложении.
 

Kathrin

Новичок
Ясненько, спасибо. Читала о том, что частенько после обновления данных, приходится читать с мастера, если необходима актуальность.
Мастер-мастер получается зеркала, удобна для географического разделения.
 

Kathrin

Новичок
А при схеме матср-мастер у мастера еще могут быть слейвы?
 

Kathrin

Новичок
А какое решение подойдет если в таблице куча записей 500 мил например, и мы уперлись именно в это... Репликация отпадает, шардинг судя по ответам не айс, кластер - пока мало о нем знаю.
Вот как работать с такой таблицей?
 
grigori

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Kathrin это вопрос сродни просьбе поставить диагноз больному через общение на форуме и перечисление симптомов, которые вы заметили. так не бывает. нанимайте того, кто знает, или учитесь - сначала надо прочесть несколько тысяч страниц мануалов и статей.
это называется "профессия", на ее освоение уходит не один год
 

Kathrin

Новичок
grigori написал(а):
Kathrin это вопрос сродни просьбе поставить диагноз больному через общение на форуме и перечисление симптомов, которые вы заметили. так не бывает. нанимайте того, кто знает, или учитесь - сначала надо прочесть несколько тысяч страниц мануалов и статей.
это называется "профессия", на ее освоение уходит не один год
Нажмите для раскрытия...
Спасибки.
Это понятно, просто пытаюсь выделить подходы с которых начинать можно и нужно. Посмотрела видео о кластере, задачу можно решить с его помощью (данные шардит). Но задача абстрактная, так же как и решение, т.е. без учета нюансов и привязки к контексту.
Если у нас задача и в задаче только работа с 1 мил записей, то можно будет класть в кэш или сделать отдельную таблицу и сливать туда. Если уткнутся в запись и обновление индексов, можно сделать клон таблицы с данными и без индексов и сихронизировать их и т.д.
Решений может быть много и вы правы имея коня в вакууме, сложно что то сказать.

Cпасибо, что направляете.
 

MiksIr

miksir@home:~$
флоппик c чего бы мастер-мастер поможет при проблемах с записью? Асинхронный мастер-мастер еще может помочь пережить кратковременные пики по записи, но асинхронный м-м не тривиальная задача. А синхронный все-равно ждет все ноды, т.е. скорость записи равна производительности самой слабой ноды.

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

Если возвращаться к мускулю, там есть неплохое решение "из коробки" - NDB, где и шардинг и репликация.
 
Войдите или зарегистрируйтесь для ответа.
Сверху