by Peter Zaitsev | Nov 26, 2008 | Insight for DBAs
Happy Thanksgiving and little holiday challenge for you. Say you have a trigger on the slave which you would like to work differently, depending on whenever update is executed via replication thread vs updating table locally ? This can be helpful for example for...
by Baron Schwartz | Oct 8, 2008 | Insight for DBAs
The trouble with slave lag is that you often can’t see it coming. Especially if the slave’s load is pretty uniform, a slave that’s at 90% of its capacity to keep up with the master can be indistinguishable from one that’s at 5% of its capacity....
by Peter Zaitsev | Sep 22, 2008 | Insight for DBAs
The 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 and configuring it properly. In this post I will just look...
by Peter Zaitsev | Aug 2, 2008 | Insight for DBAs
Quite frequently I see customers looking at MySQL recovery as on ability to restore data from backup which can be far from being enough to restore the whole system to operating state, especially for complex systems. Instead of looking just at data restore process you...
by Peter Zaitsev | Aug 2, 2008 | Insight for DBAs
Have you ever seen the replication stopped with message like this: Last_Error: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the...
by Peter Zaitsev | Jul 7, 2008 | Insight for DBAs
As you probably know MySQL Replication (statement based) works by fetching statements from MASTERs binary log and executing them on the SLAVE. Since MySQL 4.0 this process is a bit more involved having events passing via relay logs on the Slave which also means there...
by Peter Zaitsev | Jun 29, 2008 | Insight for DBAs
Sometimes MySQL Replication may run out of sync – because of its own buts or operational limitations or because of application mistake, such as writing to the slave when you should be only writing to the master. In any case you need slave to be synced with...
by Peter Zaitsev | Jun 4, 2008 | Insight for DBAs
I already wrote about some MySQL Error Messages which are confusing, here is one more: 080603 20:53:10 [Note] Slave: connected to master '[email protected]:3306',replication resumed in log 'master-bin.003676' at position 444286437 080603 20:53:10 [Note] Slave: received...
by Baron Schwartz | May 26, 2008 | Insight for DBAs
A while ago I wrote about how to make MySQL replication reliable, part of which is to eliminate temporary tables. The idea is this: if a slave is stopped (or crashed) while a temporary table is open and is then restarted, the temporary table doesn’t exist...
by Baron Schwartz | May 14, 2008 | Insight for DBAs
Recently I had an interesting surprise with concurrent inserts into a MyISAM table. The inserts were not happening concurrently with SELECT statements; they were blocking and the process list was filling up with queries in Locked status. My first thought was that the...
by Aurimas Mikalauskas | Mar 27, 2008 | Insight for DBAs
Few months ago, I wrote about a faster way to do certain table modifications online. It works well when all you want is to remove auto_increment or change ENUM values. When it comes to changes that really require table to be rebuilt – adding/dropping columns or...
by Peter Zaitsev | Jan 29, 2008 | Insight for DBAs
As you might know even if you’re only using Innodb tables your replication is not completely crash safe – if Slave MySQL Server crashes/power goes down it is likely for relay logs to run out of sync (they are not synced to the disk) plus position on the...
by Peter Zaitsev | Nov 7, 2007 | Insight for DBAs
To get this straight – I’m not a big fan of filtered or partial MySQL Replication (as of version MySQL 5.0) – there is enough gotchas with replication itself and getting things right with filtering can get quite bumpy road. In some applications...
by Maciej Dobrzanski | Oct 31, 2007 | Percona Software
Microslow patch is used by many DBAs and developers to accurately time their queries and to catch those which run less than a second as they can also be a performance killer for a busy application. Recently I have started the development of an updated version of the...
by Peter Zaitsev | Oct 12, 2007 | Insight for DBAs
The question I often get is how far MySQL may fall behind and how to keep replication from lagging. The lag you will see will vary a lot from application to the application and from load to load. Plus what is the most important within same application the lag will...
by Maciej Dobrzanski | Jul 18, 2007 | Percona Software
Microslow patch has been there for some time, but only for earlier MySQL editions such as 4.1 and 5.0. Now it’s also available for the latest 5.1. Because MySQL went through a lot of internal changes, the patch had to be written from scratch. It introduces some...
by Peter Zaitsev | Apr 6, 2007 | Insight for DBAs
I just found post by Kevin, in which he criticizes Master-Master approach, finding Master with many slaves more optimal. There is surely room for master-N-slaves systems but I find Master-Master replication much better approach in many cases. Kevin Writes “It...
by Peter Zaitsev | Mar 28, 2007 | Insight for DBAs
I just filed a bug regarding slow queries executed by replication thread are not being logged to the slow query log. This is not a big deal but it is ugly little gotcha which I think few people know about. It is especially bad if you’re using tools to analyze...
by Peter Zaitsev | Feb 14, 2007 | Insight for Developers
MySQL Replication is asynchronous which causes problems if you would like to use MySQL Slave as it can contain stale data. It is true delay is often insignificant but in times of heavy load or in case you was running some heavy queries on the master which not take...
by Peter Zaitsev | Jan 30, 2007 | Insight for DBAs
Kevin Burton writes about making MySQL Replication Parallel. Many of us have been beaten by the fact MySQL Replication is single threaded so in reality it is only able to use only single CPU and single disk effectively which is getting worse and worse as computers are...
