Stewart Smith wrote:
On Mon, Dec 14, 2009 at 07:34:50PM -0500, Jay Pipes wrote:
Right, but this is NOT what Stewart has proposed for the AlterTable
statement. Stewart (and Stewart, correct me if I'm wrong) would
like to send the *actions* that the master executed for the Alter
Table. I am opposed to this (see link above for the ML post with my
reasons why)
Replicating a before and after image requires engines or database
systems parsing this to know *everything* in the table definition and
correctly look at *everything* and compare it to work out if it can do
the alter operation (especially think about online alter).
As soon as we introduce a new thing into the table structure, all of
these systems instantly and silently break.
For example:
We add a STORAGE property to columns. and storage could be
NULL.. i.e. don't store anything and return a default value.
So if you "ALTER TABLE t1 COLUMN a STORAGE=NULL;" on a master, column
a will always come back with the default value.
If the slave now reads the ALTER, it only knows the old definition of
table, examines everything, does it's work (which could be a no-op, or
there could be other things in the ALTER TABLE statement).
You now have a different master and slave.
If we had a series of modifications, we'd easily be able to detect
this in the slave: we'd have an invalid transformation! We could error
out!
I fail to see your logic here. If you had different proto formats for
the "series of actions" on the master and slave, you'd run into the same
problem. However, this problem actually isn't as much of a problem as
you might think.
As long as the changes you make to the proto add *optional* fields to
the message formats, you won't break a system that has an older version
of the compiled code on it...
It also creates much fewer opportunities for those implementing
replication slaves to get the code wrong. Comparing two tables and
generating the list of operations to run in your engine is fraught
with lots of code and potential bugs (check out the hoops NDB jumps
through to avoid rewriting ALTER table in the MySQL server to be
sane).
What Paul and I are recommending is not that engines would have to do
this, but that *they would have the opportunity to do so if they chose
to*. Again, I believe the confusion is going back to Krow and yourself
not fully reading the long series of posts back and forth describing a
new API for allowing the engine to advise the kernel it would like to
handle a particular statement itself...again, I'm putting together a
summary so we can get this conversation a bit back on track :)
Cheers,
Jay
Now... shipping before and after images as well could be useful...
perhaps slave should error out if start definition is different (and
if start definition is the same but the same sequences of actions
results in a different final proto then something is certainly wrong).
Passing the statement down means that it becomes impossible to
replicate to non-sql systems without a SQL parser for ALTER statements
(which, no doubt, will also be buggy).
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
