On Fri, Oct 9, 2009 at 8:41 AM, Jay Pipes <jay.pi...@sun.com> wrote: > MARK CALLAGHAN wrote: >> >> On Wed, Oct 7, 2009 at 1:45 PM, Monty Taylor <mord...@inaugust.com> wrote: >>> >>> Brian Aker wrote: >>>> >>>> Hi! >>>> >>>> Should "DROP TABLE IF EXISTS" end up in the replication log even if the >>>> table did not exist on the master? >>> >>> I do not believe it should. The replication log in Drizzle has been >>> described to me as being a record of changes made to the master, rather >>> than being a record of requests made of the master. >>> >>> If it is a record of changes made, then what should be logged here is >>> any changes in the state of the master as the result of this statement. >>> If the table did not exist, then no changes would have been made, and >>> therefore nothing should go in to the log. >> >> Monty, >> >> If by doing this you are committed to closing the race conditions that >> make some actions (including DDL) non-atomic and introduce differences >> between master and slave, then I won't mind. > > Hi Mark! > > Could you elaborate some more please? I'm not intimately familiar with the > race conditions. Can you point me to a MySQL bug report or a piece of the > code we should look at? Is this related to MyISAM/HEAP and not InnoDB or is > it related to all engines? Is the race condition related to the MySQL > binlog? Is it related to the XA code in MySQL?
It is in most engines because of FRM files. I think Drizzle removed them. In non-Drizzle where FRM files exist: 1) create table has two steps (create FRM, create table in the storage engine) 2) drop table has two steps (create FRM, drop table in the storage engine) 3) a lot of other DDL has two steps (update FRM, do DDL in the storage engine) It is not good when InnoDB and the MySQL dictionary (FRM files) don't agree. The two steps are not performed atomically. I have witnessed replication halt on a slave because of a crash during 1) or 2) and we even added code to InnoDB to recover from that case. I wonder whether partitioning increases the opportunity for a problem? There are other opportunities for slave replication state to get out of sync in official MySQL because the state files are updated after commit (commit, crash, no state file update is not good). Drizzle doesn't have that problem because you are redoing replication. -- Mark Callaghan mdcal...@gmail.com _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
