As you know, Sun's open source software and microprocessor strategy has been, at times controversial. We've filled trade journals and chat rooms with all kinds of dialog and the occasional crackpot conspiracy theory.

As many have rightly assumed from the outset, that controversy was, in fact, not a byproduct of the strategy - it was the strategy: if you're talking about Sun, you're not talking about the other guy. And then you'll buy a datacenter.

But now that we've firmly established our reputation for open source leadership, I'm very worried there's no more controversy to be had. There's too much trust in the system, and too much clarity around our strategic intent. So it's getting tougher and tougher to kick up a storm - and we can't very well spend a billion dollars or change our ticker symbol every time we want to generate a headline. Now can …

We made a very significant announcement last week, of a collaboration with one of the most (if not the most) security sensitive institutions on earth, the United States government's National Security Agency. They've joined the burgeoning OpenSolaris community, to collaborate with Sun and other community members on the future of ultra-secure operating systems.

To put this in context, community engagement has always been one of the most important ways Sun innovates in the marketplace - we partner with those that have extreme demands (whether it's the world's largest supercomputing facility, or the world's most paranoid security professionals (no offense intended), or the world's largest archival storage facilities), and then we leverage that expertise to create products for the mass market. We let extreme customers teach …

I have been quite vocal at every opportunity about how surrogate keys suck. However I must admit, as vocal as I may be, I have not really been good at working towards not using them myself. So briefly what are surrogate keys? They are usually those meaningless integer identifiers you see everywhere. Yes like in the url to this very blog post. People have come to love them however, especially people that use tools to generate SQL for them. But general wisdom tells people that everything is faster with integers. I keep hearing the same story over and over from self proclaimed MySQL, PostgreSQL or whatever kind of RDBMS they are flying experts. Index reads, joins and of course development since most tools are optimized (or should we rather say oversimplified things) towards integer surrogate keys. Now I …

A second (after Open eHealth) Open Source industry announcement today.

I just need to get some basics off of my chest here, it’s by no means a full list but it’s the most basic list I can think of to start with, and it’s basic because I am surprised by some of the slop I’ve seen in production environments.

1. Highly available server clusters - this is different than load balancing cluster, if confused see here.

2. Disaster recovery

-> this means daily,weekly,monthly backups as well as off site backups, and tertiary backups as well as a plan to get those backups imported and running in production as fast as possible. Backups should have consistency checking when they are created.

3. Security

-> perimeter on the network, VLAN’d databases from the web/app servers, firewall, ACLs, etc

-> system level: strong passwords on OS and database accounts (no blank …

Today, Sun announced we've closed the acquisition of MySQL - MySQL is now officially a part of Sun! From a dinner meeting back in late November, through some introspection from MySQL's CEO, to a closing today in late February - everyone involved showed a great sense of pace, urgency and excitement. And now, it's off to the races!

Since the announcement, I've seen and heard near universal support for the relationship - most everyone wants to know where we're headed, so here's a quick overview of our initial plans.

Starting today, we're rolling out global programs to raise awareness and adoption of MySQL among more established enterprises - you'll see ads like this (to the right) targeting institutions and independent software/service vendors (ISV's) looking to …

Let’s begin by assuming you have a server that runs MySQL and lots and lots of traffic flows through it everyday, let’s say… something like 50% of the size of the partition that the mysql binary logs are written to is on, then we will assume the binary log is turned on. Then we assume that expire_logs_days is not set.

What happens? Nagios/etc alerts that the partition is reaching a usage threshold because - low and behold the binary logs are filling up the partition. Tuning this variable is also important. It may need to be set to as low as 1 day, in which case I would say we need a bigger partition for binary logs, but setting it so low can cause replication problems if the slave(s) gets behind more than 1 day - god help us if it does - then those binary logs that the slave is reading are no longer available, and rebuilding replication will be next on the task list. (or using maatkit)

While I’m at it here are some good ones …

Ok, at least they tried. But it seems SAP has for now put their attempts to rest to smoose up a bit closer to OSS. I guess Oracle-InnoDB deal send enough shockwaves around the SAP HQ to kill of any of the little wishpers that had made the surprising MySQL-SAP deal happen in the first time. Now things have come full circle again, MaxDB development is not only back at SAP as I have noted before, its also back to closed source development. At the same time most big European OSS companies seem to end up in the hands of US based companies.

A while ago Novel scooped up SUSE. Recently MySQL AB was bought up by Sun. The biggest European software maker …

As a rule I always execute the following commands on a fresh database installation. Then for each user that is granted privileges, of course they are given a password and the host permissions are locked down as much as possible for their needs, alternately table and column privs as well. I’m not going to get into the parts the manual covers, but rather mention a couple of things on my mind.

First the initial commands:


mysql> use mysql
mysql> delete from user where User='';
mysql> delete from db where User='';
mysql> update user set Password=password('password_here') where User=’root’;
mysql> flush privileges;


However, one thing I’ve noticed is that when you hand over a server to someone that doesn’t necessarily follow your same understanding or regard to user privilege security, bad things can happen. Such as users created without a password. …