maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Sergei Golubchik <serg@xxxxxxxxxxx> writes:

> >     Make it print an error:
> >     "The table 'db.table' has deprecated columns types incompatible
> >     with Row-based replication."
> > 
> >     (the same text with #b, but this time an error instead of a note).
> > 
> 
> I leave it to Kristian...

First, note that this is not just --binlog-format=row, if I understand
correctly. It also seems that --binlog-format=mixed could be affected, if some
particular logging decides to use row-based for a query.

But I think I need an explanation of the original problem to give an informed
opinion.

What happens if for example I take a mysqldump from a table with old DECIMAL
and apply it on a new version server? Will it create a table with new DECIMAL?
Will this break row-based replication between the two servers?

Or does the problem only happen if eg. replicating between different column
definitions? Eg. if replicating from old DECIMAL(10,2) to new DECIMAL (20,4)?

In general, it seems that the first scenario would be pretty bad breakage, and
something to avoid.

But having different table definitions on master and slave is a different
matter, I think, if the user explicitly choose to do this. I would say this is
not something that is officially supported, even if we sometimes try to make
it work. So not a top priority to fix. Though if the different definitions can
somehow arise on its own, due to mysql_upgrade or the like, the matter is of
course more serious.

>> > d. Make the master running with --binlog-format=row refuse to do any
>> > >  INSERT/UPDATE/ALTER or any other queries that can modify a table
>> > >  with the old DECIMAL.
>> 
>> Note that currently such DECIMAL columns work just fine with RBR, so
>> long as the master and slave have the same internal types. So
>> completely disallowing DECIMAL with RBR seems like a breaking and
>> unnecessary change to something which apparently works fine for the
>> user already.
>
> Right. That's why I didn't particularly like that idea. Because quite
> often old DECIMAL works just fine with RBR.

Right.

So what is the problem with this: on the slave, if we get a row event for an
old DECIMAL column, assume it has the same definition (DECIMAL(M1,N1)) as the
one in the slave table. Document that replicating from old DECIMAL to new
DECIMAL of different (M2,N2) type is not supported and can cause problems?

> On the other hand, the master cannot know whether tables on the slave
> are compatible with old DECIMAL or not. And by the time the replicated
> row events reach the slave it's too late to stop them - replication is
> already broken.
>
> At the moment I, frankly, cannot think of any satisfactory solution for
> this.

Well, what about introducing new row events? And these new row events contain
the necessary information for the slave to handle matters correctly?

But, as from above, I'm not sure if that much effort is warranted.

Hope this helps,

 - Kristian.