[MDEV-2460] LP:967914 - CHECK TABLE persistently reports table corruption after removing Aria logs Created: 2012-03-29  Updated: 2015-02-02  Resolved: 2012-10-04

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: Launchpad

Attachments: XML File LPexportBug967914.xml    

 Description   

This is a sequel of bug #944422, now on

revision-id: <email address hidden>
date: 2012-03-28 13:58:14 +0300
build-date: 2012-03-29 04:40:31 +0400
revno: 3481

After the fix for bug #944422 the behavior changed: now with the same scenario, after Aria logs have been removed and server restarted, CHECK TABLE gives the message "Corrupt / Table is from another system and must be zerofilled or repaired to be usable on this system", as apparently designed.

However, I could not get rid of this message neither by running REPAIR TABLE on the running server, nor by running aria_chk --recover t.MAI.
REPAIR TABLE says
------------------------------+

Table Op Msg_type Msg_text

------------------------------+

test.t repair status OK

------------------------------+

but further CHECK TABLE t again complains about corruption:
----------------------------------------------------------------------------------------------------------------+

Table Op Msg_type Msg_text

----------------------------------------------------------------------------------------------------------------+

test.t check error Table is from another system and must be zerofilled or repaired to be usable on this system
test.t check error Corrupt

----------------------------------------------------------------------------------------------------------------+

aria_chk --recover says

  • recovering (with keycache) Aria-table '/home/elenst/5.3.5-release/data/test/t.MAI'
    Data records: 4
    State updated

But the result is the same, CHECK TABLE still throws the message about corruption.
I could make it stop only by altering the table to another engine and then back.
It differs from the previous behavior when REPAIR TABLE would make the error message go away.
I didn't notice actual corruption though, the table still returns rows, I can insert into it, etc.

The scenario to reproduce is pretty much the same as in bug #944422:

  • start server (no specific server parameters required);
  • run
    mysql -uroot -e "DROP DATABASE IF EXISTS db; CREATE DATABASE db; USE db; \
    CREATE TABLE t ( i INT ) ENGINE=Aria; BEGIN; INSERT INTO t VALUES (1),(2); COMMIT; \
    BEGIN; INSERT INTO t VALUES (1),(2); COMMIT;"
    (adjust connection parameter such as port or socket, if needed)
  • stop server, e.g. using mysqladmin -uroot shutdown
  • remove aria_log* files from the datadir;
  • start server on the same datadir;
  • run
    mysql -uroot -e "CHECK TABLE db.t"
    (it says "Table is from another system and must be zerofilled or repaired to be usable on this system / Corrupt")
  • run
    mysql -uroot -e "REPAIR TABLE db.t"
    ( it says status OK)
  • again, run
    mysql -uroot -e "CHECK TABLE db.t"
    (it still says "Table is from another system and must be zerofilled or repaired to be usable on this system / Corrupt")
  • stop server
  • run aria_chk --recover test/t.MAI
    (it says "State updated")
  • start server
  • run
    mysql -uroot -e "CHECK TABLE db.t"
    (still reports corruption)


 Comments   
Comment by Rasmus Johansson (Inactive) [ 2012-03-30 ]

Launchpad bug id: 967914

Comment by Michael Widenius [ 2012-03-30 ]

Re: CHECK TABLE persistently reports table corruption after removing Aria logs
I had forgot to remove the 'moved' mark from repaired tables. This is now fixed in MariaDB 5.1 and above

Generated at Thu Feb 08 06:42:00 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.