List:Internals« Previous MessageNext Message »
From:Peter B. Volk Date:June 19 2007 3:24pm
Subject:Re: Rationale behind FEDERATED engine queries
View as plain text  
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.

>> 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

Thread
Rationale behind FEDERATED engine queriesGiuseppe Maxia19 Jun
  • Re: Rationale behind FEDERATED engine queriesPeter B. Volk19 Jun
    • Re: Rationale behind FEDERATED engine queriesJay Pipes19 Jun
      • Re: Rationale behind FEDERATED engine queriesBaron Schwartz19 Jun
        • Re: Rationale behind FEDERATED engine queriesPeter B. Volk19 Jun
          • Re: Rationale behind FEDERATED engine queriesEric Prud'hommeaux19 Jun
  • Re: Rationale behind FEDERATED engine queriesPhilip Stoev23 Jun