From: Kristian Nielsen Date: October 4 2012 8:55am Subject: Re: making a storage engine crash safe on a slave in MySQL 5.6 List-Archive: http://lists.mysql.com/internals/38597 Message-Id: <87obkiy5tv.fsf@frigg.knielsen-hq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Zardosht Kasheff writes: > Is the following correct? > > With each InnoDB write transaction on a slave, the slave's relay log > info is updated with that transaction before commit? Because the > slave's relay log is now an InnoDB table, upon recovery, whatever the > slave relay log recovers to will be correct. If this is correct, where > is the code that is doing this? As I understand it, the issue is not the relay log. If the relay log is cut short after a crash, it can just be fetched anew from the master. The issue is the position in the master binlog that the SQL thread has reached, ie. the end of the last event applied by the slave. This used to be stored in relay-log.info in a non-crash-safe way, and can now optionally be stored in an InnoDB table so it can be recovered in a transactionally consistent way along with applied changes. > sync with the state of InnoDB. I would like to understand how this is > done and what another storage engine can do to ensure this. In principle, this should work for any other XA-capable engine as well. Since transactions that span two or more such engines are XA-committed and recovered consistently after a crash. So putting the replication info in InnoDB and replicating tables in your engine should be ok, or vice versa. However, note that XA between multiple engines is rather costly, and also there used to be several severe bugs for this in MySQL that may or may not be fixed yet. > How does this work with a slave running parallel threads? If multiple > threads are processing different parts of the relay log, how do these > multiple threads manage updating the relay log? I do not know. I would assume there will be multiple rows in the table, one per SQL thread? Hope this helps, - Kristian.