0

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

Here 

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?

Improve this question

2 Answers 2

Reset to default
0

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.

Improve this answer
5
  • 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. 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".) 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. Commented Dec 13, 2016 at 21:11
0

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.

Improve this answer
1
  • 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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.