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 …

Here's the replication structure: 1 master, 5 slaves under it, each slaves have another 5 slaves under it.

Here's the problem: What if you have to update a couple of big tables and you know that if you apply it to the master that it will take a long time to replicate? What can you do?

Here's the solution: Run the update queries on each database by turning off replication. This can be done by running the command below.

set SQL_LOG_BIN = 0;

1. Check if all the weekend database related jobs ran, this could be backup, or some data-related processing work.

2. Check your replication and make sure it was running smoothly (you should actually check this everyday).

3. Check your logs for any related errors.

4. Check the scripts that you are working on.

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 …

Last week I wrote about CVE-2007-5925, a vulnerability in MySQL 5.0.51 (current version of the MySQL Community Edition), which is fixed in 5.0.52 (current version of the MySQL Enterprise Edition, released on the same day as 5.0.51) and was known for more than three weeks when 5.0.51 got released. 5.0.51 is also affected by CVE-2007-6303 and CVE-2007-6304, both as well already fixed in 5.0.52. While preparing 5.0.51-1 (not yet uploaded to unstable) for …

The potential for successfully building or extending a corporate identity based on Open Source depends on a company’s relationship towards an Open Source product. The graph below relates the extend of product ownership to the level of awareness potentially available for marketing:

Basically, the more you own the product, i.e. the more it is directly correlated to your company, the more you can make out of it.

If you’re the creator of the product (e.g. MySQL, the company, is the creator of MySQL, the database), you can utilize maximum awareness in your market. Your whole ecosystem will support your marketing efforts. For example, those providing extensions to your product, will automatically market your product while promoting their extension.

If you’re an external contributor to a product (e.g. providing patches with bug fixes), you …

For all new contributors devoted to quality, FAQ was slightly updated with new section.

I still remember my first database disaster that occurred almost 20 years ago.  I was a brand new systems engineer working on a massive mainframe database.  My leader needed me to make a few data changes, but they would have to be done while he was on vacation (of course) but he assured me nothing would go wrong.  Right.  To make a long story short, the morning I ran the jobs to make the change, I ended up deleting the entire worldwide telecommunications database of General Motors and keeping just the two records I needed to change.  Let me tell you, no amount of antiperspirant stands up under those conditions.

Thank goodness for the backup job that I ran right before the change.  I was able to restore everything back to the way it was, but brother, were there ever some anxious moments in between… 

For sure, data protection is the database professional’s #1 job.  And this …

We are working hard on the next release of MySQL Workbench and are trying to follow our plan of getting a release out every second week. A lot of things have already been addressed, some new things came up. But we are clearly moving into the right direction and our investments in unit tests and UI tests seems to pay off as expected. More details in a post later this week.