Zardosht Kasheff <zardosht@stripped> 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,