MySQL 5.6.14 Source Code Document
 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Friends Macros Groups Pages
Dblqh::LogPageRecord Struct Reference

#include <Dblqh.hpp>

Public Attributes

UintR logPageWord [8192]

Detailed Description

These are the 8 k pages used to store log records before storing them in the file system. Since 64 kbyte is sent to disk at a time it is necessary to have at least 4*64 kbytes of log pages. To handle multiple outstanding requests we need some additional pages. Thus we allocate 1 mbyte to ensure that we do not get problems with insufficient number of pages.

Definition at line 1727 of file Dblqh.hpp.

Member Data Documentation

UintR Dblqh::LogPageRecord::logPageWord[8192]

This variable contains the pages that are sent to disk.

All pages contain a header of 12 words:

  • WORD 0: CHECKSUM Calculated before storing on disk and checked when read from disk.
  • WORD 1: LAP How many wraparounds have the log experienced since initial start of the system.
  • WORD 2: MAX_GCI_COMPLETED Which is the maximum gci which have completed before this page. This gci will not be found in this page and hereafter in the log.
  • WORD 3: MAX_GCI_STARTED The maximum gci which have started before this page.
  • WORD 4: NEXT_PAGE Pointer to the next page. Only used in main memory
  • WORD 5: PREVIOUS_PAGE Pointer to the previous page. Currently not used.
  • WORD 6: VERSION NDB version that wrote the page.
  • WORD 7: NO_LOG_FILES Number of log files in this log part.
  • WORD 8: CURRENT PAGE INDEX This keeps track of where we are in the page. This is only used when pages is in memory.
  • WORD 9: OLD PREPARE FILE NO This keeps track of the oldest prepare operation still alive (not committed or aborted) when this mbyte started.
  • WORD 10: OLD PREPARE PAGE REF File page reference within this file number. Page no + Page index. If no prepare was alive then these values points this mbyte.
  • WORD 11: DIRTY FLAG = 0 means not dirty and = 1 means the page is dirty. Is used when executing log when a need to write invalid commit records arise.

The remaining 2036 words are used for log information, i.e. log records.

A log record on this page has the following layout:

  • WORD 0: LOG RECORD TYPE The following types are supported:
    • PREPARE OPERATION An operation not yet committed.
    • NEW PREPARE OPERATION A prepared operation already logged is inserted into the log again so that the log tail can be advanced. This can happen when a transaction is committed for a long time.
    • ABORT TRANSACTION A previously prepared transaction was aborted.
    • COMMIT TRANSACTION A previously prepared transaction was committed.
    • INVALID COMMIT A previous commit record was invalidated by a subsequent system restart. A log record must be invalidated in a system restart if it belongs to a global checkpoint id which is not included in the system restart. Otherwise it will be included in a subsequent system restart since it will then most likely belong to a global checkpoint id which is part of that system restart. This is not a correct behaviour since this operation is lost in a system restart and should not reappear at a later system restart.
    • COMPLETED GCI A GCI has now been completed.
    • FRAGMENT SPLIT A fragment has been split (not implemented yet)
    • FILE DESCRIPTOR This is always the first log record in a file. It is always placed on page 0 after the header. It is written when the file is opened and when the file is closed.
    • NEXT LOG RECORD This log record only records where the next log record starts.
    • NEXT MBYTE RECORD This log record specifies that there are no more log records in this mbyte.

A FILE DESCRIPTOR log record continues as follows:

  • WORD 1: NO_LOG_DESCRIPTORS This defines the number of descriptors of log files that will follow hereafter (max 32). the log descriptor will describe information about max_gci_completed, max_gci_started and log_lap at every 1 mbyte of the log file since a log file is 16 mbyte always, i need 16 entries in the array with max_gci_completed, max_gci_started and log_lap. thus 32 entries per log file descriptor (max 32*48 = 1536, always fits in page 0).
  • WORD 2: LAST LOG FILE The number of the log file currently open. This is only valid in file 0.
  • WORD 3 - WORD 18: MAX_GCI_COMPLETED for every 1 mbyte in this log file.
  • WORD 19 - WORD 34: MAX_GCI_STARTED for every 1 mbyte in this log file.

Then it continues for NO_LOG_DESCRIPTORS until all subsequent log files (max 32) have been properly described.

A PREPARE OPERATION log record continues as follows:

  • WORD 1: LOG RECORD SIZE
  • WORD 2: HASH VALUE
  • WORD 3: SCHEMA VERSION
  • WORD 4: OPERATION TYPE = 0 READ, = 1 UPDATE, = 2 INSERT, = 3 DELETE
  • WORD 5: NUMBER OF WORDS IN ATTRINFO PART
  • WORD 6: KEY LENGTH IN WORDS
  • WORD 7 - (WORD 7 + KEY_LENGTH - 1) The tuple key
  • (WORD 7 + KEY_LENGTH) - (WORD 7 + KEY_LENGTH + ATTRINFO_LENGTH - 1) The attrinfo

A log record can be spread in several pages in some cases. The next log record always starts immediately after this log record. A log record does however never traverse a 1 mbyte boundary. This is used to ensure that we can always come back if something strange occurs in the log file. To ensure this we also have log records which only records the next log record.

A COMMIT TRANSACTION log record continues as follows:

  • WORD 1: TRANSACTION ID PART 1
  • WORD 2: TRANSACTION ID PART 2
  • WORD 3: FRAGMENT ID OF THE OPERATION
  • WORD 4: TABLE ID OF THE OPERATION
  • WORD 5: THE FILE NUMBER OF THE PREPARE RECORD
  • WORD 6: THE STARTING PAGE NUMBER OF THE PREPARE RECORD
  • WORD 7: THE STARTING PAGE INDEX OF THE PREPARE RECORD
  • WORD 8: THE STOP PAGE NUMBER OF THE PREPARE RECORD
  • WORD 9: GLOBAL CHECKPOINT OF THE TRANSACTION

An ABORT TRANSACTION log record continues as follows:

  • WORD 1: TRANSACTION ID PART 1
  • WORD 2: TRANSACTION ID PART 2

A COMPLETED CGI log record continues as follows:

  • WORD 1: THE COMPLETED GCI

A NEXT LOG RECORD log record continues as follows:

  • There is no more information needed. The next log record will always refer to the start of the next page.

A NEXT MBYTE RECORD log record continues as follows:

  • There is no more information needed. The next mbyte will always refer to the start of the next mbyte.

Definition at line 1898 of file Dblqh.hpp.


The documentation for this struct was generated from the following file: