How To Set Up MySQL Database Replication On Fedora 10

This tutorial describes how to set up database replication in MySQL. MySQL replication allows you to have an exact copy of a database from a master server on another server (slave), and all updates to the database on the master server are immediately replicated to the database on the slave server so that both databases are in sync. This is not a backup policy because an accidentally issued DELETE command will also be carried out on the slave; but replication can help protect against hardware failures though. I will use Fedora 10 for the master and slave in this tutorial.

We've been making a fair number of announcements recently - on both the product and the partnering front. That's generated a lot of interest, and a fair number of questions. So I thought I'd take the opportunity to deliver this overview and the upcoming focused discussions on what makes Sun tick in a video format. Let me know if this is useful, or what else we can do to keep you informed via the comment field at the bottom.

We're approaching the end of our fiscal year, and given all the swirl in the economy, I thought it worthwhile to restate where Sun's headed as a company, to let customers, partners, employees and investors see and understand where we're headed. Clarity's always useful, doubly so in times of uncertainty.

Let me start by joining the chorus of those worried about the global economy. I am routinely talking to customers now partially owned by governments, whose share prices have declined 95% or more, whose balance …

Last week (or rather last weekend) was quite productive. I was able to make a good progress migrating to the new mysql-test based testing framework. Reviewing the tests I was able to find and fix some bugs. For example there was a bug that ignored some columns while detecting index capabilities. As I mentioned earlier I also started to rework the output format. Here’s an example:

/*

Query:

select sum(col2) from t2 group by col1selectivity:

all rows

used tables:

t2 (all rows)

used aggregate functions:

sum ( col2 )

ordering:

implicit

related existing indexes:

t2.ix123(col1, col2, col3): covering, optimizes ORDER BY, optimizes GROUP BY

*/

As you can see now the tool reports used aggregate functions, if any. This is very convenient for manual query analysis, especially in non-trivial cases.

Next, the “ordering” now can be “implicit”. This is reported for the cases when there’s a GROUP BY clause and no ORDER …

We finally managed to get Intel X25-E SSD drive into our lab. I attached it to our Dell PowerEdge R900. The story making it running is worth separate mentioning - along with Intel X25-E I got HighPoint 2300 controller and CentOS 5.2 just could not start with two RAID controllers (Perc/6i and HighPoint 2300). The problem was solved by installing Ubuntu 8.10 which is currently running all this system. Originally I wanted to publish some nice benchmarks where InnoDB on SSD outperforms RAID 10, but recently I faced issue which can make previous results inconsistent.

In short words using Intel SSD X25-E card with enabled write-cache (which is default and most performance mode) does not warranty storing all InnoDB transactions on permanent storage.
I am having some déjà vu here, as Peter was rolling this 5 years ago http://lkml.org/lkml/2004/3/17/188 regarding regular IDE …

I just got back from the monthly MySQL Meetup. It's been moved from the Elysium to downtown, to the offices of Blue Gecko.

So the food wasn't as good, but it was easier to talk and listen.

The conversation orbited a lot around Drizzle, but also to practical issues of types of sharding, using VIEWs to access denormalized tables, data warehousing solutions, and using snapshots vs online backup tools for backups.

There was also a great deal of discussion about AWS; running databases in EC2 nodes, backing up stuff into S3, building scaling web services, and using CloudFront.

It was fun.


I was "on" most of the time; bright, cheerful, helpful, and outgoing.

Which means, of course, that as soon as I got home, I was exhausted. An introvert am …

It’s a fairly simple rule, and something that should be obeyed for your health and sanity.

There are a couple of bugs which you could run into, when quoting large numbers. First of all, Bug #34384. This is concerning quoting large INTs in the WHERE condition of an UPDATE or DELETE. It seems that this will cause a table scan, which is going to be slooooow on big tables.

Similarly, there is the more recently discovered Bug #43319. You can run into this if you quote large INTs in the IN clause of a SELECT … WHERE. For example:

mysql> EXPLAIN SELECT * FROM a WHERE a IN('9999999999999999999999')\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        TABLE: NULL
         type: NULL
possible_keys: NULL
          KEY: NULL
      key_len: NULL
          ref: …

Tomorrow, I'll be attending the Executive Seminar on Cloud Computing at NASDAQ MarketSite (NY). Speakers include Dr. Werner Vogels and Mårten Mickos (ex-CEO of MySQL). Big thanks to Amazon and RightScale who were able to accommmodate my RSVP even when the registration had formally closed.

I hope to be able to catch up with Mårten Mickos during the event. In case I do succeed in catching up, is there any question you want me to ask him? You can email me or post a comment.

It's funny that the event site still shows Mårten's title as "SVP of Sun Microsystems’ Database Group."

Today we announce release 1.0.2-3 of our XtraDB storage engine.

Here is a list of enhancements:

• Move to MySQL 5.1.31
• Scalability fix — ability to use several rollback segments

Increasing the number of rseg may be helpful for CPU scale of write-intentional workloads. See benchmark results.