In review of some list posts today, I came across the Falcon Preview 6.0.5 downloads available from the MySQL Forge (even that is unclear, but the directory indicates this on the forge). The Forge Wiki Documentation indicates the 6.0.5 release features (without a download link), however the official MySQL downloads for 6.0, and the directory structure for all MySQL releases only describes 6.0.4.

Nothing in the MySQL News and Events of this new release. The documentation for 6.0.5 is also unclear as it lists this version as Not Yet Released.

This comes on the heels of “Pending General Availability/near-final release candidate” (See here and here), and the Press Releases for Sun Celebrates Third-Party MySQL Storage Engines only to be negated by Sun Microsystems Announces MySQL 5.1 which broke the plugins as they were not compatible.

I don’t wish to create confusion, but it’s unclear what is happening here, not withstanding the new preview only has 5 builds and excludes Mac OS/X which means I can’t natively test.

As per the Platinum Partners List PrimeBase Technologies has made a key achievement. I think this is a great list to make for the company. There are only 18 Platinum partners, and PrimeBase Technologies are the third Storage Engine provider and the second first open source storage engine company.

The News Release quotes “As a key milestone in our relationship with both the MySQL Community and MySQL, this partnership strengthens our commitment and involvement in working with the MySQL database server starting with PBXT and following with additional product developments.”

Update Thanks to Ken Jacobs, I need make a correct, we are not the first “open source storage engine company”, Innodbase, a wholly owned subsidiary of Oracle was indeed.

Kevin Murphy just posted Tip of the Day — max_connections and I thought it might be nice to know what people actually set this to so I’ve created a Survey “What’s your max_connections” (totally anonymous).

For the record, while a consultant the record for a production system was 9,500. Yes you read right, and I might add the client was running a 32-bit OS as well, just to boot.
Apparently they had also tested they could get 9,500 connections, problem is they didn’t do anything with the connections, so didn’t see any per thread memory usage, and I did not get confirmation of how the actually system memory usage was used during the test.

It’s been six weeks since the completion of the acquisition of MySQL by Sun Microsystems. In this time, on the MySQL News and Press Releases there has only been one (1) Press Release here.
In the six weeks between the announcement and completion of the acquisition MySQL made ten (10) Press Releases, and the six weeks preceding this including the Christmas break there was (six) Press Releases.

On the Sun Press Releases in this period there has been twenty three (23), but just the same one MySQL specific.

The MySQL Developer Zone has picked up three articles in the past week, but nothing prior to that for a month.

So, Where’s the News of what’s happening with MySQL?

It seems our only options are the official company blog of Kaj Arno and his travels , Robin Schumacher and Giuseppe Maxia as other sources of information.

There has been some discussion recently regarding the death of MySQL Read Replication starting with Brian Aker and then Farhan, Arjen and Paul have all chimed in. Whatever you want to call it, the next generation of replication approach is clearly on the agenda of the industry leaders and pack followers. We should take a programmatic look however and ask ourselves a few questions. Such as:

1. The Use — What is/was MySQL Replication used for?
2. The Reasons — Why was it used?
3. The Problems — Why is there a need for something better, different or improved?

Read Scalability

1. The Use — Clearly the most commonly known method of MySQL Replication is for Read Scalability. The ability for many more reads to occur against the data then writes. I call it the YouTube effect, thousands/millions of reads (i.e. view a video) to a single write (i.e. upload of a video)
2. The Reasons — Database servers could not support the read/write load. Applications were poorly designed for sharding data. The database was being used for a function when it wasn’t really needed. The MySQL Server can’t scale to a massive number of cores.
3. The Problems — MySQL Replication suffers from the asynchronous condition. A successful transaction on the Master, is not confirmed with a Slave before acknowledgment to the client. Google has made inroads in their own environment to improve the asynchronous nature with the SemiSyncReplication patch, now submitted back to the community. The number one effect of asynchronous replication is lag, and again poorly developed applications simply can’t support successful scale-out. Other problems include locking contention when not using a transactional engine.

Backups

1. The Use — A Replication slave is used to perform a database backup, designed to not affect production usage.
2. The Reasons — MySQL does not support a single “unbreakable” online backup solution. Period. There are partial/incomplete implementations, dependent on storage engines and data volume. There is a Roadmap for a solution in MySQL 6.0 (finally), but it’s way too early to tell what features will there be, will you need to pay for some of them, will it just work, let alone who is going to upgrade to 6.0 for this.
3. The Problems — There exists no consistent method for backup across all storage engines. There is no compatibility for backup/point in time recovery (e.g. binary logs/redo logs) across different master/slave servers. No mirrored binary logs is also a problem, something also in the Google Patch.

Failover

1. The Use — You need Business Continuity or Revenue Continuity Solutions (RCS) as discussed by Marc Simony. You need to ensure the maximum uptime possible with a failover infrastructure when some component (software or hardware) fails and your production database is not accessible.
2. The Reasons — MySQL provides no Online DDL. In a 24×7 large volume, changing functionality application this provides an unnecessary complexity for applying changes easily.
3. The Problems — When correctly configured and applied in a controlled situation, failover can work, provided your data is not too large, and your traffic is not too much. It simply doesn’t have a guarantee to work without data loss in an uncontrolled (i.e. disaster recovery) situation.

Others

There are more reasons, something to write about at a later time. These would include.

• Testing
• Alternative data access path (e.g. Data Warehousing)
• Upgrade Path/Migration Path

Options

To handle Read Scalability. Why select something from the database (or various level of caches in the database call when it can be managed by the Application). Memcache is the obvious buzz word here. With tighter database integration (such as the patches and commands FaceBook has) this could be a winner.

Backups is a tough one, without practical storage engine agnostic consistent solutions I don’t feel the backup conundrum will be resolved anytime soon.

To handle a successful failover you need a guarantee that the data is consistent. A Synchronous Replication solution will solve this. MySQL Cluster is a synchronous solution, however it is impractical for basically every application that is already running with MySQL Replication.

What other options exist? Food for thought.

About Memcache

A little on Memcache for those still in the dark ages. Many large sites such as FaceBook,Fotolog, Wikipedia and Slashdot are strong proponents of Memcached. Created originally for Live Journal Memcached has become the defacto standard in this level of application data caching.

The description from the source.

memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

This week I’d expected to hear good friend Giuseppe (CCO) Maxia speak about MySQL SandBox at the Hamburg MySQL April Meetup.

This is product I’ve thought about using, wanted to use, but just never got to the point to using. I download the current version 1.18, I had MySQL tar’s already of 5.0, 5.1 and 6.0 and was all ready until the late topic change.

However due to the language barrier in the second talk, I got a one-on-one lesson. Now I know how it works, and understands the strengths I can use it as part of my standard vanilla testing. There are some improvements I could see, something perhaps I can contribute if they allow a Perl part-timer too. The joy of open source is I can add, modify, change and submit my work, if not wanted for example, there is simply no loss to me.

• By default installation goes to $HOME, and then creates a different standard for individual, replication or multiple instances. I’d like to see this default to a directory say $HOME/msb so all different installs are all under one directory node. You can specific this currently via –sandbox_directory otherwise.
• express_install.pl could benefit from a –help option
• I’d like the set_replication.pl and set_many.pl commands to support an array of mysql tar’s. I’m most interested in testing replication say from 5.0 to 5.1 and 6.0, not just 5.0 to 5.0. I’d also like to be able to install a 5.0, 5.1 and 6.0 versions and be able to use the multi_cmd to run the same SQL across different versions easily.
• The multi_cmd would benefit from a means to list the identify of the instance with the output. It’s hard as MySQL does not have MYSQL_SID, only a server_id which can be a little confusing.

Thanks Giuseppe for your work on this product.

Current syntax

./install.pl --help
Unknown option: help
    The MySQL Sandbox,  version 1.18 05-Apr-2008
    (C) 2006,2007,2008 Giuseppe Maxia, MySQL AB
syntax: ./install.pl [options]
    -h --home_directory = name          The home directory. (default: $HOME (/Users/rbradfor))
    -d --sandbox_directory = name       Where to install the sandbox, under home-directory
    -P --sandbox_port = number          The port number to use for the sandbox server.
                                        (Default: 3310)

    --datadir_from = name               Where to get datadir files from. Available options are
                                        archive   will be taken from the archived data
                                                  provided with the package. They include
                                                  default username and passwords
                                                  ( DEPRECATED )
                                        script    the script mysql_install_db is called, with
                                                  default users, no passwords.
                                        dir:name  will be copied from an existing mysql directory
                                        (Default: script)

    -i --install_version = name         Which version to install (3.23, 4.0, 4.1, 5.0 or 5.1) default: 5.0
    -b --basedir = name                 Base directory for MySQL (default: /usr/local/mysql)
    -m --my_file = name                 which sample my-{small|large|huge}.cnf file should be used
                                        for additional configuration
                                        You may enter either the label (small|large|huge) or a full
                                        file name. (default: none)

    -f --conf_file = name               Configuration file containing options like the ones
                                        you can give on the command line (without dashes)

    -U --operating_system_user = name   Operating system user (for mysql installation)
                                        default: $USER (rbradfor)

    -u --db_user = name                 user for global access to mysql (Default: sandbox)
    -p --db_password = name             password for global access to mysql (Default: sandbox)
    -c --my_clause = name               option to be inserted in a my.cnf file
                                        it may be used several times

    --prompt_prefix = name              prefix to use in CLI prompt (default: mysql)
    --force                             Use this option if you want to overwrite existing directories
                                        and files during the installation. (Default: disabled)

    --no_ver_after_name                 Do not add version number after sandbox directory name (default: disabled)
    -v --verbose                        Use this option to see installation progress (default: disabled)
    --load_grants                       Loads the predefined grants from a SQL file.
                                        Useful when installing from script.
                                        (default: disabled)

    --no_load_grants                    Does not loads the predefined grants from a SQL file.
                                        (default: disabled)

    -t --interactive                    Use this option to be guided through the installation process (default: disabled)
    --no_confirm                        suppress the confirmation request from user

Example:
     ./install.pl --my_file=large --sandbox_directory=my_sandbox