Добрый всем [утро/день/ночь/пятница]Не подскажете, можно ли сделать репликацию MySQL, чтобы на SLAVE не выполнялись DELETE с MASTER'а ? (SLAVE будет этаким большиииим мусорным контейнером)
Если это и возможно встроенными средствами ( в чем я сомневаюсь ) такая конфигурация может вызвать brain-split.
Например:
в таблице t1 есть поле id, являющееся primary key.
DELETE FROM t1 WHERE id = 1; (на slave не выполнилось)
INSERT INTO t1(id) VALUES(1);рекцией на последний запрос будет, скорее всего ошибка на slave
>Если это и возможно встроенными средствами ( в чем я сомневаюсь )
>такая конфигурация может вызвать brain-split.
>Например:
>в таблице t1 есть поле id, являющееся primary key.
>DELETE FROM t1 WHERE id = 1; (на slave не выполнилось)
>INSERT INTO t1(id) VALUES(1);
>
>рекцией на последний запрос будет, скорее всего ошибка на slaveХотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы. БД организована более-менее грамотно, как минимум, primary key - автоинкремент и инсёрты в таблицу без явного указания ключа.
>Хотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы.
>БД организована более-менее грамотно, как минимум, primary key - автоинкремент и
>инсёрты в таблицу без явного указания ключа.Извините, но мне кажется, что это ошибка планирования. Как вариант возможно реализовать это во фронт-энде.
Если вы привидете больше конкретики, возможно я смогу ещё что-то предложить.
>>Хотелось подчищать быстро нарастающие таблицы на мастере, заставив фронт-энды дёргать селектами слейвы.
>>БД организована более-менее грамотно, как минимум, primary key - автоинкремент и
>>инсёрты в таблицу без явного указания ключа.
>
>Извините, но мне кажется, что это ошибка планирования. Как вариант возможно реализовать
>это во фронт-энде.
>Если вы привидете больше конкретики, возможно я смогу ещё что-то предложить.Есть сервер БД (MASTER), есть БД, в ней есть ряд таблиц, которые очень быстро "пухнут".
Есть ряд пользователей, которые донимают сервер БД тяжёлыми селектами по этим самым пухнущим таблицам. Тяжёлые таблицы - Innodb.
При аварии восстановление из дампа занимает несколько часов именно из-за содержимого этих тяжёлых таблиц.Идея в следующем:
Поднять SLAVE. Натравить надоедливых пользователей с их селектами на SLAVE. В то же время, подчищать MASTER ( к примеру, раз в сутки удалять данные старше N дней )
При такой схеме MASTER занимается основной работой, SLAVE - отдачей и складированием.
Если беда с MASTER - восстановление из урезанного дампа гораздо быстрее.
а если полностью перенести "пухнущие" таблицы на другой сервер?
>а если полностью перенести "пухнущие" таблицы на другой сервер?
нельзя, т.к. их "заполняет" "чёрный ящик" - демон, к коду которого нет доступа
>Добрый всем [утро/день/ночь/пятница]
>
>Не подскажете, можно ли сделать репликацию MySQL, чтобы на SLAVE не выполнялись
>DELETE с MASTER'а ? (SLAVE будет этаким большиииим мусорным контейнером)Это работа для тригеров (только в mysql5.x). Вкраце - при вставке новой записи или обновлении можно заставить mysql выполнить заполнение других таблиц на основе изменяемых данных.
P.S. Запретить DELETE для репликации стандартным методом невозможно, из-за того, что это нарушает основы SQL сервера. А именно - нарушается целостность данных.