On Thu, Aug 14, 2008 at 1:54 PM, Sheeri K. Cabral <[EMAIL PROTECTED]> wrote: > On 8/14/08, Brian Aker <[EMAIL PROTECTED]> wrote: >> >> Hi! >> >> On Aug 14, 2008, at 5:27 AM, Baron Schwartz wrote: >> >>> The problem I'm pointing towards is that currently the synchronization >>> between the binlogs and InnoDB causes a lot of extra fsyncs for each >>> commit. >> >> Unfortunately there is only a couple of solutions for a safe commit. >> >> 1) Let one engine lead the charge on sync (I like this). >> 2) Store binlog in Innodb (Hmmm might work). >> 3) Punt like we did in the past (I dislike this) >> 4) ? >> >> Cheers, >> -Brian > > 2) interesting idea. some things are appealing, others make me cringe. > > If we did this we should put the binlogs in a different ibdata file (even if > the server isn't running innodb_file_per_table). Would PURGE MASTER LOGS > automatically OPTIMIZE the table to get the storage back? Can there be more > than one binary log file in this case?
Well, that sounds like you're thinking of putting the binary logs with the data files -- I think the suggestion was to put them with the innodb log files. What about this idea: put the binary logs, as they currently are (statement-based) in ib_logfile* with the InnoDB logs. Keep the InnoDB log files a circular log as they currently are -- just a lot fatter. Then as checkpointing occurs, move the binlog portion of it out to ordinary binlog files as they currently are. (Otherwise only a very limited amount of binlogs could be kept around.) _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
