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

row-based replication

Апельсин

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

Лысый

Новичок
ок
пасиб
но всё же
киньте плз ссылочки на статьи о том как граммотно пользоваться репликацией?

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

вот я и думаю, как мне лучше организовать репликацию.

спасибо
 

chisto_tolyan

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

Лысый

Новичок
ну вот я и думаю над этим
но мне не нужно хранить на всех слейвах всю инфу

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

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

вот такая схема. если на пальцах объяснять
 
svetasmirnova

svetasmirnova

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

Вообще-то это slave read-only и на него всё реплицируется с мастера. А ты, как я поняла, хочешь двустороннюю репликацию. В принципе, в мане MySQL информации достаточно. Других учебников так сразу и не вспомню.
 

Лысый

Новичок
во мне хотя бы интересен ответ на практический вопрос

является ли нормальной идея, производить репликацию сразу после добавления строчки на мастер в схеме мастер и 5-6 слейвов?
 

Апельсин

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

Тебе же это не подойдет потому что структура таблиц отличается и судя по всему тебе нужна мастер-мастер репликация, а не стандартная мастер-слейв.
 

Лысый

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

вот об этом то я и хотел побольше почитать
 

Апельсин

Оранжевое создание
> просто боязно не вызовет ли это черезмерной нагрузки

черезмерной нагрузки на что? на мастер?

> или блокировки БД на чтение не то что на запись

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

Лысый

Новичок
ну про нагрузку я не верно сказал
я имею в вижу не застопорит ли такое массовое обновление работу системы благодаря блокировке?

как быстро идёт репликация если изменилась всего одна строчка? скажем один мастер, 6 слейвов, таблица из 2х интов и одног тайм зампа?

какой способ предпочтительней, row-based или statement-based ?
 

Апельсин

Оранжевое создание
> я имею в вижу не застопорит ли такое массовое обновление работу системы благодаря блокировке?

что вы понимаете под "массовым обновлением"? Один большой UPDATE который много строк обновляет? на слэйвах он будет обрабатываться так же как и на мастере, и если у вас блокируется таблица/строки на мастере то они же будут блокироваться и на слэйве.

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

> как быстро идёт репликация если изменилась всего одна строчка? скажем один мастер, 6 слейвов, таблица из 2х интов и одног тайм зампа?

зависит от вашей сети и нагрузки на слэйве. В идеале - мгновенно. В не идеале - с секундомером измеряйте сами.

> какой способ предпочтительней, row-based или statement-based ?

смотря что вам нужно. первый способ более точный, второй - быстрее. Если у вас разные структуры, то первый вам не подходит в принципе.
 

Лысый

Новичок
более менее понял про типы репликации

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

chisto_tolyan

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

Лысый

Новичок
ну и что?

1) их спецификация может быть вынесена по внешнему ключу в другие таблицы

2) вот как я понял, при statement-based репликации можно обновалять более полную таблицу (содержащюю большее колво не NOT NULL столбцов) с мастера, где полей меньше
 

Апельсин

Оранжевое создание
> ну и что?

то что с этим можно набраться гемороя. причем большого.
 

Апельсин

Оранжевое создание
> а какие выходы?

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

Лысый

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

Апельсин

Оранжевое создание
Лысый, дело не в том брать всю инфу или не всю. Можно реплицировать разные таблицы на разные слэйвы. Но структура при этом желательно должна быть одинаковой.

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

Хочешь в это ввязываться - никто тебя держать не будет, но в 99% случаев геморой тебе будет обеспечен.
 
Войдите или зарегистрируйтесь для ответа.
Сверху