Select Page

About MySQL storage engines and replication

Patrick Galbraith | | September 2, 2011

I know most articles are more about DBA issues, however, being a MySQL DBA means that you have several hats that you can where– data architect, application developer, MySQL source developer, and often good old fashioned DBA. I recently had an interesting problem with a particular project I was working on that required the MySQL source code developer hat that I used to wear much more often during the black vodka era of working for MySQL AB.

This was case of a custom storage engine a client has, and whenever I would try to use statement-based replication, I would encounter an error upon running DML statements on the master:

<pre>ERROR 1598 (HY000): Binary logging not possible.
Message: Statement-based format required for this statement,
but not allowed by this combination of engines</pre>

Despite having worked on several storage engines, written Federated/FederatedX, I couldn’t remember what about a storage engine pertains to replication, nor did it make sense to me that the storage engine would have anything to do with it since binary logging occurs at a higher level than at the storage engine.

I was talking to Monty about it, and he pointed me to look at

ha_myisam::ha_myisam(handlerton *hton, TABLE_SHARE *table_arg)
:handler(hton, table_arg), file(0),

How one forgets simple but important things over time, that being me! These flags are very important and determine the capabilities of a storage engine. I will post about what each is at a later time. Suffice to say, I had searched Google to no avail, and by posting this article, if you are trying to get replication working for a given storage engine, this will come up! The important flags you see here are <code>HA_BINLOG_ROW_CAPABLE</code> and <code>HA_BINLOG_STMT_CAPABLE</code>. I never used to pay as much attention to these particular flags when developing Federated because I would often use flags from another storage engine and was focused on flags that pertained more to what Federated could do and could not do. However, these flags are required if you want replication to work.

The flags in the client storage engine did have <code>HA_BINLOG_ROW_CAPABLE</code> but not <code>HA_BINLOG_STMT_CAPABLE</code>. Additionally, the flag <code>HA_HAS_OWN_BINLOGGING</code> was present. This is a show-stopper. The only engine that has this is NDB cluster.

No harm done, with the correct flags added, the custom storage engine now replicates!

Happy storage engine hacking!

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

ORA-12154: TNS:could not resolve the connect identifier specified

Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.

Jeremiah Wilton | March 4, 2009

12c Upgrade Bug with SQL Tuning Advisor

Learn the steps to take on your Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.

Megan Elphingstone | March 22, 2017

Recover a Table from an RMAN Backup in an Oracle 12c

This blog post will is to show a table restore for one table in a container database.

Megan Elphingstone | February 2, 2017

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.


Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.