[MDEV-4816] rpl.rpl_trunc_temp fails in 10.0-serg - JIRA

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 10.0.4
Fix Version/s: None
Component/s: None
Labels:
None

Description

rpl.rpl_trunc_temp test fails in 10.0-serg. The failure looks like this:

CURRENT_TEST: rpl.rpl_trunc_temp
mysqltest: In included file "./include/wait_for_binlog_event.inc": 
included from /data0/psergey/dev2/10.0-serg/mysql-test/suite/rpl/t/rpl_trunc_temp.test at line 52:
At line 33: ERROR: failed while waiting for $wait_binlog_event in binlog

In the log, one can see

**** SHOW BINLOG EVENTS on slave ****
binlog_name = 'slave-bin.000001'
SHOW BINLOG EVENTS IN 'slave-bin.000001';
Log_name        Pos     Event_type      Server_id       End_log_pos     Info
slave-bin.000001        4       Format_desc     2       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
slave-bin.000001        248     Gtid_list       2       273     []
slave-bin.000001        273     Binlog_checkpoint       2       312     slave-bin.000001
slave-bin.000001        312     Gtid    1       350     GTID 0-1-1
slave-bin.000001        350     Query   1       446     use `test`; create temporary table t1 (n int)

**** SHOW RELAYLOG EVENTS on slave ****
relaylog_name = 'slave-relay-bin.000002'
SHOW RELAYLOG EVENTS IN 'slave-relay-bin.000002';
Log_name        Pos     Event_type      Server_id       End_log_pos     Info
slave-relay-bin.000002  4       Format_desc     2       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
slave-relay-bin.000002  248     Rotate  1       0       master-bin.000001;pos=4
slave-relay-bin.000002  292     Format_desc     1       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
slave-relay-bin.000002  536     Gtid_list       1       273     []
slave-relay-bin.000002  561     Binlog_checkpoint       1       313     master-bin.000001
slave-relay-bin.000002  601     Gtid    1       351     GTID 0-1-1
slave-relay-bin.000002  639     Query   1       447     use `test`; create temporary table t1 (n int)
slave-relay-bin.000002  735     Gtid    1       485     BEGIN GTID 0-1-2
slave-relay-bin.000002  773     Query   1       572     use `test`; insert into t1 values(1)
slave-relay-bin.000002  860     Query   1       641     COMMIT
slave-relay-bin.000002  929     Gtid    1       679     BEGIN GTID 0-1-3
slave-relay-bin.000002  967     Query   1       756     use `test`; delete from t1
slave-relay-bin.000002  1044    Query   1       825     COMMIT
slave-relay-bin.000002  1113    Gtid    1       863     GTID 0-1-4
slave-relay-bin.000002  1151    Query   1       937     use `test`; truncate t1
slave-relay-bin.000002  1225    Gtid    1       975     GTID 0-1-5
slave-relay-bin.000002  1263    Query   1       1085    use `test`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `t1`

Gliffy Diagrams

Attachments

Issue Links

is part of

MDEV-4786 merge 10.0-monty → 10.0

Closed

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Sergei Petrunia added a comment - 2013-07-25 17:42

Debugging, I found out that

"CREATE TEMPORARY TABLE t1" is successfully replicated and written to slave's binary log
INSERT INTO t1 ... , and other statements are replicated and run on the slave, but they are not written to the binary log
Replication doesn't break - if one runs regular updates they get replicated.
However, some statements, despite being successfully run on the slave, do not end up in slave's binary log

Show

Sergei Petrunia added a comment - 2013-07-25 17:42 Debugging, I found out that "CREATE TEMPORARY TABLE t1" is successfully replicated and written to slave's binary log INSERT INTO t1 ... , and other statements are replicated and run on the slave, but they are not written to the binary log Replication doesn't break - if one runs regular updates they get replicated. However, some statements, despite being successfully run on the slave, do not end up in slave's binary log

8 older comments

Hide

Permalink

Kristian Nielsen added a comment - 2013-09-03 10:12

Something has gone wrong with this issue. The proposed patch was rejected in review:

https://lists.launchpad.net/maria-developers/msg05966.html

However, somehow the patch now nevertheless has ended up in main 10.0

Show

Kristian Nielsen added a comment - 2013-09-03 10:12 Something has gone wrong with this issue. The proposed patch was rejected in review: https://lists.launchpad.net/maria-developers/msg05966.html However, somehow the patch now nevertheless has ended up in main 10.0

Hide

Permalink

Sergei Petrunia added a comment - 2013-09-03 13:54

Kristian, this was intended. See the review request https://lists.launchpad.net/maria-developers/msg05958.html:

> In order to get rid of test failures of 10.0-serg, I have pushed the below patch.

I pushed the patch during your vacation as a way to get the testsuite to pass. After that, you got back and rejected it. I did not act on the rejection, though.

I've checked the current 10.0 - if I revert the patch for mdev-4816 with "patch -R", the testcase starts to fail again.

I could act on your review comments, or you can take over for this issue.

Show

Sergei Petrunia added a comment - 2013-09-03 13:54 Kristian, this was intended. See the review request https://lists.launchpad.net/maria-developers/msg05958.html: > In order to get rid of test failures of 10.0-serg, I have pushed the below patch. I pushed the patch during your vacation as a way to get the testsuite to pass. After that, you got back and rejected it. I did not act on the rejection, though. I've checked the current 10.0 - if I revert the patch for mdev-4816 with "patch -R", the testcase starts to fail again. I could act on your review comments, or you can take over for this issue.

Hide

Permalink

Kristian Nielsen added a comment - 2013-11-27 12:08

I pushed to 10.0-base a patch that corrects the GTID code to clear
the OPTION_BIN_LOG flag rather than set table->no_replicate.

I still think you should revert the original patch in 10.0.

(I tried to merge my 10.0-base patch to 10.0 to check if it solves the
original problem, but there are lots of other unmerged changes that cause a
lot of unrelated conflicts, so I did not manage to complete the merge).

Show

Kristian Nielsen added a comment - 2013-11-27 12:08 I pushed to 10.0-base a patch that corrects the GTID code to clear the OPTION_BIN_LOG flag rather than set table->no_replicate. I still think you should revert the original patch in 10.0. (I tried to merge my 10.0-base patch to 10.0 to check if it solves the original problem, but there are lots of other unmerged changes that cause a lot of unrelated conflicts, so I did not manage to complete the merge).

Hide

Permalink

Sergei Petrunia added a comment - 2013-11-27 19:23

Ok. I'm fine with reverting the patch myself, or having someone else revert it.

I've tried "patch -R" on current 10.0, and it applied. Should I push the reverse patch into 10.0?

Show

Sergei Petrunia added a comment - 2013-11-27 19:23 Ok. I'm fine with reverting the patch myself, or having someone else revert it. I've tried "patch -R" on current 10.0, and it applied. Should I push the reverse patch into 10.0?

Hide

Permalink

Sergei Petrunia added a comment - 2014-01-20 14:38

Pushed a change that reverts my original patch.

Show

Sergei Petrunia added a comment - 2014-01-20 14:38 Pushed a change that reverts my original patch.

rpl.rpl_trunc_temp fails in 10.0-serg

Details

Description

Gliffy Diagrams

Attachments

Issue Links

Activity

People

Dates

Agile