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

[Крот]

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

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

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

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

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

Всем заранее Спасибо!
С наступающими Праздниками!

 

[zerkms]

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

так или иначе - имхо рулить вручную будет правильнее всего

 

[Krishna]

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

-~{}~ 06.01.10 07:30:

А может и нет смысла)

 

[zerkms]

Krishna
а пофиг в итоге как разделять объектом или аргументом
яйца те же, имхо

 

[fixxxer]

> потому что куча запросов select должны выполняться на том же сервере, что и insert.

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

-~{}~ 06.01.10 11:02:

Krishna

Хоть так, хоть эдак, только я бы сразу учел, что слейвов со временем наверняка будет более одного, дабы добавлять тот же round robin на 2-3 слейва не было потом мучительно больно.

 

[zerkms]

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

угу, хотел об этом упомянуть, но решил оставить это на сладенькое тредстартеру

 

[Adelf]

>> SELECT SQL_FOUND_ROWS
Данный селект как и другие, "связанные с результатом инсерта", не являются селектами в стандартном понимании SELECT-оператора. Это фичи баз данных. Поэтому они должны быть как-нибудь в обертке INSERT-коннекшена реализованы.

Почему ТСу не нравится два коннекта?

 

[zerkms]

Adelf
ну прям. у тебя в базе навешаны триггеры/хранимки/дефолтные (вычисляемые) значения
сразу после вставки часто может понадобиться выгрести только что добавленные данные, потому как они уже модифицированы штатными средствами субд. это как раз будет обычный себе SELECT.

 

[Adelf]

Ну... каюсь. SQL_FOUND_ROWS меня смутил. Не в ту сторону думал.

 

[fixxxer]

>>решил оставить это на сладенькое тредстартеру

злой ты )

 

[zerkms]

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

 

[Крот]

Всем Огромное Спасибо за ответы!

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

Когда обдумывал тоже задумался про это. Решил с мастера селектить, разумеется.