[Commits] Rev 4515: MDEV-7179: rpl.rpl_gtid_crash failed in buildbot with Warning: database page corruption or a failed in http://bazaar.launchpad.net/~maria-captains/maria/10.0

knielsen at knielsen-hq.org knielsen at knielsen-hq.org
Tue Nov 25 15:19:11 EET 2014


At http://bazaar.launchpad.net/~maria-captains/maria/10.0

------------------------------------------------------------
revno: 4515
revision-id: knielsen at knielsen-hq.org-20141125131911-poi0zfc8ms5tcnkj
parent: knielsen at knielsen-hq.org-20141125111948-2gpl5eo3rime9yrl
committer: Kristian Nielsen <knielsen at knielsen-hq.org>
branch nick: work-10.0
timestamp: Tue 2014-11-25 14:19:11 +0100
message:
  MDEV-7179: rpl.rpl_gtid_crash failed in buildbot with Warning: database page corruption or a failed
  
  I saw two test failures in rpl.rpl_gtid_crash where we get this in the error
  log:
  
  141123 12:47:54 [Note] InnoDB: Restoring possible half-written data pages 
  141123 12:47:54 [Note] InnoDB: from the doublewrite buffer...
  InnoDB: Warning: database page corruption or a failed
  InnoDB: file read of space 6 page 3.
  InnoDB: Trying to recover it from the doublewrite buffer.
  141123 12:47:54 [Note] InnoDB: Recovered the page from the doublewrite buffer.
  
  This test case deliberately crashes the server, and if this crash happens
  right in the middle of writing a buffer pool page to disk, it is not
  unexpected that we can get a half-written page. The page is recovered
  correctly from the doublewrite buffer.
  
  So this patch adds a suppression for this warning in the error log for this
  test case.
=== modified file 'mysql-test/suite/rpl/r/rpl_gtid_crash.result'
--- a/mysql-test/suite/rpl/r/rpl_gtid_crash.result	2014-11-25 11:19:48 +0000
+++ b/mysql-test/suite/rpl/r/rpl_gtid_crash.result	2014-11-25 13:19:11 +0000
@@ -3,6 +3,7 @@ include/rpl_init.inc [topology=1->2]
 call mtr.add_suppression("Checking table:");
 call mtr.add_suppression("client is using or hasn't closed the table properly");
 call mtr.add_suppression("Table .* is marked as crashed and should be repaired");
+call mtr.add_suppression("InnoDB: Warning: database page corruption or a failed");
 flush tables;
 ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB;
 CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB;

=== modified file 'mysql-test/suite/rpl/t/rpl_gtid_crash.test'
--- a/mysql-test/suite/rpl/t/rpl_gtid_crash.test	2014-11-25 11:19:48 +0000
+++ b/mysql-test/suite/rpl/t/rpl_gtid_crash.test	2014-11-25 13:19:11 +0000
@@ -12,6 +12,11 @@
 call mtr.add_suppression("Checking table:");
 call mtr.add_suppression("client is using or hasn't closed the table properly");
 call mtr.add_suppression("Table .* is marked as crashed and should be repaired");
+# We have seen this warning a couple of times in Buildbot. Since we crash the
+# server deliberately, it seems possible that we could in rare cases crash in
+# the middle of a page write. The page is recovered from the doublewrite
+# buffer ("[Note] InnoDB: Recovered the page from the doublewrite buffer.").
+call mtr.add_suppression("InnoDB: Warning: database page corruption or a failed");
 flush tables;
 
 ALTER TABLE mysql.gtid_slave_pos ENGINE=InnoDB;



More information about the commits mailing list