Sergei Golubchik <serg@mariadb.org> 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.