LOG Disable

  • Filter
  • Time
  • Show
Clear All
new posts

  • LOG Disable

    I am looking at the source tree for Percona 5.5.

    Anybody have ideas on how to make changes to trx so that commits for a given database or table are NOT written to ibdata0 and ibdata1, just written directly to the database.

    I am looking to have one INNODB database execute on fast RAMDISK while another operates on RAID10 long term storage. Since speed is paramount and transaction integrity is not needed for ramdisk tables, I want to disable logging for those tables on ramdisk.

    I would love to leave normal logging in place for ibdata0 and ibdata1 but selectively disable it for a given database or tables (maybe based on table name).

  • #2
    ibdata0 is the database itself. You want to disable the double write buffer, which is disabled with innodb_doublewrite=0. It might help to search for innodb_doublewrite in the code.


    • #3
      gmouse, thanks for the answer, but there are some things that
      I cannot make sense of in your comment.

      ibdata0 is NOT the database itself. I am using innodb_file_per_table which means each table/index is put into a tablexxx.ibd file.

      I cannot just turn off double write since it would affect ALL tables and databases and I am looking to have normal innodb operations on the RAID10 files, but Limited activity against the RAMDISK tables.

      Of course, I can just let the RAMDISK behave normally, but the ibdata0 and ibdata1 log entries for the RAID10 tables would also get entries by the RAMDISK tables, thus negating the benefits of RAMDISK speed.

      So my only option to start with is to place the ibdata0 and ibdata1 LOG files on the RAMDISK as well and just suffer the problems of losing transaction data on system crashes.

      But by inserting some logic into the TRX commit code (maybe), I could just let INNODB operate normally but then it would not log for tables on RAMDISK.

      Anybody got some ideas, since it is really a shame that innodb log/transaction files are not PER database or PER table.



      • #4
        So there is the REDO log and the UNDO log in the system tablespace.

        So how to intercept these calls/writes for specific tables/databases.



        • #5
          What you're asking is probably a massively complex project, maybe even impossible. InnoDB is designed to be the ACID, the whole ACID, and nothing but the ACID. It generally does not have any features or architectural decisions geared towards anything but ACID. All of the data it has on disk is transactional and ACID compliant. There is basically nothing that's not ACID. Even the changes to the transaction log files themselves are.

          ibdata0 IS part of the database, even in file-per-table mode, and all changes to it are done in an ACID way.

          I think you need to pursue alternative architectures to meet your goals.


          • #6

            I understand that everything is ACID, until you set
            the innodb_flush_log_at_trx_commit <> 1.

            There have been ramblings of stuff about having undo logs, I/O reduction stuff on SSD, etc.

            It seems like a big research project to figure out the actual layout of the various entities inside the engine to figure out where I can insert a data blocker so that data does not flow to the log/undo/redo areas.

            I guess at this point, I will look for another architectural option. I could not get good performance out of NDB or MEMORY/HEAP.

            Oops, I made a mistake, I indicated that idbdata0 was NOT part of the table, I should have said ib_log0, not ibdata0. Sorry Mr G Mouse, my bad.

            Who has a good architectural diagram of all of the entities and how they relate to each other.


            • #7
              Percona Server actually allows you to put the doublewrite buffer into its own file, by the way. There is a diagram on http://www.mysqlperformanceblog.com/2010/04/26/xtradb-innodb -internals-in-drawing/


              • #8
                Hello everybody:

                I just wanted to give a report back to

                The best solution was to not use INNODB but MariaDB Aria engine which can control transaction logging and binary logging to meet requirements.

                Especially, than you Mr gmouse for your answers.

                MD in NYC