I thought about covering an issue that many people will come across when implementing MySQL Cluster if they are not aware of it. That is of bandwidth and latency in TCP/IP when implementing a transport over ethernet cabling.

The MySQL Cluster is always passing information between the different nodes that it contains. This is obvious for synchronisation and also for retrieval of data through the MySQL api nodes. When people first setup the cluster they often go for a default install on a higher speed network such as gigabit ethernet (GigE). This will probably work fine for very small data sets or initial testing data, but when the data becomes larger in size, the user realises very quickly that there is a lot of traffic passing through the network on the cluster.

So what can be done to help in reducing the load on the network, or in improving the performance of the cluster's network? Well, the first and most simplest step is to make …

I thought about covering an issue that many people will come across when implementing MySQL Cluster if they are not aware of it. That is of bandwidth and latency in TCP/IP when implementing a transport over ethernet cabling.

The MySQL Cluster is always passing information between the different nodes that it contains. This is obvious for synchronisation and also for retrieval of data through the MySQL api nodes. When people first setup the cluster they often go for a default install on a higher speed network such as gigabit ethernet (GigE). This will probably work fine for very small data sets or initial testing data, but when the data becomes larger in size, the user realises very quickly that there is a lot of traffic passing through the network on the cluster.

So what can be done to help in reducing the load on the network, or in improving the performance of the cluster's network? Well, the first and most simplest step is to make …

I thought about covering an issue that many people will come across when implementing MySQL Cluster if they are not aware of it. That is of bandwidth and latency in TCP/IP when implementing a transport over ethernet cabling.

The MySQL Cluster is always passing information between the different nodes that it contains. This is obvious for synchronisation and also for retrieval of data through the MySQL api nodes. When people first setup the cluster they often go for a default install on a higher speed network such as gigabit ethernet (GigE). This will probably work fine for very small data sets or initial testing data, but when the data becomes larger in size, the user realises very quickly that there is a lot of traffic passing through the network on the cluster.

read more

I thought about covering an issue that many people will come across when implementing MySQL Cluster if they are not aware of it. That is of bandwidth and latency in TCP/IP when implementing a transport over ethernet cabling.

The MySQL Cluster is always passing information between the different nodes that it contains. This is obvious for synchronisation and also for retrieval of data through the MySQL api nodes. When people first setup the cluster they often go for a default install on a higher speed network such as gigabit ethernet (GigE). This will probably work fine for very small data sets or initial testing data, but when the data becomes larger in size, the user realises very quickly that there is a lot of traffic passing through the network on the cluster.

read more

From the list of "where is Brian"...

Monday night is the MySQL Meetup, so I will be hanging out at the Elysian at 7 talking to MySQL users.

Tuesday morning I will be flying down to California to speak at the MySQL Customer Advisory Board on Wednesday and meeting with one of our product teams on Tuesday and Thursday. Thursday afternoon I will be flying back to Seattle for the "Ignite Seattle" event. This is a "geek night out" being sponsored by O'Reilly and friends. I'll be there speaking about recent (and not so recent) VOIP/ Asterisk work.

Link to Ignite site:
http://www.capitolhillarts.com

Link to Exploit Seattle listing:
http://exploitseattle.com/article.pl?sid=06/11/29/0722250&mode=thread

These companies have fought long, hard battles to get Open Source into the corporate data centers.  It was an uphill battle, requiring education on a concept new to many people.  They couldn’t just blaze a path for themselves, they had to prove an entire business model; explain its viability, its resulting products, and value.  The developers and executives at these companies fought a hard, honest war and have established a beach head.

The Marines have blazed the trail.  No mucking around with convincing a CIO that “not just anyone can update their source automatically” and that Open Source companies can generate real value, revenue with a product you COULD …

In writing a test I need a 1024 character block. I could just
generate one, but I was thinking to myself "There must one out
there...".

Most of the time I just embed the Preamble to the American
Constitution. I learned it as a kid and I can still recite it (and if
you look in some of the MySQL test cases you will find bits and
pieces of it).

And when recite, thanks to School House Rock, I mean I can sing it :)

What though is a phrase that is exactly 1024 characters in length?

I wrote before about a generic, cross-platform way to simulate the SQL ROW_NUMBER() function in any RDBMS. There is a much more efficient way to do this on MySQL with user variables.

I’ll be presenting a webinar about the solidDB for MySQL product on Tuesday, Dec 5. The webinar includes my talk, followed by some time at the end for Q&A. If you’re interested, you can find more info about the webinar and register for the event. ¶

After my last tinkering around with the stream format for the Archive engine I decided to
see if I could improve on compression (this is under MySQL 5.1).

34,973,793 rows.

MyISAM: 4,253,705,712
Archive v2: 2,153,692,212
Archive v3: 836,812,832

The Schema:
CREATE TABLE `accesslog2` (
`id` int(10) unsigned NOT NULL DEFAULT '0',
`method` varchar(255) DEFAULT NULL,
`bytes_sent` varchar(255) DEFAULT NULL,
`protocol` varchar(255) DEFAULT NULL,
`uri` varchar(255) DEFAULT NULL,
`args` varchar(255) DEFAULT NULL,
`hostname` varchar(255) DEFAULT NULL,
`client` varchar(255) DEFAULT NULL,
`Referer` varchar(255) DEFAULT NULL,
`slash_user` varchar(255) DEFAULT NULL,
`e2_node` varchar(255) DEFAULT NULL,
`time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00'
)

So just a bit better :)
…