View Issue Details

IDProjectCategoryView StatusLast Update
0004135SymmetricDSBugpublic2022-08-08 14:01
Reporterpmarzullo Assigned To 
Prioritynormal 
Status closedResolutionunable to reproduce 
Product Version3.11.0 
Summary0004135: MariaDB key change from auto-increment column needs to remove auto-increment before removing primary key
DescriptionHello!

I had a case where I think that SymmetricDS has a bug.

I have two databases MariaDB 10.2, they are replicated like (master -> slave) with SymmetricDS 3.10.3 since a while.

Some time ago I changed the primary key of one table of the master database, the setup kept working. Nothing wrong..

Yesterday I created a new table and did a reload of the data so SymmetricDS would sync the data of the new table.

I forgot that initial.load.create.first was set to true on the master, so SymmetricDS sent the commands do create the tables.

The problem was:

SymmetricDS detected that my old table was diferent at the slave (as a I had the primary key changed) and tried to alter the table to reflect the state of the master.

The SQL generated would drop the primary key and create the new primary key as the master. But, this has a problem.

The old primary key was AUTO INCREMENT, so when Symmetric tried to DROP PRIMARY KEY the default MariaDB error

"Incorrect table definition; there can be only one auto column and it must be defined as a key"

was triggerd because a table cannot have a AUTO INCREMENT field that is not a key.

All the syncing was freezed as the error would never be fixed by itself.

I think that SymmetricDS needs to first check if the primary key that will be droped has a AUTO_INCREMENT field and if yes, perform an ALTER TABLE first to remove the AUTO INCREMENT of the field.

What do you think?
Tagsdialect: mysql/mariadb

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-10-30 16:01 pmarzullo New Issue
2019-10-30 16:01 pmarzullo Tag Attached: dialect: mysql/mariadb
2022-08-08 14:01 emiller Status new => closed
2022-08-08 14:01 emiller Resolution open => unable to reproduce