This was bound to happen, of course. Things were going too well. At a time when Google is activating 200,000 Android phones a day, and Android has overtaken the iPhone in terms of U.S.

read more

It is a common misconception that DRBD (or any block-level data replication) solution can magically make an application crash-safe that intrinsically isn’t. Baron highlights that misconception in a recent blog post.

I want to reiterate and stress that point here: if your application can’t reliably survive a node crash, it won’t successfully fail over on a replicated (or shared, for that matter) data device. But if it can, and DRBD is replicating synchronously, then DRBD won’t break it. In other words: try pulling the power plug on your machine while your app is running, and power back on. If your application recovers to a consistent state, you’re clear. If it doesn’t, don’t bother adding DRBD until you fix that.

…

Recently I had the opportunity to do some testing on a large data set against two MySQL column-store storage engines. I'd like to note that this effort was sponsored by Infobright, but this analysis reflects my independent testing from an objective viewpoint.

I performed two different types of testing. The first focused on core functionality and compatibility of ICE (Infobright Community Edition) compared with MyISAM on a small data set. The second part of my testing compared the performance and accuracy of ICE with InfiniDB Community Edition on a 950GB data set.

The first first part of my analysis focused on testing specific MySQL functionally with Infobright's storage engine. A lot of my tests involved corner or edge cases since I have experience developing such cases for MySQL column-based storage engines in the past. I reported any bugs that I found, and contributed my test cases to ICE. In fact, some of the issues have already …

Last week's "announcement" of the death of OpenSolaris has steered a lot of questions my way about where people should go, and/or where OmniTI will go, now that OpenSolaris future looks non-existent. As one of the more open users of Solaris related technology, and running some beefy loads on top of it, it makes sense that people would be curious as to what we might be doing next. I would start with saying that as a company, we don't have an official policy on this yet, and probably won't. We evaluate each situation on a customer by customer basis, so what follows here is more my personal …

I’ll be joining the NovaRUG (Northern Virginia Ruby Users’ Group) on Thursday to talk about MySQL performance. See their blog for the details and how to RSVP.

Related posts:

1. Free webinar on MySQL performance this Thursday
2. Speaking at MySQL Meetup in Northern Virginia
3. Speaking at EdUI Conference 2009
4. …

During the development of an application, not all time is spent on writing code. A lot of time is spent on reading debug output, crawling through log files and firing up the debugger to figure out what the application does. While the debugger helps us to inspect details of a running application on a testing environment, logfiles are often the only indication of the origin of an error on a production system. In this blogpost I want to describe how to log SQL statements on an existing application without touching any existing line of code at all. We will use a new MySQLnd Extension developed at the Mayflower OpenSource Labs for that purpose.

As an example, I will use PHProjekt 6. The project is particularly suitable for demonstration purposes as it has a logging infrastructure for function calls, but does not log SQL statements. …

Is your MySQL deployment reaching its performance and data limits? Calpont InfiniDB is a massive scaling, high performance analytic database built on MySQL. InfiniDB provides ultra fast query response against small, large and extremely large data.

Unlike other MySQL solutions, only Calpont provides a multi-threaded, scale out software architecture that maintains query performance as your data and user requirements grow. Since you know MySQL, it's also easy to install, learn an...

I’ll be joining the NovaRUG (Northern Virginia Ruby Users’ Group) on Thursday to talk about MySQL performance. See their blog for the details and how to RSVP.

If you need to work with LVM in your scripts but haven’t found a good method to access details about Logical Volume Groups, here’s a simple Python script that will print the details about any volumes on your system. This could be useful for writing a partition check script for your MySQL data directory (if you’re not using a standard monitoring system like Nagios).

import sys
import os
import commands
import subprocess
import select

def lvm():
    print ""
    LVM_PATH = "/sbin"
    LVM_BIN = os.path.join(LVM_PATH, 'lvm')
    argv = list()
    argv.append(LVM_BIN)
    argv.append("lvs")
    argv.append("--nosuffix")
    argv.append("--noheadings")
    argv.append("--units")
    argv.append("b")
    argv.append("--separator")
    argv.append(";")
    argv.append("-o")
    argv.append("lv_name,vg_name,lv_size")

    process = subprocess.Popen(argv, stdout=subprocess.PIPE)
    output = ""
    out = process.stdout.readline()
    output += out
    lines = …

Tokutek is pleased to announce immediate availability of TokuDB for MySQL, version 4.1. It is designed for continuous querying and analysis of large volumes of rapidly arriving and changing data, while maintaining full ACID properties.

New in TokuDB v4.1 includes important improvements, most notably support for SAVEPOINT and improved Fast Loader performance (introduced in v4.0).

This new release builds on TokuDB’s unique combination of capabilities:

• 10x-50x faster indexing for faster querying
• Full support for ACID transactions
• Short recovery time (seconds or minutes, not hours or days)
• Immunity to database aging to eliminate performance degradation and maintenance headaches
• 5x-15x data compression for reduced disk use and lower storage costs

Because of its high …