On Fri, Jan 16, 2009 at 12:29 AM, Brian Aker <br...@tangent.org> wrote: > Hi! > > On Jan 16, 2009, at 12:18 AM, Mats Kindahl wrote: > >> Suppose that the row id is just an auto_inc sequence added as a primary >> key to >> the table. In that case there will be problems with finding the right rows >> to >> update or delete (as Kristian already pointed out) and the slave will stop >> irrecoverably whenever a change is made on the slave in a different order >> from >> what is used on the master. This might not seem like a big deal, but any >> form of >> restore of a slave from a backup, or even when bootstrapping the slave, >> require >> the rows to be inserted in the same order on both master and slave. This >> is not >> practical. > > The last applied image is all you need for a particular column, not the > transformation step. > >> I agree with what you say later, that replication cannot be free, but in >> my >> opinion, the cost is an effort on designing the database to be replicated, >> not >> by adding any hidden fields. > > What is the solution? > > There is a radical solution. Dump every single engine and just transfer the > transaction logs of one particular engine (though this only works if all of > the transaction is written to the log). > > Everything about replication is impractical in the end, but you can't do > without it. Keeping a hidden value on the row and an index on it (or using > the main primary key) is really the only way to do this. > > Cheers, > -Brian > >> >> >> Just my few cents, >> Mats Kindahl >> >> Brian Aker wrote: >>> >>> Hi! >>> >>> It keeps coming back to the fact that to really have replication work >>> and correctly resolve in most cases we really need two things. >>> >>> We need a rowid, and we need a timestamp. The rowid makes it so that we >>> are updating the right field and the timestamp allows us to handle some >>> large class of conflict resolutions (far from all, but that is a >>> different topic). >>> >>> We keep circling around the issue of primary key and using that as this >>> rowid. The problem is, that not all tables have such a key, and in many >>> cases it would be suboptimal to use this key as the primary key. >>> >>> What if instead we create two hidden fields that we do not normally >>> display? Sure, we can make them available if they are asked for, but >>> otherwise we just keep them from visual site. We can drop the fields if >>> a user makes a table as "do not replicate" but otherwise we will insert >>> them. >>> >>> Thoughts? >>> >>> One thing... skipping rowids is always going to keep a replication >>> design pretty much half assed, and is going to lead to all of the >>> problems we tend to see crop up today. The other DBs have solved this by >>> keeping some sort of public or private key, we have to find a solid >>> solution for this problem going forward. >>> >>> Worse case? I predict we need twenty-four bytes per row (16 for the >>> rowid, and 8 for the timestamp). >>> >>> Cheers, >>> -Brian >>> >>> -- >>> _______________________________________________________ >>> Brian "Krow" Aker, brian at tangent.org >>> Seattle, Washington >>> http://krow.net/ <-- Me >>> http://tangent.org/ <-- Software >>> _______________________________________________________ >>> You can't grep a dead tree. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> -- >> Mats Kindahl >> Lead Software Developer >> Replication Team >> MySQL AB, www.mysql.com >> <mats.vcf> > > -- > _______________________________________________________ > Brian "Krow" Aker, brian at tangent.org > Seattle, Washington > http://krow.net/ <-- Me > http://tangent.org/ <-- Software > _______________________________________________________ > You can't grep a dead tree. > > > > > _______________________________________________ > 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 >
If the timestamp is based on a wall-clock, then this will still have many problems when used for conflict resolution. At the start of this thread you state that rowid+timestamp are needed for replication. Do you want this for master-slave and multi-master replication, or just for multi-master? -- 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
