Memo: Binary Logging of MySQL from the viewpoint of storage engine
- two formats: statement-based and row-based
- can be mixed
- 5.1 supports both
- statent-based logs record UPDATE,INSERT,DELETE queries
- row-based logs store internal buffers passed to `handler' class
- storage engines may declare HA_HAS_OWN_BINLOGGING and write to binlog directly
- however, it becomes impossible to log multitable updates
- what happens if the storage engine supports transaction?
- handling of auto_increment
- when using statement-based logs, lock for auto_increment value should be held until a query completes
- when using row-based logs, an auto_increment column can be updated and stored to log one row by row by directly updating ``uchar record[]''
For myself, since Q4M has a hidden rowid, it seems that declaring HA_HAS_OWN_BINLOGGING is the way to go.