While replicating from Mariadb 10.1 to MySQL (5.0, 5.1, 5.5) or Mariadb (5.2, 5.5) lower versions, if master's binlog_format is set to row, the replication failure occurs with the following message at slave (show slave status \G;):

Last_Error: Table definition on master and slave does not match: Column 18 type mismatch - received type 19, rtmariadb10.empdetails has type 11


Master: Mariadb 10.1,binlog_format: row ; 
Slave : Mysql 5.1, binlog_format=statement/row/mixed(any one of these) 

Can someone please help to solve this issue?

2 Answers 2


You have encountered one of the reasons for saying that replication must not go from a newer Master to an older Slave.

Would you care to explain the ultimate goal; maybe we can discuss a workaround.

  • Thanks for the reply,My ultimate goal is to solve this error for row based replication , i have searched a lot for a suitable solution to this , but have not been successful to understood what is the cause of this error, it will be a great help if i get this Commented Dec 9, 2016 at 6:06
  • Please step back further -- Why are you attempting to replicate from a new Master to an old Slave.
    – Rick James
    Commented Dec 9, 2016 at 6:10
  • (When I cannot answer a question as asked, I try to provide a workaround. In your situation, I don't have enough knowledge of the bigger picture to know what to "work around".)
    – Rick James
    Commented Dec 9, 2016 at 6:12
  • yes , i got your point. Actually i am working in a team which is upgrading old databases ,both mysql and mariadb to Mariadb 10.1 . So as a part of the process i have to perform a poc to ckeck backward and forward replication between the old and new database versions. That's where i got stucked. Everything is working fine in replication set up except the case where i set master to row based logging , mainly the above mentioned issue is coming in this case Commented Dec 9, 2016 at 6:37
  • You have found an replication situation that will not work. Plan A: Don't replicate from new to old. Plan B: Use SBR, not RBR. Plan C: Something else.
    – Rick James
    Commented Dec 13, 2016 at 21:11

Consider the BLACKHOLE engine in a "relay" server. I don't now the specifics for your situation, but look at:

Master -- new version -->
Relay -- intermediate version -->
Slave -- old version

The Relay would receive the data and pass it on to the Slave without even storing it ("Blackhole"). The hope is that with a suitable intermediate version and/or using SBR on one side and RBR on the other, you can avoid your problem.

  • I never tried, but I think this cannot work in a normal situation. Since BLACKHOLE won't store any row, UPDATEs and DELETEs are never written to the binlog, and never replicated. Commented Jan 18, 2021 at 0:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.