From: Rick James
Date: October 3 2012 3:42pm
Subject: RE: making a storage engine crash safe on a slave in MySQL 5.6
List-Archive: http://lists.mysql.com/internals/38592
Message-Id: <2E7DD7ADE53B044C8C8BCD9C5829E1EB148CF92165@SP2-EX07VS01.ds.corp.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As I understand it, it is not quite that...

The transaction must get into the Slave's relay log before returning from t=
he COMMIT.  (That's not the same as "committing".)



> -----Original Message-----
> From: Zardosht Kasheff [mailto:zardosht@stripped]
> Sent: Wednesday, October 03, 2012 8:16 AM
> To: internals@stripped
> Subject: making a storage engine crash safe on a slave in MySQL 5.6
>=20
> Hello all,
>=20
> 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.
>=20
> Upon recovery of a slave, how does InnoDB report to MySQL where the
> replication log should resume?
>=20
> Can another storage engine similarly make itself crash safe on a slave?
> Will there be any issues with multiple storage engines doing so?
>=20
> Thanks
> -Zardosht
>=20
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals