Comments on: Getting use of Slave in MySQL Replication

By: peter

peter — Fri, 22 Jun 2007 19:14:49 +0000

Not yet to be honest. I did not try 5.1 -> 5.0 Generally to be safe you better have Slaves at same or higher revision than the master.

By: Jojo

Jojo — Fri, 22 Jun 2007 04:03:29 +0000

Quick question. Have you tried replicating from 5.1 (master) to 5.0.xx (slave)? I’m planning to do a downgrade of our existing db due to some problems I’m experiencing on 5.1. I’m planning to create a replica first then cutover to the replicas so as to minimize downtime.

Looking forward to your reply. Thanks.

By: Dmitry

Dmitry — Thu, 14 Jun 2007 15:13:19 +0000

That delay become random and once per 2-3 days, now we researching about.

Thankx.

By: peter

peter — Thu, 14 Jun 2007 15:00:36 +0000

Dmitry,

If replication is that delayed you need to tune it first as semi synchronous replication will cral very slow in such case.

By: Dmitry

Dmitry — Thu, 14 Jun 2007 14:39:47 +0000

Thanks, Peter. Will test it, cause delays sometimes 5 seconds before in slave appears this row.

By: peter

peter — Thu, 14 Jun 2007 13:38:10 +0000

Dmitry,

Check Google Semi-Synchronous replication patches.

By: Dmitry

Dmitry — Wed, 13 Jun 2007 21:22:05 +0000

Exists any ways to create synced replication without delays or lags with mysql ?

By: peter

peter — Sat, 17 Feb 2007 08:44:02 +0000

James there are many different circumstances out where. You may have just one slave in which case it might not overload master too badly. There are also different cases about reading stale data – in some cases you can use it if you have no choice in others it is absolutely critical data is reasonably recent.

The thing is even non-critical queries might allow only certain delay – can you really use the slave if it is lagging by a week ? (And I’ve seen even worse cases).

Designing how slaves are usage you should of course take your normal lag spikes in account – if you have nightly job which does 10min update queries – this will be normal lag time for you which does not cause switching.

Regarding Alter Table – if it is long, in most cases the good idea is to run it on the slaves separately from the master and exclude it from replication.

By: James Day

James Day — Sat, 17 Feb 2007 05:01:52 +0000

Jakub, going to the master if the slave is lagged is very dangerous. Consider what happens if an ALTER TABLE is replicated: all slaves lag at the same time, the applications then mount an accidental denial of service attack on the master and take the site down. Slow queries or broken queries can also cause this problem. It’s good to track but switching to a different slave or giving up and providing out of date information for non-critical queries (and critical had better be limited!) is also necessary to handle fault cases.

By: Thomas

Thomas — Fri, 16 Feb 2007 23:12:53 +0000

Then use a timeout on MASTER_POS_WAIT en fetch data from master if a timeout occurs.
Not the best solution, but it ensures slaves are used as much as possible.

This can be very useful if you divide the tables in a database to difference slaves. Using the slave as much as possible greatly increases the chance most data is in cached in memory whereas the same query could be really, really slow on the master because it might not have much of it in cache.