Typically, the guid in the database will look something like this:

http://blog.bit-matrix.com/?p=2411

You can use this perfectly fine but it will hurt your SEO since search sites prefer descriptive links such as:

http://blog.bit-matrix.com/2010/02/10/google-buzz-a-privacy-disaster

As it turns out, you can easily construct this link from the database yourself. Wordpress will recognize the format of the link and display the appropriate post. The query to construct this is quite simple, all we need is a little date formatting:

SELECT CONCAT(DATE_FORMAT(post_date,’%Y/%m/%d/’),post_name) AS permalink FROM wp_posts WHERE post_status=’publish’;

This will return all the published post guid’s in the following format:

2010/02/10/google-buzz-a-privacy-disaster

That’s all!

However, looking into the running processes via SHOW FULL PROCESSLIST I noticed that the thread reading the binary log data from the master has disappeared mysteriously.

Normally you should see two threads related to replication running on a slave server under the system user. One for reading the binary log data from the master and the other one for executing fetched data from the relay log:

mysql>SHOW FULL PROCESSLIST;
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
| Id     | User        | Host                | db   | Command | Time    | State                                                                 | Info                  |
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
|  37550 | system user |                     | NULL | Connect | 5878076 | Waiting for master to send event                                      | NULL                  |
|  37551 | system user |                     | NULL | Connect |       0 | Has read all relay log; waiting for the slave I/O thread to update it | NULL                  |
| 119738 | you         | 127.0.0.1:37540 | NULL | Query   |       0 | NULL                                                                  | SHOW FULL PROCESSLIST |
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
3 rows in set (0.17 sec)

mysql>

Restarting the slave would work for a short while until the same silent failure occurred.

In order to counter this, I looked into the variables related to networking and replication. modified the global variable ’slave_net_timeout’. The default variable for this is 3600 seconds (ie. 1 hour). The slave timeout sets the number of seconds to wait for the master to send more data before aborting the read. I set it to a short, 10 second period:

SET GLOBAL slave_net_timeout=10;

This improved the situation and the incidence of replication mysteriously stopping dropped dramatically. Additionally now the slave IO thread would actually stop running which, at least, given an indication that something is wrong.

Overall, the number of these failures dropped to almost zero just as suddenly as they had appeared. This leads me to believe that there might have been something in the network connection between the master and slave servers (in different datacenters) that was causing this.

Tip #1: Check the file sizes

“Why sure boss, I have last night’s backup right here, it’s… 0 bytes!”

While running backups very often is good it can fill up your backup drives rather quick. The solution is to consolidate your backup at the end of each day. Delete all the previous backups for that day and only keep the latest. And always check the file sizes of your backups! Generally they should always increase and should definitely not be zero bytes!

Tip #2: Run backups off a replicated slave

If you are making a backup of the database while someone if trying to access it they will have to wait until the backup is done before they can commit any writes. This is annoying to the user and the larger your database gets, the more they’ll have to wait. A common solution is to setup a replicated slave and make the backups from that machine instead of the master database. This way the client is unaffected. If course, make sure your replication slave is running when using that server for backups.

Tip #3: Dump a single table at a time

If you are making backups by dumping data into an SQL file (which would be the most common way) the best practice is to dump a single table at a time. There are a few advantages to this. Firstly, if you need to restore data from only one table at a later data you can just import that SQL file instead of trawling through the entire database dump. This makes the restoring job much simpler. Secondly, it results in smaller files which are easier to manage.

Conclusion

Using these tips will result in simple and transparent backup system which is easy to monitor and, most importantly, is actually useful when it comes to restoring data.

Here are some of the highlight new features in MySQL 5.1:

• Federated tables
• Partitioning
• Row-based replication
• Event scheduler
• MySQL Cluster updated and now available as separate product

For a more complete list and details see the MySQL 5.1 official new features page.

The master server is typically being used to execute reads and writes of the data while the slave (which started with an exact copy of the master’s data) duplicates the writes and thus maintains data that is identical to the master. Replication can be setup on several levels: all databases on a server, selected databases or even selected tables.

Usage Scenarios

Replication can be a very powerful tool in various scenarios:

• When distributing load, you can use multiple slave servers to read data from while only writing to the one master server.
• A slave server can be used as a hot standby in case of master failure.
• Slave servers can be used to perform operations that would typically result in degraded performance on the master, such as executing backups or running large queries for reports.

Advantages and Feature

A major feature of replication is the easy with which it can be implemented in a working environment. Replication is also fairly hands-free when it comes to maintenance (a few typical problems not withstanding, see below).

The simple operation allows for a changing and evolving setup so your replicated database solution can grow with you. Need more power? Add more read-only slaves. This will scale quite well for most solutions and depending on your particular usage. Naturally the more read-heavy your problem, the better use you can make of replicated read-only slaves to scale. Fortunately most database problems are read-heavy.

Another feature of replication is that it is asynchronous, i.e. the master and slave do not need to be constantly connected. When a connection is established, the slave server will “catch up” to the master. This helps make any solution implemented with replication pretty robust as long as one keeps in mind that the slave servers can and do lag behind the master on occasion – as we see in the next paragraph.

Potential Issues

However, replication is not without its share of problems.

For example, in implementing some of the above uses of replication one has to be weary of lag between the master and the slave. Either due to the slave’s “slow” connection speeds, the slower speed of the slave server or high load on the slave server it can start lagging behind the master. This is the result of the asynchronous nature of replication, while a definite and necessary feature, requires that we keep an eye on this potential problem. In normal operation with similarly matches master and slave servers, replication can be considered instantaneous (particularly on fast local networks).

A second drawback of replication can occur when the data on the slave becomes corrupted. A scenario like this can occur when servers are powered off unexpectedly or the server’s hard drives develop problems. While not a common occurrence, if the data is corrupted beyond salvation, the replication process needs to be started from scratch. This requires “pausing” the master server while a snapshot of its data is taken. After this the data is copied over to the slave and replication is restarted from the master’s current position.

Most issues due to interrupted replication are solved fairly quickly by restarting the replication and possibly skipping over the first duplicate record in the binary log. More detail about that can be found in this post.

Conclusion

Replication is a powerful feature of MySQL that is being used daily to provide high scalability and performance while keeping the entry cost low in terms of administration and setup time.

When the replication gets interrupted (either via a clean server shutdown or a forced one), replication refuses to restart citing the following error:

ERROR 1201: Could not initialize master info structure, more error messages can be found in the MySQL error log

The master.info file is present in the data directory and has all the required information in it but MySQL refuses to use it. Searching on the net did not yield anything definitive.

The simplest way to restart replication from this point is to re-enter the master.info data manually. Do the following:

1. STOP SLAVE
2. RESET SLAVE
3. CHANGE MASTER TO MASTER_HOST=’your_master’, MASTER_USER=’your_login’, MASTER_PASSWORD=’your_password’, MASTER_LOG_FILE=’log_file’, MASTER_LOG_POS=log_position
4. START SLAVE

At this point you want to execute ‘SHOW SLAVE STATUS’ and check to see if everything is running. Most times MySQL will stop since it tried to replay a duplicate record from the logs. We need to tell MySQL to skip that record and continue:

1. SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1
2. START SLAVE

That should get replication up and running again.

What is interesting to note is that, under the same circumstances, my MySQL 4 servers had no problems continuing replication. In any case, don’t forget to run regular backups of your database.