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

FEDERATED Storage Engine - коннекты к удаленному серверу

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

slach

Новичок
FEDERATED Storage Engine - коннекты к удаленному серверу

внимательно прочитал доку

http://dev.mysql.com/doc/refman/5.1/en/federated-usagenotes.html
http://dev.mysql.com/doc/refman/5.1/en/federated-description.html
The local server communicates with the remote server using MySQL client C API functions. It invokes mysql_real_query() to send the statement. To read a result set, it uses mysql_store_result() and fetches rows one at a time using mysql_fetch_row().
Нажмите для раскрытия...

все замечательно, все понятно
только непонятно каким образом и сколько раз mysql_connect при соединении с REMOTE сервером???
к сожалению прямо сейчас не могу запустить mysqlsniffer и проверить
поэтому задаю вопрос сюда

вариантов в моей голове несколько
какой из них правильный???

- один mysql_connect на каждую созданную FEDERATED таблицу с одинаковым CONNECTION mysql://user:password@host/database???
- один mysql_connect на каждый запрос к любой FEDERATED таблице в рамках одного mysql_connect к LOCAL серверу???
- или (о чудо если так) один коннект на все FEDERATED таблицы с одинаковым mysql://user:password@host/database с использованием множества LOCAL тредов для доступа к этому коннекту???
 
продолжаем .. простые пустые таблицы :-)
 
algo
как написано в документе выше даже простые select на FEDERATED таблицах реализовано мягко говоря не оптимально.

-~{}~ 28.08.07 20:10:

если честно меня давно не покидает ощущение что mysql превратился в набор костылей, после прослушивания презентации от Московской Группы Пользователей MySQL на тему "Новые возможности MySQL 5.1" это ощущение только усилилось.
 
Поделицца что ль своим опытом :) Может, я до чего-то недогадался..

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

Сказано - сделано, сервер поднят и таблица logs пишецца туда.. На уровне приложения все поправили.

Но к этой таблице идут иногда запросы с джойнами на справочники.. Пришлось туда еще таблицы реплицировать нужные, просто чтоб джойн на месте делать. Сервер с логами - слейв, сервер со справочниками - мастер.

А дальше косяк.. SQL-стейтменты, которые справочники обновляют, используют другие таблицы. Когда такой стейтмент на мастере отработал - он на слейве падает, т.к там таких таблиц нет..
Если добавить эти таблицы - то еще по депендам добавлять - и приходится всю базу реплицировать...

Сейчас рабочий вариант - делать запросы в 2 этапа: сначала из логов выборка, а потом джойн... Но, в общем, есть некоторые проблемы с таким подходом..

С MSSQL и Oracle такой проблемы бы, конечно, не было, а тут мне неочевидно что предпринять... Может, FEDERATED... Идеи?
 
по-моему тут косяк исключительно у вас, а не в mysql. коли сами злые чебурашки закрутили такую репликацию, научите приложение работать в такой связке.

P.S. мне кажется тут можно использовать очередной костыль из арсенала mysql это такой storage engine как BLACKHOLE.
 
P.S. мне кажется тут можно использовать очередной костыль из арсенала mysql это такой storage engine как BLACKHOLE.
Нажмите для раскрытия...
Имхо толку будет очень мало. Да, запросы падать не будут, но и джоины с такими таблицами будут пустые.

По мне так можно поиграться с использованием RBR вместо SBR.
 
Wicked, а что такое RBR ?

-~{}~ 29.08.07 11:57:

si: Не понимаю, как тут можно использовать Blackhole.
 
si, а как blackhole тут поможет? там же все равно идет фильтрация на уровне SQL выражений и если у него в выражении используется 2 таблицы, а реплицировать надо только 1, то либо все выражение будет реплицироваться и в результате ошибка на слэйве, либо полностью будет скипаться.
 
я так понял он не хочет на мастере писать таблицу logs, тогда получатеся что на мастере все все кроме logs а нa slave вообще все данные.
 
Войдите или зарегистрируйтесь для ответа.
Сверху