Thanks for the feedback Kristian. With this information, I now need to
experiment to investigate this behavior.
On Thu, Oct 4, 2012 at 4:55 AM, Kristian Nielsen
> 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,
> - Kristian.