Хитрая репликация (master-slave)

[confguru]

Хитрая репликация (master-slave)

Может кто у себя делал?

Идея такая - есть мастер mysql сервер, заточенный
под insert,update (убраны лишние индексы)

И есть пара slave серверов у которых индексы оптимизированы под select.

Возможно ли вообще такое и будет ли прирост
по выборке если читать только со slave?

 

[si]

ну в принципе возможно я думаю. на счет что это даст сказать не берусь.

 

[.des.]

На данный момент возможно.
Это очень сильно загрузит slave, так как ему придется перестраивать индексы. Зато нагрузка на master снизится.

Ну и также могут возникнуть проблемы с репликацией при наличии UNIQUE индексов.

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

 

[Steamroller]

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

 

[si]

Это очень сильно загрузит slave, так как ему придется перестраивать индексы. Зато нагрузка на master снизится.

плюс тут в том что на slave insert/update делает 1 процес

Ну и также могут возникнуть проблемы с репликацией при наличии UNIQUE индексов.

неочень понимаю если често в чем проблема.

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

они и сейчас ее меняют. скажем я обновил один из своиз slave до 5.0 (master и другие slave 4.1) так на slave с 5.0 репликация падает переодически, на простом примере это воспроизвести мне не удалось.

сам я конечно против таких решений когда на master/slave базы разные по структуре. имхо лучше увеличить мощность hw или добавить еще slave при необходимости, а не строить себе мины замедленного действия.

 

[.des.]

Автор оригинала: si
неочень понимаю если често в чем проблема.

На мастере:

CREATE TABLE tbl(id int);

На слэйве:

ALTER IGNORE TABLE tbl ADD UNIQUE INDEX (id);

На мастере:

INSERT INTO tbl VALUES (1),(2);
SELECT * FROM tbl;
|    1 |
|    2 |
2 rows in set (0.00 sec)

На слэйве:

SELECT * FROM tbl;
|    1 |
|    2 |
2 rows in set (0.00 sec)

На мастере:

INSERT INTO tbl VALUES (2),(3);
SELECT * FROM tbl;
|    1 |
|    2 |
|    2 |
|    3 |
4 rows in set (0.00 sec)

На слэйве:

[ERROR] Slave: Error 'Duplicate entry '2' for key 1' on query. 
Query: 'INSERT INTO tbl VALUES (2),(3)' ....
[ERROR] Error running query, slave SQL thread aborted. 
Fix the problem, and restart the slave SQL thread...

Собственно говоря, что делать после этого момента мне лично не совсем понятно. Перезапуск слэйва проблему не решит.

Ситуация надуманная - конечно constraint индексы как и primary keys в таблицах на мастере должны быть, так как без них даже непонятно как проводятся updates.

 

[SaNo]

Эээээ, ребята, куда вас понесло?

Какого хрена на слейве менять структуру таблиц? Вы чего? Такое дело не пойдет. Репликация в большинстве случаев нужна либо для избыточности, либо для прироста производительности. Репликация подразумеват, что slave берет данные с master (еще бывает двухсторонняя репликация). Обычно мастер 1, а слейвов 1 и более, хотя можно и дерево построить, но мы не об этом сейчас.

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

Использовал реплицикацию в одном из своих проектов (MySQL 4.0.X), не знаю, как сейчас реализована репликация, но помню, что были проблемы.
Не было механизма корректного восстановления при сбое (т.к. не было механизма горячего резервного копирования). Приходилось всё ручками поднимать. А это потеря времени, данных и т.д. Надо блокировать таблицы, копировать их, запомнить позицию, а потом это все перенести на слейв.

 

[si]

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

 

[.des.]

2 si согласен.
Я просто указал на одну из возможных проблем