URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 6006
[ Назад ]

Исходное сообщение
"MySQL репликация без DELETE"

Отправлено z1nkum , 12-Дек-06 19:31 
Добрый всем [утро/день/ночь/пятница]

Не подскажете, можно ли сделать репликацию MySQL, чтобы на SLAVE не выполнялись DELETE с MASTER'а ? (SLAVE будет этаким большиииим мусорным контейнером)


Содержание

Сообщения в этом обсуждении
"MySQL репликация без DELETE"
Отправлено rWizard , 13-Дек-06 10:35 
Если это и возможно встроенными средствами ( в чем я сомневаюсь ) такая конфигурация может вызвать brain-split.
Например:
в таблице t1 есть поле id, являющееся primary key.
DELETE FROM t1 WHERE id = 1; (на slave не выполнилось)
INSERT INTO t1(id) VALUES(1);

рекцией на последний запрос будет, скорее всего ошибка на slave


"MySQL репликация без DELETE"
Отправлено z1nkum , 13-Дек-06 10:44 
>Если это и возможно встроенными средствами ( в чем я сомневаюсь )
>такая конфигурация может вызвать brain-split.
>Например:
>в таблице t1 есть поле id, являющееся primary key.
>DELETE FROM t1 WHERE id = 1; (на slave не выполнилось)
>INSERT INTO t1(id) VALUES(1);
>
>рекцией на последний запрос будет, скорее всего ошибка на slave

Хотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы. БД организована более-менее грамотно, как минимум, primary key - автоинкремент и инсёрты в таблицу без явного указания ключа.


"MySQL репликация без DELETE"
Отправлено rWizard , 13-Дек-06 12:17 
>Хотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы.
>БД организована более-менее грамотно, как минимум, primary key - автоинкремент и
>инсёрты в таблицу без явного указания ключа.

Извините, но мне кажется, что это ошибка планирования. Как вариант возможно реализовать это во фронт-энде.
Если вы привидете больше конкретики, возможно я смогу ещё что-то предложить.


"MySQL репликация без DELETE"
Отправлено z1nkum , 13-Дек-06 13:58 
>>Хотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы.
>>БД организована более-менее грамотно, как минимум, primary key - автоинкремент и
>>инсёрты в таблицу без явного указания ключа.
>
>Извините, но мне кажется, что это ошибка планирования. Как вариант возможно реализовать
>это во фронт-энде.
>Если вы привидете больше конкретики, возможно я смогу ещё что-то предложить.

Есть сервер БД (MASTER), есть БД, в ней есть ряд таблиц, которые очень быстро "пухнут".
Есть ряд пользователей, которые донимают сервер БД тяжёлыми селектами по этим самым пухнущим таблицам. Тяжёлые таблицы - Innodb.
При аварии восстановление из дампа занимает несколько часов именно из-за содержимого этих тяжёлых таблиц.

Идея в следующем:

Поднять SLAVE. Натравить надоедливых пользователей с их селектами на SLAVE. В то же время, подчищать MASTER ( к примеру, раз в сутки удалять данные старше N дней )

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



"MySQL репликация без DELETE"
Отправлено rWizard , 13-Дек-06 14:14 
а если полностью перенести "пухнущие" таблицы на другой сервер?


"MySQL репликация без DELETE"
Отправлено z1nkum , 13-Дек-06 15:00 
>а если полностью перенести "пухнущие" таблицы на другой сервер?
нельзя, т.к. их "заполняет" "чёрный ящик" - демон, к коду которого нет доступа



"MySQL репликация без DELETE"
Отправлено BigHo , 14-Дек-06 11:32 
>Добрый всем [утро/день/ночь/пятница]
>
>Не подскажете, можно ли сделать репликацию MySQL, чтобы на SLAVE не выполнялись
>DELETE с MASTER'а ? (SLAVE будет этаким большиииим мусорным контейнером)

Это работа для тригеров (только в mysql5.x). Вкраце - при вставке новой записи или обновлении можно заставить mysql выполнить заполнение других таблиц на основе изменяемых данных.

P.S. Запретить DELETE для репликации стандартным методом невозможно, из-за того, что это нарушает основы SQL сервера. А именно - нарушается целостность данных.