[Maria-developers] Fwd: crash in slave replication with XA transaction
Hello all, We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work? -Zardosht ---------- Forwarded message ---------- From: Rich Prohaska <prohaska@tokutek.com> Date: Mon, Jun 4, 2012 at 1:23 PM Subject: crash in slave replication with XA transaction To: internals@lists.mysql.com Hello, We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage engines. When one runs a transaction that inserts into an InnoDB table and a TokuDB table, the commit crashes the replication slave at log.cc line 6602 because cache_mngr == NULL. We found a pattern in various log functions in log.cc that calls binlog_setup_trx_data to initialize the txn state. This change fixes our immediate problem. $ diff log.cc.orig log.cc 6595a6596,6597
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Is this a correct fix? If so, are there other places that need a similar change? Thanks Rich Prohaska The transaction is: create table t1 (a int primary key) engine=innodb; create table t2 (a int primary key) engine=tokudb; set autocommit=0; insert into t1 values (1); insert into t2 values (2); commit; the slave crashes while handling the commit binlog entry. -- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/internals
We made a slightly different change for MariaDB 5.5.24 in the TC_LOG_BINLOG::log_and_order function. $ diff log.cc.orig log.cc 7424a7425,7426
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Is this correct? Is this sufficient? Thanks RIch Prohaska On Tue, Jun 5, 2012 at 10:14 AM, Zardosht Kasheff <zardosht@gmail.com> wrote:
Hello all,
We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?
-Zardosht
---------- Forwarded message ---------- From: Rich Prohaska <prohaska@tokutek.com> Date: Mon, Jun 4, 2012 at 1:23 PM Subject: crash in slave replication with XA transaction To: internals@lists.mysql.com
Hello,
We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage engines. When one runs a transaction that inserts into an InnoDB table and a TokuDB table, the commit crashes the replication slave at log.cc line 6602 because cache_mngr == NULL. We found a pattern in various log functions in log.cc that calls binlog_setup_trx_data to initialize the txn state.
This change fixes our immediate problem.
$ diff log.cc.orig log.cc 6595a6596,6597
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Is this a correct fix? If so, are there other places that need a similar change?
Thanks Rich Prohaska
The transaction is: create table t1 (a int primary key) engine=innodb; create table t2 (a int primary key) engine=tokudb; set autocommit=0; insert into t1 values (1); insert into t2 values (2); commit;
the slave crashes while handling the commit binlog entry.
-- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/internals
Hello all, Does anyone have any feedback on this issue? We currently have a customer affected by this issue. Thanks -Zardosht On Tue, Jun 5, 2012 at 11:14 AM, Rich Prohaska <prohaska@tokutek.com> wrote:
We made a slightly different change for MariaDB 5.5.24 in the TC_LOG_BINLOG::log_and_order function.
$ diff log.cc.orig log.cc 7424a7425,7426
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Is this correct?
Is this sufficient?
Thanks RIch Prohaska
On Tue, Jun 5, 2012 at 10:14 AM, Zardosht Kasheff <zardosht@gmail.com> wrote:
Hello all,
We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?
-Zardosht
---------- Forwarded message ---------- From: Rich Prohaska <prohaska@tokutek.com> Date: Mon, Jun 4, 2012 at 1:23 PM Subject: crash in slave replication with XA transaction To: internals@lists.mysql.com
Hello,
We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage engines. When one runs a transaction that inserts into an InnoDB table and a TokuDB table, the commit crashes the replication slave at log.cc line 6602 because cache_mngr == NULL. We found a pattern in various log functions in log.cc that calls binlog_setup_trx_data to initialize the txn state.
This change fixes our immediate problem.
$ diff log.cc.orig log.cc 6595a6596,6597
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Is this a correct fix? If so, are there other places that need a similar change?
Thanks Rich Prohaska
The transaction is: create table t1 (a int primary key) engine=innodb; create table t2 (a int primary key) engine=tokudb; set autocommit=0; insert into t1 values (1); insert into t2 values (2); commit;
the slave crashes while handling the commit binlog entry.
-- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe: http://lists.mysql.com/internals
Hi!
"Zardosht" == Zardosht Kasheff <zardosht@gmail.com> writes:
Zardosht> Hello all, Zardosht> We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work? Zardosht> -Zardosht <cut> Zardosht> We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage Zardosht> engines. When one runs a transaction that inserts into an InnoDB Zardosht> table and a TokuDB table, the commit crashes the replication slave at Zardosht> log.cc line 6602 because cache_mngr == NULL. We found a pattern in Zardosht> various log functions in log.cc that calls binlog_setup_trx_data to Zardosht> initialize the txn state. Zardosht> This change fixes our immediate problem. Zardosht> $ diff log.cc.orig log.cc Zardosht> 6595a6596,6597
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Zardosht> Is this a correct fix? If so, are there other places that need a Zardosht> similar change? I would just add a call to if (thd->binlog_setup_trx_data()) DBUG_RETURN(1); Just before calling: binlog_cache_mngr *cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(thd, binlog_hton); There is no need to test for value of thd_get_ha_data(thd,binlog_hton) as the function thd->binlog_setup_trx_data() already does that. There is a couple of other functions that also calls thd_get_ha_data(thd, binlog_hton) and uses this without checking if the value returned is == NULL . You probably want to add the same code in these functions. Regards, Monty
Hello, Thanks for the feedback on how to fix our replication slave crash. I hacked the mariadb 5.5.23 and ended up with the attached patch. Rich Prohaska On Fri, Jun 8, 2012 at 1:37 PM, Michael Widenius <monty@askmonty.org> wrote:
Hi!
"Zardosht" == Zardosht Kasheff <zardosht@gmail.com> writes:
Zardosht> Hello all, Zardosht> We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?
Zardosht> -Zardosht
<cut> Zardosht> We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage Zardosht> engines. When one runs a transaction that inserts into an InnoDB Zardosht> table and a TokuDB table, the commit crashes the replication slave at Zardosht> log.cc line 6602 because cache_mngr == NULL. We found a pattern in Zardosht> various log functions in log.cc that calls binlog_setup_trx_data to Zardosht> initialize the txn state.
Zardosht> This change fixes our immediate problem.
Zardosht> $ diff log.cc.orig log.cc Zardosht> 6595a6596,6597
if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();
Zardosht> Is this a correct fix? If so, are there other places that need a Zardosht> similar change?
I would just add a call to
if (thd->binlog_setup_trx_data()) DBUG_RETURN(1);
Just before calling:
binlog_cache_mngr *cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(thd, binlog_hton);
There is no need to test for value of thd_get_ha_data(thd,binlog_hton) as the function thd->binlog_setup_trx_data() already does that.
There is a couple of other functions that also calls thd_get_ha_data(thd, binlog_hton) and uses this without checking if the value returned is == NULL . You probably want to add the same code in these functions.
Regards, Monty
Hi!
"Rich" == Rich Prohaska <prohaska@tokutek.com> writes:
Rich> Hello, Rich> Thanks for the feedback on how to fix our replication slave crash. Rich> I hacked the mariadb 5.5.23 and ended up with the attached patch. Rich> Rich Prohaska
--- log.cc.orig 2012-06-08 16:36:34.007231363 -0400 +++ log.cc 2012-06-08 16:36:36.218354938 -0400 @@ -1838,6 +1838,7 @@ { int error= 0; DBUG_ENTER("binlog_commit"); + thd->binlog_setup_trx_data();
It would be good to have error checking if the above failed.
binlog_cache_mngr *const cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(thd, binlog_hton);
@@ -1894,6 +1895,7 @@ { DBUG_ENTER("binlog_rollback"); int error= 0; + thd->binlog_setup_trx_data();
It would be good to have error checking if the above failed. <cut>
@@ -4846,6 +4848,7 @@ if (binlog_table_maps == 0) binlog_start_trans_and_stmt();
+ this->binlog_setup_trx_data(); binlog_cache_mngr *const cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(this, binlog_hton);
I would move the call this->binlog_setup_trx_data() before if (binlog_table_maps == 0) binlog_start_trans_and_stmt(); As binlog_start_trans_and_stmt() will also need the structure.
@@ -4941,6 +4944,7 @@ { DBUG_ENTER("MYSQL_BIN_LOG::remove_pending_rows_event");
+ thd->binlog_setup_trx_data();
Add error checking. Same to other places. Otherwise ok! Regards, Monty
participants (3)
-
Michael Widenius -
Rich Prohaska -
Zardosht Kasheff