Announcement

Announcement Module
Collapse
No announcement yet.

Question about innodb's implementation for flushing dirty pages to data files

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Question about innodb's implementation for flushing dirty pages to data files

    dear all:

    i have two questions about innodb's implementation for flushing dirty pages to data files!

    1.As we all known ,innodb use a transaction log[redo log] to act as a permenent record for commited transaction,

    Once the log is safely on disk, the transactions are permanent, InnoDB uses a background thread

    to flush the changes to the data files intelligently.And Once the recored is updated ,mysql will mark the related

    data page in buffer pool as dirty.
    [From High Performance mysql].

    So my question is

    what does [a background thread] do with the dirty pages ? does the information in

    transaction log enough for that thread to update related data files in filesystem!

    2.As mysql use MVCC to supply multi-versin data in tablespace[on disk],,and once we update the

    record,mysql will mark the related data page in bufferpool as dirty page!

    so my question is

    what's the relation between the mvcc in filesystem and dirty page in buffer pool!

    and when does mysql write the new multi-version data to the filesystem as writing to the filesystem is a

    time-consuming job!

    [IMG]index.php/fa/66/0/[/IMG]

    The picture is what i understand ,does it right!
    Thanks in advance!

  • #2
    I am not sure I understand your question clearly.

    If you update a row, the page is marked dirty.
    If you commit the transaction, the txn log will contain information needed to re-do the modification.
    But the page might not be written yet.
    After a checkpoint, the page is guaranteed to be written.
    It might be written by the background thread at a convenient time, or it might be written forcibly during the checkpoint.

    You can read up on "fuzzy checkpoints" here:

    http://dev.mysql.com/doc/mysql-backup-excerpt/5.0/en/innodb- checkpoints.html

    Please ignore that page's advice about how large to make the size of the log. It is wrong.

    Comment


    • #3
      Thanks a million for your reply firstly ,There are some questions exists however!

      As the dirty page will be written to disk by some background thread at some time

      and there is some backgroud thread responsible for writing the updated Page to [Double Write Buffer] according [Redo Log],

      does that mean one update will bring twice write final data file on disk,
      1. updating disk file by [dirty page] in buffer pool updating disk file by [redo log]
      By the way,does the picture i present tell the right thing![/b]

      Comment


      • #4
        I'm not sure how you understand the picture. It is the right kind of idea but I'm not sure if we have the same idea of what it means, and this is a complicated topic to explain. So I can't say that it is WRONG, but I am not sure that means you are 100% correct.

        Now, about writing pages. You are correct that the page is written twice to disk: once to the doublewrite buffer, then once to its real location. This is to protect against partial page writes. However, when the dirty page is flushed from the buffer pool to disk, the redo log is not involved. The redo log is only there in case recovery is needed (if there is a crash).

        Comment

        Working...
        X