Times of change are upon the database market. The major established database companies are being challenged by open source upstarts like MySQL and PostgreSQL. For years, Open Source Databases (OSDBs) have been quietly increasing their penetration, but until recently they have lacked the capabilities to seriously threaten proprietary databases like Oracle, IBM's DB2, and Microsoft's SQL Server.

All that has changed. OSDBs now boast the necessary features and robustness to support commercial databases hundreds of Gigabytes in size. And a growing trickle of competitive benchmark results shows them …

Times of change are upon the database market. The major established database companies are being challenged by open source upstarts like MySQL and PostgreSQL. For years, Open Source Databases (OSDBs) have been quietly increasing their penetration, but until recently they have lacked the capabilities to seriously threaten proprietary databases like Oracle, IBM's DB2, and Microsoft's SQL Server.

All that has changed. OSDBs now boast the necessary features and robustness to support commercial databases hundreds of Gigabytes in size. And a growing trickle of competitive benchmark results shows them …

It recently came up that it would be helpful if we had a cheat sheet to find out the machine names for any given UNIX. I knew these off the top of my head but it would be great if people added more as comments.

HP/HP-UX: /bin/uname -i
IBM/AIX: /bin/uname -m
SGI/IRIX: /sbin/sysinfo -s
Sun/Solaris: /usr/ucb/hostid

The built-in HQ database is PostgreSQL. Recently, users have been discovering PostgreSQL has a certain limitation: it will not execute more than 2 billion transactions between vacuums. In rare cases, an HQ built-in database can get into this state.

If this happens, the database will stop accepting connections and HQ, which needs a data store, will obviously cease to operate properly. The immediate symptom will be that users will not be able to log in to HQ and the message displayed on the screen will be The backend datasource is unavailable.

That error is not enough to say for sure that the problem is PostgreSQL avoiding wraparound failure by not accepting connections. A quick look at the hqdb.log can confirm. The telltale log entries look like this:

FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres"
HINT: Stop the postmaster and …

Thanks to a patch Dane Miller submitted, MySQL Heartbeat can now be used to monitor Slony-I replication lag for PostgreSQL. It works identically: it updates a record on the master and looks for it on the slave. You just have to specify the database driver on the command-line:

mysql-heartbeat [options] --dbidriver=Pg

Most of the tools in the MySQL Toolkit are very MySQL-specific. This one just happened to be an exception, and I'm happy it's useful for more than the original purpose.

Hello everyone, I think this will be a great log buffer. Dave has been sick these past two days and as a result, we do not have a comprehensive log buffer ready the way we or a volunteer usually do. This was bound to happen to log buffer at some point and today it has happened. So I [...]

Well, it’s better late than never! Frank Wiles has published the 65th edition of Log Buffer the weekly review of database blogs, on the Revolution Systems Blog. For the record Frank published it right on time on Friday - it’s just us that’s late. Sorry about that. Log Buffer #65.

I just read a fascinating article on clustering architectures for databases from Kevin Closson of Polyserve (now HP). Kevin, for those of you who don’t know him, is a Golden God, at least according to StorageMojo Robin Harris, but all I can say is that he has one of the most informed and incisive views [...]

Some say Sun is as cool as OSCon (if not cooler) because, among most companies that support OSCon, only Sun can produce truly underground notes on OSCon.

David Van Couvering reviews Mike Olson's comments about his keynote at OSCon and pontificates about whether the value of Open Source could be limited to the collaboration it fosters. David aptly notes that

Open source and an open community gives you the assurance that the technology you are depending on is not going to be discontinued or put into "maintenance mode," it won't be acquired by someone who you would rather not do business with, and it won't be used as leverage against you to extract money or modify your behavior.

By way of further review, David contrasts MySQL as an Open Source project to …

Now you may not believe me, but there actually are situations when DRBD is not the right choice for meeting your storage needs. Since I’ve been asked to compile some of these and present them here, let’s take a look.

Don’t use DRBD when…

• All or most of your data is static. Front-end web servers are a prime example for this. Even though they usually serve highly dynamic content these days, your PHP documents and Perl scripts and JSP’s usually don’t change that often. Using DRBD for that type of data isn’t much use. Use DRBD for your backend store instead. On the front end, you’ll do fine with rsync, although it …