This is after crash recovery. Crash recovery is done at startup to
make InnoDB consistent. At the conclusion of that there might be
InnoDB transactions in state PREPARED. The following is then done.
The list is used to determine what to do with transactions in state PREPARED.
* if it is on the list it is committed
* otherwise it is rolled back
On Sun, Oct 10, 2010 at 7:25 PM, Haihao Tang <haihaot@stripped> wrote:
> Thanks Mark. Under your guidance, I even more understood internal XA.
> But I still have one quetion:
> In crash recovery, mysqld uses the list of committed transactions from
> the current binlog to recover. Why not use transaction log to recover
> the crashed transaction ? I am not familiar with InnoDB -_-!
> 2010/10/8 MARK CALLAGHAN <mdcallag@stripped>:
>> Internal XA is used to keep the replication binlog and Innodb in sync
>> after a crash. In this case the commit protocol is:
>> 1) prepare InnoDB (force changes in transaction log to disk, mark
>> transaction as "prepared")
>> 2) write transaction changes to binlog including XID event
>> 3) commit InnoDB (write and force "commit" record to transaction log)
>> If mysqld crashes after step 2, then the "prepared" InnoDB
>> transactions will be committed during crash recovery. In crash
>> recovery, mysqld determines the list of committed transactions from
>> the current binlog and uses that to determine what to do with
>> "prepared" transactions.
>> The work above requires 3 fsync calls in the normal case. The fsyncs
>> done in steps #1 and #3 can be shared across many concurrent
>> transactions. The fsync done in step #2 cannot today -- unless you use
>> the Google patch. I know that MariaDB is very interested in changing
>> that. I suspect that MySQL is as well.
>> On Thu, Oct 7, 2010 at 7:30 PM, Haihao Tang <haihaot@stripped> wrote:
>>> I am recently in the study of MySQL XA. In the section
>>> "Restrictions on XA Transactions" of MySQL reference 5.1
>>> (http://dev.mysql.com/doc/refman/5.1/en/xa-restrictions.html), it
>>> For “external XA,” a MySQL server acts as a Resource
> Manager and
>>> client programs act as Transaction Managers. For “Internal XA”,
>>> storage engines within a MySQL server act as RMs, and the server
>>> itself acts as a TM.
>>> I understand the "external XA" where MySQL server acts as RM,
>>> the "internal XA" confuse me. How does MySQL server itself act as a TM
>>> and storage engine (It could be only InnoDB, right?) act as RM? How
>>> does MySQL server manage storage engines to accomplish a DTP? Any
>>> Thank you!
>>> Best Regards,
>>> MySQL Internals Mailing List
>>> For list archives: http://lists.mysql.com/internals
>>> To unsubscribe: http://lists.mysql.com/internals?unsub=1
>> Mark Callaghan