Hi Zardosht,
Normally, the storage engine does not have to do anything special to support
replication. The flags you mention are basically only there so that a storage
engine can *prevent* certain kinds of replication that will not work (it is
common that MVCC engines does not support statement-based replication in some
situations).
Sergei showed an example where InnoDB does not work, and for Falcon it is
generally the case that it does not support statement-based replication (because
it is a "pure" MVCC engine).
The contract is different in statement-based replication and row-based
replication. For statement-based replication the statement will simply be logged
after the storage engine has successfully finished updating the tables, for
row-based replication, a packed version of the record(s) sent to the storage
engine is written to the binary log on a successful write/delete/update.
Just my few cents,
Mats Kindahl
Zardosht Kasheff wrote:
> Hello all,
>
> I realize this is a bit of a general question, but I am not sure where
> to start looking.
>
> How does one determine if a storage engine supports replication/binary logging?
>
> I see that a storage engine must expose the flags
> HA_BINLOG_ROW_CAPABLE and HA_BINLOG_STMT_CAPABLE, but I do not see
> anything the storage engine needs to actually do. What is the
> contract? For other flags, exposing them implies something that the
> storage engine can do. For example, setting
> HA_PRIMARY_KEY_IN_READ_INDEX implies that the storage engine must be
> able to retrieve the primary key when doing a scan of a secondary
> index.
>
> However, for binary logging, I do not see any functions the storage
> engine must implement and I cannot find any contract the storage
> engine must fulfill. However, the existence of the flags makes me
> think that the storage engine must be doing something.
>
> Any ideas on what I should read or where to look?
>
> Thanks
> -Zardosht
>
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
