3 ms·
Could you explain why that technique is only viable for row-based replication? It looks really useful and I don't quite understand enough about the replication
by robbles 13y ago
Could you explain why that technique is only viable for row-based replication?
It looks really useful and I don't quite understand enough about the replication process to see why you couldn't rely on this for mixed replication as well.
- thaumaturgy 13y agoIt might work for mixed too, but I'm not sure. Honestly, I read http://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html http://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html a few times and my eyes glazed over by the end every time. Finally I just decided that I could expect it to work forever with row-based, but I was less certain about whether it would work in mixed, or whether it might change in future versions of MySQL. I consider "I'm not sure what will happen" to be a scary answer in sysops, so I went with row-based.
- blantonl 13y agothis should work in a mixed setup, remember replication in MySQL is pretty much a replay of SQL statements.
- toast0 13y agoI don't know how mixed mode decides to use row or query based for a given query; but if it chose query based, the queries would work, but you wouldn't be resynchronized. (In query based mode, I've done resynchs by iterating over each row, and setting a not super important column to a different value, and then back, including values for all the columns that need to be resynchronized. It's a lot more queries, but it's also easier to rate limit if your tables are big enough that doing it in two queries is going to back everything up)