Archive for the ‘enterprise’ Category

MySQL Enterprise Backup: Redo-log-only Incremental Backups

Январь 12th, 2012
The latest release of MySQL Enterprise Backup (MEB 3.7.0) introduces a new method for performing incremental hot backups - the redo-log-only incremental backup. This new method of incremental backups allows for highly compact and fast incremental backups and MEB users now have the choice between data-file based incremental backups and the redo-log-only incremental backups.

In data-file based incremental backups (performed using the '--incremental' option) MEB scans all InnoDB datafiles but copies to the backup only modified pages. The main benefit of this is that an incremental backup is much smaller than a full backup but the downside is that during the process of taking an incremental backup MEB still reads all data-files.

With the new redo-log-only incremental hot backups MEB copies just redo logs accumulated since the previous backup. So, no scanning of the data-files is needed and just sequential copy of the redo log is performed. The redo-log-only incremental backup and data-file based incremental backup treat the non-InnoDB data in the same way: the backup of InnoDB data is incremental but the backup of non-InnoDB data is not. Some important aspects of this backup method are:

  • Incremental redo-log-only backup is not always possible. Redo log in InnoDB is implemented with fixed-size circular log files. This means that oldest log entries are overwritten by newer ones after some time. Incremental backup using only redo log is possible only from the log position that is not yet overwritten.
  • Efficiency of the method depends on how the database is modified. If many database pages are modified, but each page is modified only once or a few times, then copying just redo log might work well. On the other hand, if only a small fraction of the database pages is modified, but each page is modified many times, then this method might give poorer performance.

Let us consider a typical usage scenario in which the redo-log-only incremental hot backup is used to back up a database once a day. This requires that InnoDB log files are large enough to hold at least one day's worth of redo logs. This also means that InnoDB log files are pretty large: for a terabyte sized database with 1% of datafile pages modified each day the minimum combined log file size would be 10 gigabytes.

Our experiments showed that the redo-log-only incremental backup method offers significant performance improvements over the normal incremental backup when the database is suitable for this method: the backup process takes less time and the resulting backup is smaller.

For taking redo-log-only incremental hot backups the user needs to issue the incremental backup command with the '–incremental-with-redo-log-only' option instead of the normal '–incremental' option. An example:

$ mysqlbackup --incremental-with-redo-log-only --incremental-backup-dir=/media/backups/incr_bak1 --start-lsn=18974478 backup

Redo-log-only incremental backups are also compatible with the '–incremental-base' option introduced in MEB 3.7.0. An example:

$ mysqlbackup --incremental-with-redo-log-only --incremental-backup-dir=/media/backups/incr_bak1 --incremental-base=dir:/media/backups/fullback backup

To ensure the LSN values match up exactly between successive incremental backups using this option, we recommend always using the --incremental-base option when you use the --incremental-with-redo-log-only option. Using the --incremental-base option has also been described in the blog post 'Taking Incremental Backups without specifying LSN'.

It should be noted that there may be times when MEB cannot perform the redo-log-only incremental hot backup. These are the times when the redo logs of the database have been over-written and page modifications reside only within the pages themselves. In such cases the data-file based incremental backup should be taken since it will successfully backup the remaining redo-logs as well as the data files. Also, incremental backup produced by redo-log-only method is different from the current incremental backup. So, the apply-log step can not be performed on a redo-log-only backup by older versions of MEB i.e. prior to MEB 3.7.0 .


PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL Enterprise Backup: Redo-log-only Incremental Backups

Январь 12th, 2012
The latest release of MySQL Enterprise Backup (MEB 3.7.0) introduces a new method for performing incremental hot backups - the redo-log-only incremental backup. This new method of incremental backups allows for highly compact and fast incremental backups and MEB users now have the choice between data-file based incremental backups and the redo-log-only incremental backups.

In data-file based incremental backups (performed using the '--incremental' option) MEB scans all InnoDB datafiles but copies to the backup only modified pages. The main benefit of this is that an incremental backup is much smaller than a full backup but the downside is that during the process of taking an incremental backup MEB still reads all data-files.

With the new redo-log-only incremental hot backups MEB copies just redo logs accumulated since the previous backup. So, no scanning of the data-files is needed and just sequential copy of the redo log is performed. The redo-log-only incremental backup and data-file based incremental backup treat the non-InnoDB data in the same way: the backup of InnoDB data is incremental but the backup of non-InnoDB data is not. Some important aspects of this backup method are:

  • Incremental redo-log-only backup is not always possible. Redo log in InnoDB is implemented with fixed-size circular log files. This means that oldest log entries are overwritten by newer ones after some time. Incremental backup using only redo log is possible only from the log position that is not yet overwritten.
  • Efficiency of the method depends on how the database is modified. If many database pages are modified, but each page is modified only once or a few times, then copying just redo log might work well. On the other hand, if only a small fraction of the database pages is modified, but each page is modified many times, then this method might give poorer performance.

Let us consider a typical usage scenario in which the redo-log-only incremental hot backup is used to back up a database once a day. This requires that InnoDB log files are large enough to hold at least one day's worth of redo logs. This also means that InnoDB log files are pretty large: for a terabyte sized database with 1% of datafile pages modified each day the minimum combined log file size would be 10 gigabytes.

Our experiments showed that the redo-log-only incremental backup method offers significant performance improvements over the normal incremental backup when the database is suitable for this method: the backup process takes less time and the resulting backup is smaller.

For taking redo-log-only incremental hot backups the user needs to issue the incremental backup command with the '–incremental-with-redo-log-only' option instead of the normal '–incremental' option. An example:

$ mysqlbackup --incremental-with-redo-log-only --incremental-backup-dir=/media/backups/incr_bak1 --start-lsn=18974478 backup

Redo-log-only incremental backups are also compatible with the '–incremental-base' option introduced in MEB 3.7.0. An example:

$ mysqlbackup --incremental-with-redo-log-only --incremental-backup-dir=/media/backups/incr_bak1 --incremental-base=dir:/media/backups/fullback backup

To ensure the LSN values match up exactly between successive incremental backups using this option, we recommend always using the --incremental-base option when you use the --incremental-with-redo-log-only option. Using the --incremental-base option has also been described in the blog post 'Taking Incremental Backups without specifying LSN'.

It should be noted that there may be times when MEB cannot perform the redo-log-only incremental hot backup. These are the times when the redo logs of the database have been over-written and page modifications reside only within the pages themselves. In such cases the data-file based incremental backup should be taken since it will successfully backup the remaining redo-logs as well as the data files. Also, incremental backup produced by redo-log-only method is different from the current incremental backup. So, the apply-log step can not be performed on a redo-log-only backup by older versions of MEB i.e. prior to MEB 3.7.0 .


PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL Enterprise Backup: Taking Incremental Backups without specifying LSN

Январь 11th, 2012
In its latest release MySQL Enterprise Backup (MEB 3.7.0) rolled out a new feature called 'incremental-base' which can save a lot of time and effort of the users when taking incremental backups. Let us understand this new feature and how it can be helpful:

What is an incremental backup ?

With MySQL Enterprise Backup v3.6.0 the functionality of performing incremental backups was introduced. An incremental backup is one in which only the changes made since your last backup are saved. So let's say you took a full backup of your MySQL database on 1/1/2011 and its size was 1TB. Now on 1/5/2011 the size of your database has reached to 1.1TB and you want to take another backup. Without incremental backups you would have to take a full backup and effectively backup the entire 1.1TB database For a typical user this is going to take a lot of time and disk space! Incremental backup feature comes to the rescue in such situations because with incremental backups you can save only the changes made in your database since the last backup. And this,of course, is very fast and space saving.

Taking incremental backup prior to MEB 3.7.0

Every backup done using MEB saves with itself meta-data which describes the backup along with its various parameters. This meta-data also includes two values - Start Log Sequence Number (start_lsn) and End Log Sequence Number (end_lsn). A Log Sequence Numbers is a unique ID of a log record made by the MySQL Server when any DDL/DML operations were performed. So a backup consists of all the modifications that were made from the start_lsn to the end_lsn.

Now suppose you want to take an incremental backup. This means that you want to backup only those modifications that were made in the database(s) after your last backup. Later, during the time of recovery, you will incorporate these additional changes (of incremental backup) into the previous full backup. MEB 3.6+ allows you to do this with the '–incremental' option and the '–start-lsn' option where '–start-lsn' is the end_lsn of your last backup. On the command line:

$ mysqlbackup --incremental --incremental-backup-dir=/media/data/backups/incr_bak1 --start-lsn=18974478 backup

This would speedily produce a backup of fractional size as compared to the full backup and when you want to prepare your full backup for recovery you need to use the command 'apply-incremental-backup':

$ mysqlbackup --backup-dir=/media/data/backups/full_bak --incremental-backup-dir=/media/data/backups/incr_bak1 apply-incremental-backup

And there you are! Your full backup is now incorporated with all the page modifications saved in the incremental backup and is ready to be restored whenever you want. Note that when you are using apply-incremental-backup over a full backup make sure that you have used the apply-log command over the full backup before applying the incremental backup.

So this was how you took an incremental backup before MEB 3.7.0

Taking incremental backup with MEB 3.7+

In the method described above, you should have noticed that you either need to look it up or keep saved the value end_lsn of the previous backup after which you want to take an incremental backup. With the new option '–incremental-base' introduced in MEB 3.7.0 things become much easier. The backup defined by 'incremental_base' is simply the 'base' backup for your new incremental backup i.e. the backup whose end_lsn you want to use as the start_lsn for your incremental backup. So looking up the old backup directory or saving the end_lsn of your previous backup is no longer required. When you want to take an incremental backup use the –incremental-base option with the 'dir' prefix (as shown below) instead of the –start-lsn and you are ready to take a backup. On the command line:

$ mysqlbackup --incremental --incremental-backup-dir=/media/backups/incr-bak2 --incremental-base=dir:/media/backups/fullbackup backup

The theory behind incremental backup remains the same as described with the only difference that you do not need to provide the start_lsn explicitly - just point to your old backup (called the 'base' backup) using the '–incremental-base' option and MEB will extract its end_lsn automatically.

Behind the scenes

The picking up of the end_lsn of the 'base' backup is not as straight forward as it seems. To protect the backup and to make sure that the correct end_lsn is extracted MEB compares the end_lsn in the backup_history table of MySQL server (for the last backup done at the location specified by –incremental-base=dir:) with that found in the backup_variables.txt file of the 'base' backup and MEB aborts operation with an error in case the LSNs do not match. This is probably the case if the meta files of your base backup are corrupt or the values in the backup_history table are altered.

Moving the backup

Consider the case when you moved your old backup to a new location. When the old backup was performed the MySQL server saved all the details of the backup in the mysql.backup_history table. This also included the field 'backup_destination'. For the new incremental backup if you now provide –incremental-base=dir:<new location> MEB will first try to query the server's backup_history table for any previous backups performed at this location. If it doesn't find any such backups, it will extract the end_lsn found in the meta data files at the new location of your base backup and continue with the incremental backup. Similarly, if you provide –incremental-base=dir:<old location> MEB will extract the end_lsn of the previous backup done at that location from the backup_history table. After this, if it cannot find any backup at the old location (since it has been moved) it will silently continue with the incremental backup using the end_lsn found in the server's backup_history table. MEB will not continue with the backup operation if the end_lsn can be extracted from both the backup_variables.txt file as well as the server's backup_history table and the two values do not match! The description above can be summarized as follows:

A: end_lsn could be extracted from backup_variables.txt file

B: end_lsn could be extracted from backup_history table


A B both LSNs match successful backup
yes no - yes
no yes - yes
yes yes yes yes
yes yes no no
no no - no

So MEB allows you to use the '–incremental-base' option even after you have moved your previous backups. In case of any confusion or difficulty you can always use the '–start-lsn' option to provide the start_lsn explicitly.


PlanetMySQL Voting: Vote UP / Vote DOWN

Announcing MySQL Enterprise Backup 3.7.0

Январь 11th, 2012

The MySQL Enterprise Backup (MEB) Team is pleased to announce the release of MEB 3.7.0, with several exciting and advanced features to benefit a wide audience. Included in this release are,

  • Redo Log only Incremental Backup
  • Incremental Backup without specifying LSN
  • Validation of Backup Image using checksums
  • Hot Backup of InnoDB .frm files
  • Performance Improvements and
  • Enhancements for Third-Party Media Managers 

 The gist and usefulness of all these new features are described in short below,

Redo Log Only Incremental Backup:
This is a new type of incremental backup that copies only the InnoDB redo log accumulated since the previous full or incremental backup. The original incremental backup technique copies from the InnoDB data files only those pages that were modified since the previous backup. This incremental backup technique based on the redo log is much faster in most cases than incremental backups that read the data files, if incremental backups are taken frequently. You can choose this new method by specifying the --incremental-with-redo-log-only option on the mysqlbackup command line.

Performance Improvements:
Performance of backup-related I/O operations is improved, particularly on Windows, by reusing I/O library code and best practices from the MySQL Server product. To avoid memory fragmentation and overhead from frequent malloc() / free() sequences, the mysqlbackup command now does all read, compress, uncompress, and comparison operations within a fixed-size buffer that remains allocated while the command runs.

Validation of Backup Image using Checksums:
The new validate option of the mysqlbackup command tests the individual files within a single-file backup using a checksum mechanism. Validation helps to verify the integrity of the single-file backup image as the image file is moved between servers and thereby ensure that backups are reliable and consistent.

Hot Backup of InnoDB .frm files
:
With this new feature, you do not have to manually copy the .frm files to perform restore. The new option --only-innodb-with-frm performs an InnoDB-only backup and backs up even the .frm files of InnoDB tables in non locking mode. Formerly, the InnoDB-only backup required putting the database briefly into a read-only state and copying the .frm files within your own backup script.

Enhancements to Third-Party Media Managers
:
 To customize the interactions between MySQL Enterprise Backup and media management software (MMS), the --sbt-environment option lets you pass application-specific environment settings to the MMS (for example, Oracle Secure Backup). Each vendor that uses the SBT programming interface could implement its own set of environment variables. The --sbt-environment variable lets you pass environment variable values from any invocation method (for example, a Makefile) rather than setting and unsetting the variables within a wrapper shell script.

For more information about MEB features and examples, please see the MEB documentation located <http://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/index.html>. My sincere thanks to Lars Thalmann, Sanjay Manwani and all the MEB team members, who have provided valuable features and improvements for every release.

Download the MEB 3.7.0 package from the Oracle Software Delivery Cloud web site <https://edelivery.oracle.com/>. MySQL Enterprise customers can begin deploying MEB 3.7.0 immediately. Users without a MySQL Enterprise license can evaluate MEB 3.7.0 for free for 30 days; please try it out and send your feedback to mysql-backup_ww@oracle.com.




PlanetMySQL Voting: Vote UP / Vote DOWN

2011, A great year for MySQL in review…

Декабрь 29th, 2011
I see so many posts on what happened to company X, product Y and dream Z that I couldn't resist the temptation to summarize this great year for MySQL. At the end of 2010, Oracle did an announcement we were all waiting for: MySQL 5.5 is GA! Another year has passed since then and it's time to reflect on what has been done.

I know this is a long post. I tried to rewrite it at least 10 times to make it shorter, but I couldn't condense the list. Hence, I wrote a summary in the beginning for those who don't want to read it all.

I believe that 2011 was an exceptional year for MySQL and I really enjoy being part of this team. I wish all of us a lot of success and fun in the years to come!

Summary:
Oracle released many MySQL 5.6 and MySQL Cluster 7.2 DMRs accompanied by new versions of MySQL Enterprise Monitor, MySQL Enterprise BackupMySQL Workbench (and utilities), MySQL Proxy, MySQL Cluster Manager and Connectors.

The MySQL team unveiled new products like the MySQL Installer for Windows and Oracle VM Templates for MySQL. Besides, the MySQL Enterprise offering has been enriched with new commercial extensions. MySQL can now be leveraged as one of the Oracle data management solutions with new certifications and the integration with My Oracle Support increased the business value of customers' investment on Oracle technologies.

Additionally MySQL presented at mayor events across the world and won a few awards.


Long List:
If you're still reading, below you can find an hopefully-extensive list of announcements and blogs (in reverse chronological order). I've mainly covered product releases, events and awards. Please let me know if I missed something.

Products: 
Dec 26 - MySQL Workbench 5.2.37 Has Been Released
Dec 20 - MySQL 5.6.4 Development Milestone Now Available!
Dec 02 - MySQL Enterprise Monitor 2.3.8 is now GA!
Nov 28 - MySQL 5.5.18 Debian packaging now available
Oct 10 - New MySQL Enterprise Oracle Certifications
Oct 10 - MySQL Utilities 1.0.3
Oct 07 - MySQL Cluster 7.2 (DMR2): NoSQL, Key/Value, Memcached
Oct 03 - More Early Access Features in the MySQL 5.6.3 Development Milestone!
Oct 03 - New Development Milestone Releases & Certifications!
Sep 15 - New Commercial Extensions for MySQL Enterprise Editions
Sep 09 - MySQL@Oracle OpenWorld
Sep 06 - Oracle Enhances MySQL Installer and High Availability for Windows
Sep 06 - Oracle Enhances MySQL Manageability on Windows
Aug 19 - MySQL Proxy 0.8.2 Has Been Released
Aug 01 - More New MySQL 5.6 Early Access Features
Jul 19 - MySQL Enterprise Backup 3.6 - New backup streaming, integration with Oracle Secure Backup and other common backup media solutions
Jul 18 - Simpler and Safer Clustering: MySQL Cluster Manager Update
Jul 06 - Announced Oracle VM Templates for MySQL
Apr 12 - MySQL Cluster 7.2 Development Milestone Release - NoSQL with Memcached and 20x Higher JOIN Performance
Apr 11 - Top Features in MySQL 5.6.2 Development Milestone Release
Apr 11 - Introducing the MySQL Installer for Windows
Mar 15 - Oracle Enhances MySQL Enterprise Edition

Events:
Oct 26 - A lot of MySQL Events in Europe
Oct 12 - MySQL Roadshow in Germany
Sep 16 - OTN MySQL Developer Day in London
Aug 08 - OTN Developer Day: MySQL is Coming to Washington, DC
Jul 14 - New “Meet The MySQL Experts” Podcast Series
May 13 - Upcoming MySQL Events in Europe
Apr 26 - OTN Developer Day for MySQL - Santa Clara, CA
Mar 25 - MySQL (and Cluster) at Collaborate and O'Reilly MySQL Conference
Mar 14 - First Ever MySQL on Windows Online Forum - March 16, 2011

Awards:
Dec 15 - MySQL Wins Best Open Source Product of 2011 Award
Jun 03 - MySQL Wins the php|architect Impact Award for Data Management
Jan 17 - MySQL Makes the Cover of Oracle Magazine

To all MySQL customers, partners, colleagues, developers, users, advocates or aficionados: Thank you for this terrific year! Go MySQL!



PlanetMySQL Voting: Vote UP / Vote DOWN

WebOS and the open alternative live another day

Декабрь 13th, 2011

There has been no shortage of reaction to HP’s move to make the Linux-based WebOS open source software. Below, I offer some of my thoughts on the meaning for the different players affected.

*What’s it mean for WebOS?
Moving WebOS to open source was best option for HP. It retains some value in the software depending on its involvement. It is also the best fate for the code, rather then being sold or simmered to its IP and patent value or even used as another weapon in the ongoing mobile software patent wars. Still, the move comes amid huge developer and consumer uncertainty for WebOS. Nevertheless, at least WebOS was already in the market with a compelling products, the Palm the Pre, in the modern smartphone market. WebOS will hopefully have a faster path to open source than Symbian since the former is based on Linux. I still think the greatest opportunity for WebOS may be in serving as an open alternative in the market, particularly after Android has proven to handset makers, wireless carriers, OEMs and others that a Linux-based, open source mobile OS can succeed in the market and provide profit for multiple parties. Furthering this opportunity, WebOS may be even more attractive to these key vendors, channel players and other stakeholders who are tired of the IP and patent stress and expense around Android. Of course, Android was not under patent or IP attack until it was successful in the market and the same may be the case for WebOS, though we think its IP roots and history in touch and smartphone technology are less complex in terms of origin and ownership.

*What’s it mean for competitors?
For Apple, an open source WebOS means more market pressure and open pressure, more competition for developers and a real danger WebOS hooks into the Android ecosystem. WebOS may also be harder to attack from a patent and IP standpoint since it is older and more singular in ownership (Palm and now HP). Other factors include HP’s own formidable patent portfolio and the perception of Apple as a patent aggressor, which would be reinforced if it attacked WebOS the way it has gone after Android.

For Android, it may finally get a dose of its own open medicine, feeling the pressure of another Linux-based, open source mobile OS that is familiar to many developers, compatible with newer smartphone technologies and appealing to handset makers and other key OEMs. However, WebOS is also a validation of Android, which paved the path for mobile Linux and open source to finally break through beyond geeks to reach a mass consumer audience.

As for other proprietary players such as Microsoft and RIM, another open source rival is bad news. It presents another open source option and potentially serious competition on developers, applications, devices, carriers and consumers. An open source WebOS may also make Android, in effect, more open with faster, easier access to code for both Android and WebOS compete. This could make it even harder for these older, proprietary players to get developer or consumer mind share that is already slipping.

*What’s it mean for open source? Really, there is no downside for open source except that it will be viewed as a form of software cemetery if WebOS is not developed or delivered to market. HP’s WebOS move does give open source greater prominence in mobile software. Again, it is a validation of Android, which is Linux-based and open source, and shows that we haven’t seen the last of mobile Linux and open source software in Android.


PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL 5.5.18 Debian packaging now available

Ноябрь 28th, 2011

I am happy to announce that MySQL 5.5.18 is now available via Debian native packaging.  We have gotten many requests for this and our build and release teams have pulled together to ensure that our DEB packages are delivered with the highest quality. 

You can download MySQL 5.5.18 Debian 5 and 6 packages from the MySQL Community Download page or from the My Oracle Support portal.

As always, thanks for your continued support of MySQL!


PlanetMySQL Voting: Vote UP / Vote DOWN

Monitoring Related OpenWorld Talks

Октябрь 12th, 2011

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the "MySQL Monitoring Mechanisms" talk, which runs through the new instrumentation in Performance Schema, the new INFORMATION_SCHEMA tables for monitoring InnoDB, and the new ways to trace how a statement executes with the enhanced EXPLAIN plan, and the new Optimizer Trace:


PlanetMySQL Voting: Vote UP / Vote DOWN

Monitoring Related OpenWorld Talks

Октябрь 12th, 2011

I gave two monitoring related talks at OpenWorld, thanks to all that came along!

Both were monitoring related, the first an introduction to MySQL Enterprise Monitor, and the second a look at some of the new instrumentation that is getting developed, primarily within the MySQL 5.6 release. 

If you'd like to get a quick overview of how MySQL Enterprise Monitor works, then take a look through the "Getting to Know MySQL Enterprise Monitor" talk. This gives you a high level view of how the different pieces fit together, and then each of the important factors within the user interface:

And if you are interested in seeing how the instrumentation and monitoring landscape will look when 5.6 hits the streets, then you can get a sneak peak at the "MySQL Monitoring Mechanisms" talk, which runs through the new instrumentation in Performance Schema, the new INFORMATION_SCHEMA tables for monitoring InnoDB, and the new ways to trace how a statement executes with the enhanced EXPLAIN plan, and the new Optimizer Trace:


PlanetMySQL Voting: Vote UP / Vote DOWN

When Clever Goes Wrong & How Etsy Overcame – Arstechnica

Октябрь 5th, 2011

In 2007, Etsy made a big bet on homegrown middleware to help with the site’s scalability. A half-year after it was taken live, the company decided to abandon it. As a senior software engineer at Etsy put it, “if you’re doing something ‘clever,” you’re probably doing it wrong.”

Read the full article at Arstechnica.com

I want to focus on the important lessons from this article, about middleware and using stored procedures in this fashion for a public web application, creating unscalable design complexity (smart and “proper” according to the old enterprise design teachings…) – causing infrastructure, development and maintenance hassles.

In the process they did replace PostgreSQL with MySQL but that’s not the critical change that made all the difference. PostgreSQL is a fine database system also.


PlanetMySQL Voting: Vote UP / Vote DOWN