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

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 тредов для доступа к этому коннекту???
 

slach

Новичок
спасибо =((( блин чего ж они так криво то реализовали
 

akd

dive now, work later
Команда форума
продолжаем .. простые пустые таблицы :)
 

si

Administrator
algo
как написано в документе выше даже простые select на FEDERATED таблицах реализовано мягко говоря не оптимально.

-~{}~ 28.08.07 20:10:

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

algo

To the stars!
Поделицца что ль своим опытом :) Может, я до чего-то недогадался..

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

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

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

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

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

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

si

Administrator
по-моему тут косяк исключительно у вас, а не в mysql. коли сами злые чебурашки закрутили такую репликацию, научите приложение работать в такой связке.

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

Wicked

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

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

algo

To the stars!
Wicked, а что такое RBR ?

-~{}~ 29.08.07 11:57:

si: Не понимаю, как тут можно использовать Blackhole.
 

Апельсин

Оранжевое создание
si, а как blackhole тут поможет? там же все равно идет фильтрация на уровне SQL выражений и если у него в выражении используется 2 таблицы, а реплицировать надо только 1, то либо все выражение будет реплицироваться и в результате ошибка на слэйве, либо полностью будет скипаться.
 

si

Administrator
я так понял он не хочет на мастере писать таблицу logs, тогда получатеся что на мастере все все кроме logs а нa slave вообще все данные.
 
Сверху