• unknown's avatar
    WL#3072 - Maria recovery · e0c5a264
    unknown authored
    For this scenario: server crashes (could be because a table is
    corrupted) and Recovery repeatedly crashes on this table. User repairs
    it with maria_chk (as REPAIR TABLE is not possible), restarts the
    server, Recovery runs: for Recovery to not apply old REDOs to this
    repaired table (which would fail: rows have moved), maria_chk sets
    create_rename_lsn to the max value. Later when the server opens
    the table via ha_maria, it sets the LSN to the correct current value.
    
    
    storage/maria/ma_check.c:
      using helper function
    storage/maria/ma_create.c:
      A new helper function which stores the create_rename_lsn 
      into the table's header on disk when we cannot wait for this to happen
      naturally at a later _ma_state_info_write().
    storage/maria/ma_delete_all.c:
      using helper function; so log_data now can be FILEID_STORE_SIZE.
    storage/maria/ma_open.c:
      When opening a transactional table in the server, we discover
      if it has been repaired with maria_chk and if yes, give it a correct
      create_rename_lsn.
    storage/maria/ma_rename.c:
      using helper function
    storage/maria/maria_chk.c:
      By setting create_rename_lsn to the maximum possible LSN, maria_chk
      ensures that old REDOs are not applied to the new table it is
      going to produce.
    storage/maria/maria_def.h:
      new helper function
    e0c5a264
ma_open.c 47.4 KB