• Marko Mäkelä's avatar
    MDEV-28495 InnoDB corruption due to lack of file locking · 0ee1082b
    Marko Mäkelä authored
    Starting with commit da094188 (MDEV-24393),
    MariaDB will no longer acquire advisory file locks on InnoDB data
    files by default, because it would create a large number of
    entries in Linux /proc/locks.
    
    The motivation for acquiring the file locks is to prevent accidental
    concurrent startup of multiple server processes on the same data files.
    Such mistake still turns out to be relatively common, based on
    corruption bug reports from the community.
    
    To prevent corruption due to concurrent startup attempts, the
    Aria storage engine would unconditionally acquire an advisory lock
    on one of its log files.
    
    Solution: InnoDB will always lock its system tablespace files.
    (Ever since commit 685d958e
    the InnoDB log file will not necessarily be open while the
    server is running, because it can be accessed via memory-mapped I/O.)
    
    If more protection is desired, then the option --external-locking
    can be used.
    
    The mandatory advisory lock also fixes intermittent failures of
    some crash recovery tests. It turns out that when the mtr test harness
    kills and restarts the server, it will not actually ensure that the
    old process has terminated before starting the new one.
    0ee1082b
fil0fil.cc 142 KB