Comments on: Managing Slave Lag with MySQL Replication http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/ Everything about MySQL Performance Thu, 05 Nov 2009 22:22:42 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Fighting MySQL Replication Lag | MySQL Performance Blog http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-357272 Fighting MySQL Replication Lag | MySQL Performance Blog Tue, 23 Sep 2008 04:16:51 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-357272 [...] problem of MySQL Replication unable to catch up is quite common in MySQL world and in fact I already wrote about it. There are many aspects of managing mysql replication lag such as using proper hardware [...] [...] problem of MySQL Replication unable to catch up is quite common in MySQL world and in fact I already wrote about it. There are many aspects of managing mysql replication lag such as using proper hardware [...]

]]> By: Robin http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-257388 Robin Wed, 26 Mar 2008 11:18:32 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-257388 Setting LOW_PRIORITY on UPDATE/DELETE/INSERT queries may also cause a replication lag. It works fine on the master, but when it is being replicated to the slaves, it will cause the replication thread to wait until there are no more readers on that table. Setting LOW_PRIORITY on UPDATE/DELETE/INSERT queries may also cause a replication lag. It works fine on the master, but when it is being replicated to the slaves, it will cause the replication thread to wait until there are no more readers on that table.

]]> By: Mark http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-254980 Mark Fri, 21 Mar 2008 00:24:30 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-254980 In a lot of cases it's hard to find a way speed up replication, so you have to be creative within your web apps. Another big problem I found is trying to test/report replication speeds under heavy load. I came up with a way for situations where you need to INSERT then SELECT the same data instantly - this is by using master/slave circular replication design, (the master/slaves can also have read-only slaves)... e.g. INSERT into the master - return the masters IP Address, then make a connection to the same master with the returned IP Address and select that same data that just got inserted into the master/slave. This can work for certain situations but can be hard getting the right load balance to the masters. Good luck :) In a lot of cases it’s hard to find a way speed up replication, so you have to be creative within your web apps. Another big problem I found is trying to test/report replication speeds under heavy load.

I came up with a way for situations where you need to INSERT then SELECT the same data instantly – this is by using master/slave circular replication design, (the master/slaves can also have read-only slaves)… e.g. INSERT into the master – return the masters IP Address, then make a connection to the same master with the returned IP Address and select that same data that just got inserted into the master/slave. This can work for certain situations but can be hard getting the right load balance to the masters.

Good luck :)

]]> By: jenny http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-252581 jenny Fri, 14 Mar 2008 00:13:00 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-252581 The replication query execution information can easily be traced with Dtrace by inserting the dtrace probes into the mysql_update function, plus, it can report query excution less than 1 sec (ms or ns) The replication query execution information can easily be traced with Dtrace by inserting the dtrace probes into the mysql_update function, plus, it can report query excution less than 1 sec (ms or ns)

]]> By: peter http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-179319 peter Sat, 20 Oct 2007 16:15:38 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-179319 Michael, Indeed no_write_to_binlog or local can be better for alter table optimize table. To bad it is not supported as a flag for all commands as you may be willing to run without replication any kind of command. Michael,

Indeed no_write_to_binlog or local can be better for alter table optimize table.

To bad it is not supported as a flag for all commands as you may be willing to run without replication any kind of command.

]]> By: Michael http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-179118 Michael Fri, 19 Oct 2007 23:58:21 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-179118 I highly recommend using local or no_write_to_binlog instead of disabling binary logging before altering the table, it prevents headaches, and forgetfulness causing problems later on. Michael I highly recommend using local or no_write_to_binlog instead of disabling binary logging before altering the table, it prevents headaches, and forgetfulness causing problems later on.

Michael

]]> By: Xaprb http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-177205 Xaprb Sat, 13 Oct 2007 21:39:24 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-177205 Yes, it would be great to have at least parts of Google's patches added. Right now (most of you readers know this, but for those who don't) you have no idea how "close to the ceiling" you are with replication. You find out when the slave abruptly can't keep up anymore. Yes, it would be great to have at least parts of Google’s patches added. Right now (most of you readers know this, but for those who don’t) you have no idea how “close to the ceiling” you are with replication. You find out when the slave abruptly can’t keep up anymore.

]]> By: peter http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-176977 peter Sat, 13 Oct 2007 08:13:07 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-176977 Thanks Mark, Hopefully you will be able to get your patch accepted soon. Thanks Mark,

Hopefully you will be able to get your patch accepted soon.

]]> By: Mark Callaghan http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/comment-page-1/#comment-176860 Mark Callaghan Fri, 12 Oct 2007 21:26:11 +0000 http://www.mysqlperformanceblog.com/2007/10/12/managing-slave-lag-with-mysql-replication/#comment-176860 If we can get the 'SHOW USER_STATISTICS' functionality from the Google patch into MySQL, then you can compute replication load average using the Busy_time output for the system user and Uptime as reported by SHOW STATUS. Busy_time is the number of seconds that user had been running SQL statements. I had not thought of monitoring this before. It is a great idea. If we can get the ‘SHOW USER_STATISTICS’ functionality from the Google patch into MySQL, then you can compute replication load average using the Busy_time output for the system user and Uptime as reported by SHOW STATUS. Busy_time is the number of seconds that user had been running SQL statements.

I had not thought of monitoring this before. It is a great idea.

]]>