IntroductionMySQL replication slave features a powerful capability of ignoring conflicts like duplicate key error, key not found errors etc. while applying row events. This is exceptionally useful while doing row based replication(RBR) from the master when the slave already contains some data which may conflict with the data coming from the master. In MySQL 5.7 we extend this capability while applying row events from mysql-binlog files using mysqlbinlog tool. This enhancement will prevent such errors from aborting mysql client in case of conflicts like the ones mentioned above.
RationalePrior to MySQL 5.7 we have been using the mysqlbinlog tool as follows.
shell$> mysqlbinlog master.000001|mysql -uroot -hexample.com -ps3cret
This allows us to pipe the output of mysqlbinlog to mysql, and works as long as the row events from the mysqlbinlog do not conflict with …
Read the original article at Limitations of MySQL row-based replication
MySQL offers a few different options for how you perform replication. Statement-based has been around a lot longer, and though it has some troublesome characteristics they’re known well and can be managed. What’s more it supports online schema changes with multi-master active-passive setup. We recommend this solution. Row-based replication is newer. It attempts to address [...]
For more articles like these go to Sean Hull's Scalable Startups
Related posts:[Read more]
With MySQL 5.6 coming closer to its release, I got a chance to
sneak a look into the Row Based Replication (RBR). 5.6 release of
MySQL will be a replication features packed one, and it is for
this reason I write another post on the new enhancements in Row
Based Replication(RBR). RBR provides a safe way of replicating
between master and slave and thats why RBR enhancements become
even more important. RBR in 5.6 is far more optimized than what
it was before and we hope it will be fun to deploy, maintain and
Folowing are some interesting enhancements in RBR in MySQL 5.6 Replication.
1. Optimized row image:Large data transfer between master and slave while using RBR is a thing of past. Why log complete rows on the master? Why not just the changed colums? The MySQL 5.6 release enables a DBA to configure the master to log …
The problemSometime back a member of the MySQL support team informed us that the slaves are very sluggish, when he tried to run a delete query on the master. "What may be the problem?" we wondered. This is in RBR and its pretty usual that we have slower slaves when using RBR as compared to SBR. We requested for some more details and found that it is something else. It's a problem when a lot of rows are getting modified in a table without PRIMARY KEY.
"UPDATE t1 set a = a+1;" and other queries such as this are generally found to make slaves sluggish if the table does not have proper index. Is it a problem with the fact that a lot of data is being transferred over the network? After all the total amount of data that will be transferred over the network will be more than twice (before and after image + some header) the sizeof data that is modified. Could this be …
Recently I needed to replicate between MySQL and another database technology. You might say, why on earth would you want to do something like that, but believe me there are reasons and definitely not (to go away from MySQL to some other DB technology like Oracle or SQL server). Unsurprisingly there are quite a few different tools to do it from any platform towards MySQL but very few which do it the other way round, just to name a couple: Golden Gate and DSCallards.