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
use.
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.