The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"MySQL репликация без DELETE"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"MySQL репликация без DELETE"  
Сообщение от z1nkum email on 12-Дек-06, 19:31 
Добрый всем [утро/день/ночь/пятница]

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "MySQL репликация без DELETE"  
Сообщение от z1nkum email on 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 - автоинкремент и инсёрты в таблицу без явного указания ключа.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру