Thanks Mark and Rich for the feedback.
So let me take a step back. As I understand it, something was done in
MySQL 5.6 to ensure that should a slave crash, the relay log is in
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.
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?
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?
-Zardosht
On Wed, Oct 3, 2012 at 12:46 PM, MARK CALLAGHAN <mdcallag@stripped> wrote:
> On Wed, Oct 3, 2012 at 8:15 AM, Zardosht Kasheff <zardosht@stripped> wrote:
>> Hello all,
>>
>> I read that InnoDB is now crash safe on slaves in MySQL 5.6. I
>> understand that a way they do this is on committing a transaction on a
>> slave, they store the binary log position in an InnoDB table (which
>> makes that information transactionally maintained). I also understand
>> that this position is stored for each database, as databases may apply
>> the replication log in parallel.
>>
>> Upon recovery of a slave, how does InnoDB report to MySQL where the
>> replication log should resume?
>
> I don't do much with 5.6 source. Grep the sql directory for
> "repository" and then start by looking at rpl_info_factory.cc. The
> vague answer is that the file name offset are read from either a table
> or the info file. I am sure the replication team will respond soon
> with a less vague answer.
>
> --
> Mark Callaghan
> mdcallag@stripped
