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

Как лучше всего на уровне прил. разделить INSERT и SELECT запросы на разные сервера?

  • Автор темы Автор темы Крот
  • Дата начала Дата начала

Крот

Новичок
Как лучше всего на уровне прил. разделить INSERT и SELECT запросы на разные сервера?

Всем привет...

Допустим, есть 3 мускульных сервера: один мастер и 2 репликанта. Как на уровне приложения четко разделить 'должности'? SELECT'ы выполняем с репликантов, имеющих единый хостнейм (распараллеливание запросов с помощью round-robin DNS), а вот INSERT'ы и UPDATE'ы выполняем на мастер-сервере.

Никакого более изящного решения, кроме как создание 2х разных коннектов к БД на ум не приходит, что-то типа...
$DB_MASTER->query("INSERT...");
$DB_SLAVE->query("SELECT...");

А как правильно и удобно?

Всем заранее Спасибо!
С наступающими Праздниками!
 
а как бы это и есть самое правильное решение. только вот назвать бы сервера read/write
почему правильное? потому что куча запросов select должны выполняться на том же сервере, что и insert.
пример: SELECT SQL_FOUND_ROWS
есть ещё ряд примеров, но навскидку не вспомню

так или иначе - имхо рулить вручную будет правильнее всего
 
Я бы только сделал 1 объект соединения, который бы принимал доп. параметр write/read и в зависимости от него бы использовал то или иное соединение. Мне кажется, это было бы более гибкое решение, чем 2 явных разных коннекта на протяжении всего кода.

-~{}~ 06.01.10 07:30:

А может и нет смысла)
 
Krishna
а пофиг в итоге как разделять :-) объектом или аргументом
яйца те же, имхо
 
> потому что куча запросов select должны выполняться на том же сервере, что и insert.

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

-~{}~ 06.01.10 11:02:

Krishna

Хоть так, хоть эдак, только я бы сразу учел, что слейвов со временем наверняка будет более одного, дабы добавлять тот же round robin на 2-3 слейва не было потом мучительно больно.
 
Ага. Практически все селекты, связанные с результатом только что сделанного инсерта. Зачастую - включая те, которые сделаны сразу после редиректа после обработки post-запроса (например, добавление-показ комментария), ибо репликация может и не успеть дойти.
Нажмите для раскрытия...
угу, хотел об этом упомянуть, но решил оставить это на сладенькое тредстартеру :-)
 
>> SELECT SQL_FOUND_ROWS
Данный селект как и другие, "связанные с результатом инсерта", не являются селектами в стандартном понимании SELECT-оператора. Это фичи баз данных. Поэтому они должны быть как-нибудь в обертке INSERT-коннекшена реализованы.

Почему ТСу не нравится два коннекта?
 
Adelf
ну прям. у тебя в базе навешаны триггеры/хранимки/дефолтные (вычисляемые) значения
сразу после вставки часто может понадобиться выгрести только что добавленные данные, потому как они уже модифицированы штатными средствами субд. это как раз будет обычный себе SELECT.
 
Ну... каюсь. SQL_FOUND_ROWS меня смутил. Не в ту сторону думал.
 
>>решил оставить это на сладенькое тредстартеру :-)

злой ты :))
 
fixxxer
ну как злой - всё равно ему эту задачу пришлось бы решать. а задача интересная :-)
 
Всем Огромное Спасибо за ответы!

Автор оригинала: zerkms
fixxxer
ну как злой - всё равно ему эту задачу пришлось бы решать. а задача интересная :-)
Нажмите для раскрытия...
:) Когда обдумывал тоже задумался про это. Решил с мастера селектить, разумеется.
 
Войдите или зарегистрируйтесь для ответа.
Сверху