A frequently asked question about MySQL replication is "how do I know whether my slave is identical to the master?" Until recently there hasn't been a good way to know, but now you can compare all the data in your master to the data in the slaves and get a reliable yes-or-no answer. And you can do this online, efficiently, across many servers simultaneously. Read on to find out how.

Guy Kawasaki has never been known as one who follows the crowd. In fact, quite the opposite. He's the type of person that business and technology experts look to for guidance and vision. So, it's only fitting that he's leading off the conference keynotes on Tuesday morning with a talk called "The Art of Innovation". Many of you may recognize the title — one of Guy's most successful books is called "The Art of the Start". In that book, he covered the points that every entrepreneur and start-up hopeful needs to know about getting venture capitalist's attention, developing a mantra (not a business plan!), and taking action instead of talking about taking action.

I don't know why MySQL is so darn popular with startups. Maybe …

I was reading through some old Jeff Nolan posts and came across this one, and it opened a sore. Jeff comments on this CNET article about Oracle's response to Microsoft's per-CPU/socket pricing. Microsoft made the decision to charge per-CPU/socket, not per-core, which throws a bit of a monkey wrench into Oracle's attempts to price per-core, and has the potential to discount Oracle's database pricing by as much as 87%, as Stephen Shankland reported.

I feel for Oracle on this, because customers derive real, tangible value from software running on improved hardware. Customers don't necessarily see it this way, but it's true. Why shouldn't a customer pay for wringing more value out of its software (through improved hardware)?

Jeff sees it very differently, and writes:

…

A frequently asked question about MySQL replication is “how do I know whether my replica is identical to the master?” Until recently there hasn’t been a good way to know, but now you can compare all the data in your master to the data in the replicas and get a reliable yes-or-no answer. And you can do this online, efficiently, across many servers simultaneously. Read on to find out how.

The Cuckoo's Egg by Clifford Stoll has been around for a while, having been published in 1989. It details how a system administrator (a trained astronomer who had to find something else to do) tracked a malicious hacker through his system and numerous others including defense contractors and unclassified DoD systems. It's one of those books a lot of folks who work security say should be read if you're in the field. When I was a cadet at …

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 requires extra hardware thats sitting in standby and not being used (more money and higher capital expenditures)", I'm surprised why would it ? Typically you can use both nodes for most of the reads, and this is in fact use pattern MMM was designed for.

"There's only one machine to act as the standby master. If you have 10 slaves you should be able to fail five times and still be operational." This is valid consideration but honestly for most of applications it is …

Another anecdote from the ongoing Java 1.4 to Java 5 transition... Last time it was an incarnation of "Favor composition over inheritance". This time I am writing about a multi-threading issue which can be equally subtle and difficult to pinpoint.

On the test systems we have set up we observed two strange types of exceptions at seemingly random times and in various different areas of the application. They looked similar to the following two patterns:

• java.lang.ArrayIndexOutOfBoundsException: 432
          at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1941)
          at java.util.Calendar.setTimeInMillis(Calendar.java:1066) …

Another anecdote from the ongoing Java 1.4 to Java 5 transition... Last time it was an incarnation of "Favor composition over inheritance". This time I am writing about a multi-threading issue which can be equally subtle and difficult to pinpoint.

On the test systems we have set up we observed two strange types of exceptions at seemingly random times and in various different areas of the application. They looked similar to the following two patterns:

• java.lang.ArrayIndexOutOfBoundsException: 432
          at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:436)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2024)
          at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1941)
          at java.util.Calendar.setTimeInMillis(Calendar.java:1066) …

Thanks to Vanessa Fox (nude!) [1] for tagging me in the latest Friday blogging meme.

Here are my five reasons for blogging, with very little deep thought:

1. I like to write. Hell, I even wrote a book once and you can read all about it on that outdated website.
2. People actually read this stuff. Seriously. I don't know who most of you are (just some of you), but I appreciate the fact that I'm able to entertain, annoy, or otherwise occupy bits of your free time. It makes me feel loved (and hated).
3. It's a very efficient way to cause trouble, …

In many Search/Browse applications you would see main (fact) table which contains search fields and dimension tables which contain more information about facts and which need to be joined to get query result.

If you're executing count(*) queries for such result sets MySQL will perform the join even if you use LEFT JOIN so it is not needed which slows down things considerably. In similar way MySQL generates full rows while executing queries with limit before throwing them away which makes queries with high offset values very expensive.

To get better performance you can "Help" MySQL and remove JOIN for count(*) and do JOIN after limiting result set for retrieval queries.

Lets look at following simple example with one dimension table. In real life you will usually have several of these so performance improvements can be even higher.

PLAIN TEXT SQL:

1. CREATE TABLE `fact` (
…