* Peter B. Volk <peter@stripped> [2007-06-19 17:24+0200]
> Hi Jay,
>
> >> But, by this logic, then statement-based replication wouldn't make
> >> sense, since the storage engine on the master and slave can be
> >> different, no?
>
> If you are using federated engines you should change the table type on
> your slave. You are right statement based replication in conjunction with
> the federated tables does not make much sense at alle. It acutally is
> contraproductive :) That is why MySQL supports row based replication. But
> also here you must be carfull. If you insert data into the federated table
> then this insertion is logged and also inserted on the slave. If the table
> on the slave is also federated then the data is inserted twice in the the
> federated database.
twice? or forever until the supply of identical rows is exhausted..?
(i assume that a failed delete does not get replicated.)
> >> In other words, why was this method chosen for the federated handler,
> >> but not for the replication writer?
>
> This method is not only used for the federated handler. It is used by all
> handlers. All storage engines are treated the same (except for innodb its
> a special one ;)). The replication wirter, as far as I know, is event
> driven. Meaning it logs all events e.g. insert statements. No matter what
> storage engine you are using.
>
> Cheers,
> Peter
>
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1
--
-eric
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509
(eric@stripped)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Attachment: [application/pgp-signature] Digital signature signature.asc
