An error occurred fetching the project authors.
  1. 16 Dec, 2009 1 commit
  2. 04 Dec, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#45292 orphan binary log created when starting server twice · e362e9a7
      Alfranio Correia authored
      This patch fixes three bugs as follows. First, aborting the server while purging
      binary logs might generate orphan files due to how the purge operation was
      implemented:
      
                (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)
      
            1 - register the files to be removed in a temporary buffer.
            2 - update the log-bin.index.
            3 - flush the log-bin.index.
            4 - erase the files whose names where register in the temporary buffer
            in step 1.
      
      Thus a failure while  executing step 4 would generate an orphan file. Second,
      a similar issue might happen while creating a new binary as follows:
      
                (create routine - sql/log.cc - MYSQL_BIN_LOG::open)
      
            1 - open the new log-bin.
            2 - update the log-bin.index.
      
      Thus a failure while executing step 1 would generate an orphan file.
      
      To fix these issues, we record the files to be purged or created before really
      removing or adding them. So if a failure happens such records can be used to
      automatically remove dangling files. The new steps might be outlined as follows:
      
                (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)
      
            1 - register the files to be removed in the log-bin.~rec~ placed in
            the data directory.
            2 - update the log-bin.index.
            3 - flush the log-bin.index.
            4 - delete the log-bin.~rec~.
      
                (create routine - sql/log.cc - MYSQL_BIN_LOG::open)
      
            1 - register the file to be created in the log-bin.~rec~
            placed in the data directory.
            2 - open the new log-bin.
            3 - update the log-bin.index.
            4 - delete the log-bin.~rec~.
      
                (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file)
      
            1 - open the log-bin.index.
            2 - open the log-bin.~rec~.
            3 - for each file in log-bin.~rec~.
              3.1 Check if the file is in the log-bin.index and if so ignore it.
              3.2 Otherwise, delete it.
      
      The third issue can be described as follows. The purge operation was allowing
      to remove a file in use thus leading to the loss of data and possible
      inconsistencies between the master and slave. Roughly, the routine was only
      taking into account the dump threads and so if a slave was not connect the
      file might be delete even though it was in use.
      e362e9a7
  3. 05 Apr, 2008 1 commit
  4. 03 Apr, 2008 1 commit
  5. 01 Apr, 2008 1 commit
  6. 31 Mar, 2008 1 commit
  7. 29 Mar, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #35675 reset master finds assert if a binlog file can not be deleted · ba7b1a7e
      aelkin/andrei@mysql1000.(none) authored
      If a binlog file is manually replaced with a namesake directory the internal purging did
      not handle the error of deleting the file so that eventually
      a post-execution guards fires an assert.
      
      Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error 
      at an attempt to delete it.
      The same applied to the index file deletion.
      
      The cset carries pieces of manual merging.
      ba7b1a7e
  8. 17 Mar, 2008 1 commit
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #18199 PURGE BINARY LOGS fails silently with missing logs; · 18dab9d7
      aelkin/andrei@mysql1000.(none) authored
      Bug #18453  Warning/error message if there is a mismatch between ...
       
      There were three problems:
       
       1. the reported lack of warnings for the BEFORE syntax of PURGE;
       2. the similar lack of warnings for the TO syntax;
       3. incompatible behaviour between the two in that the latter blanked out
          regardlessly of presence or lack the actual file corresponding to
          an index record; the former version gave up at the first mismatch.
      
      fixed with deploying the warning's generation and synronizing logics of 
      purge_logs() and purge_logs_before_date().
      my_stat() is called in either of two branches of purge_logs() (responsible
      for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax.
      If there is no actual binlog file, my_stat returns NULL and my_delete is
      not invoked.
      A critical error is reported to the user if a file from the index
      could not be retrieved info about or deleted with a system error code
      different than ENOENT.
      18dab9d7